As a excersize in learning about about these tools I've been using git with a custom makefile to make backups easy for myself.
I have some information I want to keep replicated across a bunch of machines. I may use them randomly, but I want to keep a more-or-less consistent view of this data across all of them. They are mobile devices so that having a central server for backups or a file server isn't going to work.
Advantages of git..
* fast
* keeps full revision history in a very compact format. Uses a logging system and keeps branches data. This means you can easily rollback changes. It keeps deltas between changes, which can be compressed, to save data. This is contrast with traditional multi-versioned backups that end up using massive amounts of storage space to do the same thing.
* syncing data between machines is faster then rsync
* uses running checksums to help prevent and detect data corruption. Uses real cryptographically secure checksums, sha1, rather then crc stuff. If the top-level checksum checks out then you now your data is safe from corruption.
* fully distributed each copy is a complete and total copy of the repository and can perform all operations on any data contained in it in total isolation
* can be configured in a number of ways, but how I use it through ssh.. no 'git server' is needed. All data is pulled by copying it over ssh. Since I use ssh keypairs I can replicate and sync data securely with no passwords.
* on text files (it's designed for source code, after all) it keeps track of _content_, not files and directories. This means it will track lines of data being moved from one file to another with full revision history AND moving files around, renaming them, combining, splitting, and adding and deleting directories is done gracefully and without user interaction. This is in huge contrast to other rcs that track things on a file-centric basis and moving lots of files around will cause havoc.
downsides:
* designed for code, bad performance with large binary files (very big downside)
* needs mantainance and occasional cleaning to reduce repository size or get rid of unnecessary data..
* not particularly user friendly.
* does not preserve metadata.
If your working with some types of data formats, like Opendoc or whatever then those are XML files that are stored with zip compression. You could probably use those with git with a extra decompression step.
So I keep repository synced across 3 machines.
Then I use the Makefile to keep track of scripts.
If I just type:
make
it echo's out a list of commands it'll take.
$ make commit
will add any new files and then commit them to the repository. Then a text editor opens up so I can add notes and uncomment file change notations.
$ make backup
will then create a tarball of my data, compress it, encrypt it, then sends it out to my PC at home, my file server, and then a online server. This way no matter what copy I end up salvaging after the initial nuclear attack I'll still have full data preservation with checksums and full revision history.
Then it does some other stuff for me with other commands. I started using a similar system at work and this backs up to three servers and then a compact flash drive. No data is going off-site, off course.
Except for the issue with storing binary files it works out pretty well. There are some projects that are trying to make a general purpose application that turns git into something more usefull for a backup. Two that I know of are GHH and Gibak.
http://eigenclass.org/hiki/gib...up-system-introduction
Facebook
Twitter