[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