From: Unruh on
terryc <newsninespam-spam(a)woa.com.au> writes:

>On Wed, 28 Oct 2009 14:57:55 +1100, Grant wrote:


>>>*sync isn't a abckup system. It is just a copy system.
>>
>> And a backup is not a copy?

>A backup system has multiple copies, with historical content.

man rsync
Look for --link-dest
And if you want it slightly more automated, use rsnapshot, which moves the old
directories for you.

From: Unruh on
David Brown <david(a)westcontrol.removethisbit.com> writes:

>terryc wrote:
>> On Tue, 27 Oct 2009 21:48:21 -0700, Keith Keller wrote:
>>
>>> On 2009-10-28, terryc <newsninespam-spam(a)woa.com.au> wrote:
>>>> On Wed, 28 Oct 2009 14:57:55 +1100, Grant wrote:
>>>>
>>>>>> *sync isn't a abckup system. It is just a copy system.
>>>>> And a backup is not a copy?
>>>> A backup system has multiple copies, with historical content.
>>> How do you come to that definition? A backup system has as many copies
>>> as desired/needed by business practice. If one copy without history is
>>> sufficient, then that's a good backup.
>>
>> The basic reason is that problems can happen with "the copy". No matter
>> what your system, one copy is no copy at certain times.
>>

>For an example, consider what happened to a very large software company
>recently when trying to do a hardware upgrade of the storage system.
>There was only one copy of the data (an old copy at that). Before doing
>the hardware upgrade, they wanted to make a new copy - but there was not
>enough space on the backup system. So they deleted their only copy, and
>started making a new copy. Since it was going to take days to make the
>new copy, and they couldn't be bothered waiting, they cancelled the copy
>and did the hardware upgrade anyway. When that failed, everything was gone.

>As you say, having a single copy is not a backup system by itself.

Sorry, but your example does not show that at all. No backup system is proof
against total human stupidity.



>And even multiple copies on multiple devices at multiple locations is
>not a backup system - you need a tried and tested recovery procedure to
>make it a backup system.

And rsync is a recovery system as well. That is the huge advantage of rsync. What
is saved is the same as what is needed. No compression, no weird format, not
concatenation that can be unreadable if a single byte changes.


>> As others have pointed out, it is the system, not the tools (tar, cpio,
>> rsync, etc).
>>

>However, the tools form the central part of the backup system, and
>determine the main features you have available. Thus it does make sense
>to talk about an rsync backup system.

>> As you say, it is about what he really needs.
>>
>> My 2c is that depending on amount of data and frequency of changing, he
>> could probably just dump his databases and just burn a DVD each night.
>> $AUS50 for a dvd burner and AUS50c/DVD. Even cheap DVD should last a few
>> years before they are toasters.
From: Günther Schwarz on
terryc wrote:

> On Tue, 27 Oct 2009 21:48:21 -0700, Keith Keller wrote:
>
>> On 2009-10-28, terryc <newsninespam-spam(a)woa.com.au> wrote:
>>> On Wed, 28 Oct 2009 14:57:55 +1100, Grant wrote:
>>>
>>>>>*sync isn't a abckup system. It is just a copy system.
>>>>
>>>> And a backup is not a copy?
>>>
>>> A backup system has multiple copies, with historical content.
>>
>> How do you come to that definition? A backup system has as many copies
>> as desired/needed by business practice. If one copy without history is
>> sufficient, then that's a good backup.
>
> The basic reason is that problems can happen with "the copy". No matter
> what your system, one copy is no copy at certain times.
>
> As others have pointed out, it is the system, not the tools (tar, cpio,
> rsync, etc).
>
> As you say, it is about what he really needs.

Well said. The OP did not show up again. So it is not easy to guess what
he needs. One aspect that I miss in the discussion is networking. This is
a networking group, and the OP is a system at school which will likely be
a small network.
If more than one machine has to be included in a backup scheme a simple
script based system running on every single host quickly becomes too much
demanding in administration. In such a situation the big packages like
bacula, amanda or TVM show their strength in maintaining a single
database and backup documentation for all hosts. They are also able to do
load balancing and thus distributing costly full backups over the backup
cycle.

