[sllug-members]: easy backups

[Bart Whiteley]

On Mon, 2006-05-01 at 18:41 -0600, Mac Newbold wrote:
> 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.
> 

That's what I was thinking.  As I read his description of rdiff-backup,
I could only think of ways in which it was inferior to rsnapshot-like
solutions.  I was just wondering if I missed something...