[sllug-members]: easy backups
Mac Newbold
mac at macnewbold.com
Mon May 1 18:41:32 MDT 2006
Today at 6:05pm, Bart Whiteley said:
> On Mon, 2006-05-01 at 17:50 -0600, Scott Patten wrote:
>> I'd like to add a second vote for rdiff-backup. It combines the
>> advantages of diff with those of rsync. It will very efficiently
>> create
>> a copy of a directory and also keep compressed backups of the changes
>> that occurred since the last backup. When you want to restore a
>> file,
>> you just copy it. When you want to restore an older copy then you
>> issue
>> an rdiff-backup command that decompresses and recombines the files to
>> give you the version that you are after.
>
> What are the advantages of rdiff-backup over
> http://www.mikerubel.org/computers/rsync_snapshots/ ?
I'll answer a different question and say that rsnapshot has the advantage
that every file in any of your snapshots is a complete file, usually a
hard-link to identical versions of the same file. You can easily search
your backups with grep or whatever you normally like to use, and restoring
a certain version is as easy as doing a cp (I like cp -p too). The file
permissions and ownership are perfectly preserved. The biggest advantage
I've found in that is knowing that I can quickly and very easily do large
sweeping restores in case of emergency. Once I know which version I want
(like the most recent backup) it is extremely easy to get it and do
whatever you want with it. Since it uses rsync, it also only transfers the
files that have actually changed, and you can turn on compression for
remote backups, so that it saves on bandwidth and time. (It doesn't store
the files compressed, just gzips them during transfer over the network.)
I suspect that an rdiff backup to a remote server would have to transfer
at least the smaller of the two file versions to find the difference
between them, and if so, it wouldn't provide any bandwidth/speed savings
over an rsync/rsnapshot.
The place it could provide an advantage is in the space required for a
backup, especially if you have lots of large files that get small changes
(like log files for example). The diffs could also be bigger than the file
itself, though, if a majority of the file changed, since it shows the old
way and the new way in the diff. And generally diffs are ridiculously bad
with binary files, like images, compressed files, non-text documents (like
the MS Office formats), etc.
The rdiff method can make it more fragile too. This method also adds more
complications for restoring or examining files in your backups, since
they're not whole files, just patches, basically. To restore, you need to
have a valid version of every patch in the dependency chain. I don't know
how they do it in rdiff-backup, but if the full backup was on April 1st,
and you wanted the version from April 27th, you might need 27 patch files,
and if you didn't have all of them, perfect and without any corruption,
you wouldn't be able to recover the file fully. If they do fulls monthly,
an incremental to the full weekly, and an incremental to the weekly each
day, then you'll only need 3 patches for everything to get back perfectly.
All of this is avoided by storing only whole file versions with
rsync-based methods.
Thanks,
Mac
--
Mac Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the sllug-members
mailing list