Günther
From: David Brown on
Unruh wrote:
> David Brown <david(a)westcontrol.removethisbit.com> writes:
>
>> terryc wrote:
>>> On Tue, 27 Oct 2009 21:48:21 -0700, Keith Keller wrote:
>>>
>>>> On 2009-10-28, terryc <newsninespam-spam(a)woa.com.au> wrote:
>>>>> On Wed, 28 Oct 2009 14:57:55 +1100, Grant wrote:
>>>>>
>>>>>>> *sync isn't a abckup system. It is just a copy system.
>>>>>> And a backup is not a copy?
>>>>> A backup system has multiple copies, with historical content.
>>>> How do you come to that definition? A backup system has as many copies
>>>> as desired/needed by business practice. If one copy without history is
>>>> sufficient, then that's a good backup.
>>> The basic reason is that problems can happen with "the copy". No matter
>>> what your system, one copy is no copy at certain times.
>>>
>
>> For an example, consider what happened to a very large software company
>> recently when trying to do a hardware upgrade of the storage system.
>> There was only one copy of the data (an old copy at that). Before doing
>> the hardware upgrade, they wanted to make a new copy - but there was not
>> enough space on the backup system. So they deleted their only copy, and
>> started making a new copy. Since it was going to take days to make the
>> new copy, and they couldn't be bothered waiting, they cancelled the copy
>> and did the hardware upgrade anyway. When that failed, everything was gone.
>
>> As you say, having a single copy is not a backup system by itself.
>
> Sorry, but your example does not show that at all. No backup system is proof
> against total human stupidity.
>

The point is, before they started this upgrade process, they did have a
single copy. But they did not have a backup system.

But as you say, no backup system is proof against this level of
stupidity and irresponsibility.

>
>
>> And even multiple copies on multiple devices at multiple locations is
>> not a backup system - you need a tried and tested recovery procedure to
>> make it a backup system.
>
> And rsync is a recovery system as well. That is the huge advantage of rsync. What
> is saved is the same as what is needed. No compression, no weird format, not
> concatenation that can be unreadable if a single byte changes.
>

Absolutely agreed.
From: David Brown on
Günther Schwarz wrote:
> terryc wrote:
>
>> On Tue, 27 Oct 2009 21:48:21 -0700, Keith Keller wrote:
>>
>>> On 2009-10-28, terryc <newsninespam-spam(a)woa.com.au> wrote:
>>>> On Wed, 28 Oct 2009 14:57:55 +1100, Grant wrote:
>>>>
>>>>>> *sync isn't a abckup system. It is just a copy system.
>>>>> And a backup is not a copy?
>>>> A backup system has multiple copies, with historical content.
>>> How do you come to that definition? A backup system has as many copies
>>> as desired/needed by business practice. If one copy without history is
>>> sufficient, then that's a good backup.
>> The basic reason is that problems can happen with "the copy". No matter
>> what your system, one copy is no copy at certain times.
>>
>> As others have pointed out, it is the system, not the tools (tar, cpio,
>> rsync, etc).
>>
>> As you say, it is about what he really needs.
>
> Well said. The OP did not show up again. So it is not easy to guess what
> he needs. One aspect that I miss in the discussion is networking. This is
> a networking group, and the OP is a system at school which will likely be
> a small network.
> If more than one machine has to be included in a backup scheme a simple
> script based system running on every single host quickly becomes too much
> demanding in administration. In such a situation the big packages like
> bacula, amanda or TVM show their strength in maintaining a single
> database and backup documentation for all hosts. They are also able to do
> load balancing and thus distributing costly full backups over the backup
> cycle.
>
> Günther

We can talk about rsync and networks if you like! rsync is very
network-friendly, as it only copies over the differences between
directories when doing a synchronisation (assuming you have appropriate
flags set). For large files, it can even copy only the changed parts of
the file. And all the network transfers can be compressed. This all
makes it very bandwidth friendly, and is very useful for doing offsite
backups.

For backup of multiple machines, it's best to install an rsync server on
the servers, and use an rsync client on the backup machine. This gives
you a single place to organise most of the backup system.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: GRE Keys
Next: Spanning-tree Protocol implementation