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 |
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 | |
We also thank MIT for the use of their facilities. |