Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: untested backups



 I am a big fan of rsync's "--link-dest" feature.  It allows one to do a 
backup that is both incremental and full. 

You give rsync the source location, the destination, and the link-dest.   
For an "incremental" backup the link-dest would point to the previous 
backup.  If rsync would normally create a new file in the destination if 
it is identical to the corresponding file in the previous backup, it 
instead creates a hard link to the file.  You now can have two (or more) 
hard links to the same file.  Old backups can be deleted, but the file 
will remain for as long as the last hard link to it exists. 

So you can have a whole series of backups, each "complete", but with 
only a single copy of common files (from sequential backups).  This will 
take directory space, you might want to tune your file system creation 
appropriately. 

Also, on the subject of speed to restore, I am a big fan of a mountable 
file system.  Presto, your data can be available with no copying of 
data.  Just access the data you want. 

All very cool.  In fact it is so cool it seems Apple is using something 
very much like it for their new "time machine" backup feature. 

Finally, because it is a disk file system, each new backup is a test 
that the previous backups are (at least somewhat) functional. 

At a previous job I set up the server with auto-rotating, same-disk (but 
different partition) backups, on top of software raid 1.  That was my 
version time-machine, to save people from mistakes and provide some 
hardware protection (raid 1 will catch them in a disk failure, but not 
flood, theft, lightning, etc.). 

Then, a pair of external disks were used as alternating, encrypted, 
offsite backups of that. 

My specific design was only suitable for a fairly small system, mostly 
because rsync doesn't scale up that gracefully, though backing up more 
frequently (and so biting off smaller chunks) helps.  And I didn't do 
anything special for backing up databases (there was no SQL beast there) 
nor being certain the backup was self-consistent--data that is changing 
during the backup can be "smeared", a snapshot feature (a la LVM) would 
help there.  I ran it after hours to minimize the problem.  Understand 
your data. 

-kb 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org