Automating Backups for Self-Hosted Apps: The 3-2-1 Rule in Practice
The 3-2-1 backup rule — three total copies of your data, on two different types of storage media, with at least one copy kept off-site — is frequently cited as a general best practice without much explanation of why each specific number matters, or what it actually looks like implemented concretely for a typical self-hosted application rather than as an abstract principle.
Why Three Copies, Specifically
The number three accounts for the reality that any single copy of data, including the original live copy your application is actively using, can fail — a disk failure, accidental deletion, a corrupted database, or a compromised server. A second copy provides basic redundancy against the original failing, but two copies stored in a genuinely similar way (say, on two disks in the same physical server) remain vulnerable to a shared, correlated failure mode affecting both simultaneously, like a power surge, a fire, or a single compromised account with access to both. Three copies, particularly when the additional considerations below are also satisfied, provides meaningfully more resilience against exactly this kind of correlated failure.
Why Two Different Media Types
Storing multiple copies on the same type of medium — say, three separate hard drives, all from the same manufacturing batch, all subject to the same environmental conditions — leaves you vulnerable to a systemic weakness or failure mode specific to that medium type, whether a manufacturing defect affecting an entire batch, a specific type of corruption a particular filesystem is prone to, or ransomware specifically designed to target and encrypt files on locally-attached, always-connected storage. Using genuinely different media types — a local disk, a separate network-attached device, and cloud storage, for instance — means a single systemic weakness affecting one medium type is unlikely to simultaneously compromise the others.
Why One Copy Off-Site
A backup stored in the same physical location as the original — even on different hardware — remains vulnerable to any localized disaster affecting that entire location: a fire, flood, theft, or a broader power or network outage taking down everything in that one place simultaneously. An off-site copy, whether at a genuinely different physical location or in cloud storage operated by a separate provider, ensures that even a total loss of the primary location doesn't mean a total loss of the data itself.
Applying This Concretely to a Self-Hosted Application
For a typical self-hosted application (say, a Nextcloud instance or a self-hosted project management tool, both discussed elsewhere on this blog), a practical 3-2-1 implementation might look like: copy one is the live, running application data on the server itself; copy two is an automated nightly backup written to a separate disk or network-attached storage device physically distinct from the server's primary disk; and copy three is that same backup additionally synced to a cloud storage provider, satisfying the off-site requirement, with the local network-attached storage and the cloud copy together providing the required two distinct media types beyond the original live copy.
Why Automation Is Essential, Not Optional
A backup strategy that depends on someone manually remembering to run it is, in practice, not a reliable strategy at all — manual processes get forgotten, especially during busy periods, which is precisely when an actual disaster is statistically more likely to strike given the correlation between operational stress and mistakes. Automated backup tooling (many self-hosted applications have dedicated backup plugins or scripts, and generic tools like restic or Borg Backup work well for a broader range of applications) scheduled through a cron job or the application's own built-in scheduler removes this human-reliability dependency entirely.
The Step Most People Skip: Actually Testing the Restore
As discussed in the piece on hosting backup systems elsewhere on this blog, a backup that has never actually been restored and verified is a backup only in theory — corruption, an incomplete backup script, or a subtly broken restore process can all render a seemingly successful, regularly-running backup completely useless exactly when it's needed most. Periodically, deliberately performing a full test restore to a separate, non-production environment is the only way to genuinely confirm a backup strategy works, rather than simply assuming it does because the backup job reports success each night.
Encryption for the Off-Site Copy
Because the off-site copy, particularly if stored with a third-party cloud provider, represents data leaving your direct physical control, encrypting backups before they're transmitted off-site (most dedicated backup tools support this natively) ensures that even if the off-site storage provider itself were compromised, or if credentials for that specific account were somehow exposed, the actual backed-up data remains protected and unreadable without the separate encryption key.
The Takeaway
The 3-2-1 rule isn't an arbitrary numerical convention — each specific element (three copies, two media types, one off-site) directly addresses a distinct, genuine failure mode that a simpler backup approach would remain vulnerable to. Implemented with real automation and periodically verified through an actual test restore, it turns backup strategy from a vague good intention into a concrete, reliable safeguard for any self-hosted application genuinely worth protecting.
Tags: 3-2-1 rule, backup strategy, self-hosted backups