My plan for backups of my home machine (as of early 2024)

February 10, 2024

In theory, what I should do to back up my home desktop is fairly straightforward. I should get one or two USB hard drives of sufficient size, then periodically connect one and do a backup to it (probably using tar, and potentially not compressing the tar archives to make them more recoverable in the face of disk errors). If I'm energetic, I'll have two USB hard drives and periodically rotate one to the office as an offsite backup. Modern USB should be fast enough for this, and hopefully using (fast) USB drives will no longer kill my performance the way it used to. Large HDDs are reasonably affordable, especially if I decide to live with 5400 RPM ones (which I hope run cooler), so I could store multiple full system backups on a single HDD.

In practice this is a lot of things to remember to do on a regular basis, and although I have some of the pieces (and have for years), those pieces have dust on them from disuse. So this approach isn't workable as a way to get routine backups; at best I might manage to do it once every few months. So instead I long ago came up with a plan that is not so much better as more likely to succeed. The short version of the plan is that I will make backups to an additional live HDD in my home desktop.

My home desktop's storage used to be a mirrored pair of SSDs and a mirrored but mismatched pair of HDDs. Back in early 2023, this became all solid state, with a pair of NVMe drives and a pair of SSDs (not the same SSDs, the new pair is much larger). This leaves me with an unused 4 TB HDD, which I actually (still) have in the case. So I can reuse this 4 TB HDD as an always-live backup drive, or what is really 'a second copy' drive. Because the drive will always be there and live, I can automate copies to it, run them from cron, and more or less forget about it (once it's working).

The obvious and most readily automated way to make the backups is to use ZFS snapshots. I'll make a new ZFS pool on the HDD, and then use snapshots with 'zfs send' and 'zfs receive' to move them from the solid state storage to the HDD pool. ZFS's read only snapshots will insure that I can't accidentally damage the backup copies, and I can scrub the HDD's ZFS pool periodically as insurance against disk corruption. My total space usage in both my current solid state ZFS pools is still a bit under 2 TB, so I should have plenty of space for both on a 4 TB HDD.

This is obviously imperfect, since various sorts of problems could cost me both the live storage and the HDD, and I could have ZFS problems too. But it's a lot better than nothing, and sometimes the perfect is the enemy of the good.

(Having written this, perhaps I will actually implement it. The current obstacle is that the old HDDs are still running my old LVM setup, as backup for the ZFS pool I created on the new SSDs and then theoretically moved all of the LVM's contents to. So I'd have to hold my breath and tear down those filesystems and the LVM storage first. Destroying even supposedly completely surplus data makes me twitch just a bit, and so far it's been easier to do nothing.)

Written on 10 February 2024.
« Compatibility lingers long after it's needed (until it gets noticed)
Go 1.22's go/types Alias type shows the challenge of API compatibility »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 10 22:00:55 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.