<i>The</i> key feature of Time Machine is hard links to directories -- which is only possible on modern HFS+ (and rsync doesn't even try). Some people like the UI too, of course.<p>Without hard linked directories, a full --link-dest backup of a decent sized disk, with zero file changes from the previous pass, can easily consume 100MB (and take 45 minutes to perform).<p>This disk consumption might seem insignificant, today, but that's 2.4GB per day if you run a standard Time Machine equivalent backup schedule. Of course you might not choose to do that, because the previous hour's backup would only finish 15 mins before the next one started, which is insane.<p>These numbers are from direct experience on a 2TB, approximately 60% utilized source drive.<p>That said, I use rsync, not Time Machine, for my OSX backups. You'll want a few additional switches for HFS+, and if your target drive is HFS+ also, make sure you turn OFF "ignore ownership on this volume" in the Finder... but the script posted here has the right general idea. Somewhere on my project list is adding directory hardlinking to rsync.
When will this trend of "like time machine" backup software going to stop ?<p>Time Machine, as can be seen here <a href="http://www.apple.com/support/timemachine/" rel="nofollow">http://www.apple.com/support/timemachine/</a> time machine is tightly integrated in the os and provides a self-defining interface and user experience.<p>This github page is for a wrapper shell script around rsync, which is <i>not</i> like time machine.<p>This has been going on for a while now, see Timevault (<a href="https://wiki.ubuntu.com/TimeVault" rel="nofollow">https://wiki.ubuntu.com/TimeVault</a> ), back in time (<a href="http://backintime.le-web.org/" rel="nofollow">http://backintime.le-web.org/</a> ) or flyback (<a href="http://www.flyback-project.org/" rel="nofollow">http://www.flyback-project.org/</a> ).<p>Please telling us your backup solution is like time machine when it lacks the kind of UX time machine offers, thanks !
This sounds a lot like rdiff-backup, which uses rsync and hard links to provide incremental backups:<p><a href="http://rdiff-backup.nongnu.org/features.html" rel="nofollow">http://rdiff-backup.nongnu.org/features.html</a>
This is really cool. For me, most of my data is "in the cloud" now. Important and frequently-accessed project files are in Dropbox, code is on Github, and most of my music is either streamed from the web in Spotify or my actual library is stored/streamed via iTunes Match. Because of this, I actually don't have a considerable amount of data to keep backed-up, and a lightweight non-time-machine solution like this looks perfect. I tried rsync before but never got into a solid routine.<p>I've become obsessed with the "12factor" app approach everywhere in my digital life, so that if a device ever disappeared, was stolen, or died, I could get a replacement fully operational without any problems. Like an app-server dying, just launch a new one and it will bootstrap itself.<p>I'm kinda crazy with my new "homelab" and started it off with an old 2U Poweredge I got on eBay for about $200. It's cheaper than a Synology/Drobo, has room for 6 drives, and the dual quad-core processors + 16GB of RAM is pretty cool too. It's running FreeNAS right now in a VM with a 3TB ZFS pool. I've created an AFP share that appears to my mac as Time Machine and over my gigabit-network it does a pretty fast backup. I really like the FreeNAS software. It's open-source, runs on FreeBSD, and the UI/admin tool is built in Django.
This looks great, doesn't seem to need anything other than rsync installed.<p>You should also check out rsnapshot: <a href="http://www.rsnapshot.org/" rel="nofollow">http://www.rsnapshot.org/</a>, it does a great job and has many of the features that this script does.
I have written a similar script that I use for many years now. These sort of backups are very convenient.<p>I started too with hard links but nowadays I prefer to format my backup disk with BTRFS and use btrfs snapshots instead, though I still support hard links.<p>I prefer btrfs snapshots due to their support for COW, so if I decide to play with a backup I won't mess all the other versions of this backup. With hard links you should never write to your existing backups.<p>Lately I added a helper script to mount remote filesystems and lock mysql databases but it could be easier to use.<p>Most of my code is checks to make sure I won't write somewhere I shouldn't to.<p><a href="https://github.com/andmarios/mrbStudio" rel="nofollow">https://github.com/andmarios/mrbStudio</a>
As quesera noted below, on a not-so-big modern disk with 500,000 files, the metadata can easily be in the 50-100MB range, which adds up to >1GB for metadata (even when nothing has changed) if you back up every hour.<p>You should, however, consider bup (<a href="https://github.com/bup/bup" rel="nofollow">https://github.com/bup/bup</a>) - it takes less than a minute to figure out nothing is done, it deduplicates <i>parts</i> of files, (that is, if you have a 20GB virtual machine image, and you've changed one byte in the middle of it, then the next snapshot is going to take ~10KB, not 20GB). The older release don't keep ownership/modification time, but there's a new version pending release soon that does.<p>It also works well remotely (through ssh), can do an integrity check (bup fsck), redundancy (using par2; important after deduplication). And it has a fuse frontend that makes it all accessible as a file system, as well as an ftp frontend.<p>bup is teh awesome.
Missing some options for extended attributes (SELinux, ACLs) and (on OSX) resource forks.<p>Also, if you're doing multiple backups of the same data to a filesystem over time, it's worth doing 'cp -al' from the previous backup to the current backup destination, then rsync over the top of that - that way multiple copies of files which haven't changed don't take up any extra space.
Link-backup does this as well, plus it knows how to build hard links to old backups even when directory structure or filenames change, effectively de-dup support. It does this by building a content addressable index on the destination filesystem that backup trees hard-link against.<p><a href="http://www.scottlu.com/Content/Link-Backup.html" rel="nofollow">http://www.scottlu.com/Content/Link-Backup.html</a>
If you're looking for file snapshots and versioning, I've found Back In Time (<a href="http://backintime.le-web.org/" rel="nofollow">http://backintime.le-web.org/</a>) to be awesome.