Restic Continuum

As I was migrating my online backups to Restic, I was concurrently building a system that would allow me to use Restic to complete full-disk backups to external USB drives, thus replacing my use of cryptshot and rsnapshot. I give you Resnap.

For me, the main appeal of rsnapshot has always been that the resulting backups are just directories full of files. When it comes time to restore, no special tooling is required for access. Just copy the files over using rsync or cp or whatever tickles your fancy. If you can read the disk, you can recover data. Most competing systems create backups in a way that you also need the backup tool for recovery. This introduces fragility into the setup. My experience has been that most people do not think or care about this, but I have spent many years thinking about how not to lose data. I have certain requirements for backup systems. “Robustness” is a big one.

Restic does fall into the second category of tool. If you have a copy of a Restic repository but the Restic project has imploded and you do not have or cannot execute the tool, you’re in for a bad time. But the reason Restic has been on my radar since the project first stated a decade ago (it takes me a while to adopt new backup software – also I recall it took them a while to implement compression) is that it is compiled to a single, statically linked Go binary. This means you can easily store the tool itself alongside (not within) your backups. You’re not going to do that with a sprawling Python project like Borg, which is why I continued to use rsnapshot for my local full-disk backups even after I adopted Borg for online backups.

But with Restic you can just cp the binary to the backup drive. And that’s what I do. Resnap also provides resnap-restore, a simple wrapper script that makes it easy to perform the restic restore ... operation during full-disk recovery. This too is stored on the backup drive alongside the binary.

What this means is that you can use Resnap to create a full-disk backup to an external drive and then bury that drive in your backyard for 25 years (properly sealed). After you dig it up, as long as you have the passphrase, can read the drive’s filesystem (ext4 for me), and can execute a binary compiled for whatever architecture you were using 25 years ago (x86-64 for me) – both highly likely given the commonality of those systems – you are going to have no problem restoring that data (subject to the physics of spinning rust). An unlikely scenario perhaps, but that’s sort of the data backup baseline we plan for here at pig-monkey.com.