Programming And Stuff, You Know The Thing…

The Poor Man's Alternative to Apple's Time Capsule

Posted at — Feb 3, 2019

If you don’t have a Mac and/or don’t want to spend money on NAS or similar, here is what I have come up with after years of experience.

First, I played around with obvious solutions like rsync in combination with hard links. Here is an archived web page of someone who did the same. In the end that solution suffers from performance and disk space issues because each snapshot requires a filesystem entry even for every unchanged filesystem entry included in the backup. That’s why such methods are rather limited in their number of feasible snapshots, so people usually end up having a daily snapshot over a timespan of a few weeks.

Other free and open-source tools are rdiff-backup and duplicity. I have found them to be either slow or unreliable, or both. I don’t like them, also because they make the impression of not being very widespread and therefore not too well tested.

So here is my current solution: rsync plus git. Both tools are in extremely widespread use, have been heavily tested and stood the test of time.

Let me explain a distinction. Snapshot backups, at least in the context of this article, are meant to be data dumps that will accumulate over time and necessarily get pruned or deleted after some time because your backup space will run out of space. In contrast to that, there is also something like a permanent backup.

The first rule of backups is to restrict them to the absolutely necessary parts of your system. My primary personal longterm backup system is simply this: subversion via ssh to keep the main repository off-site. A version control system forces you to actively decide what you want included in your longterm backup. Also, in contrast to git, subversion is built as a global ‘filesystem’, whereas git is intended as project-specific and you usually end up with Hundreds of git repositores, which is really not what you want for that purpose. Also, version control systems effectively protect you from human errors because there is no natural way to delete files from subversion history (however, this can be done with a little more effort if you need to expunge accidentially added binaries etc). This is where snapshot backups come in, at least in my use case scenario: to protect from losing uncommitted changes.

I then use snapshot backups for the short-term backup of uncommitted changes of my subversion repository to a second disk on the same computer, which is protected against human errors through user separation (the backup scripts runs as root). That also allows me to not spam my main repository with unnecessary commits.

Here are the scripts I’m using: