The 3-2-1 backup strategy, explained for Linux servers

The 3-2-1 rule is long-standing backup guidance. Its purpose is to reduce correlated failure: two copies on the same server can disappear with one disk or account, and two copies under one administrative boundary can be deleted by the same mistake or compromise. Independent copies make it less likely that one event removes every recovery path.

Provider snapshots frequently live in the same account or platform as the server. A compromised administrator identity, account suspension, regional incident, or deletion workflow may therefore affect both. Snapshots can be a useful recovery layer, but they should not be assumed to provide the independent copy required by the rule.

Off-site is not merely a different folder or availability zone. Review who controls the account, credentials, billing relationship, deletion permissions, and encryption keys. Independence can come from another provider or a separately protected account, but only when a shared incident cannot readily cross that boundary.

A Linux service can use its live data, an encrypted backup repository in independently controlled storage, and a second protected backup or repository copy. Client-side encryption keeps the stored contents unreadable without the repository password, but encryption alone does not create independence or prevent deletion.

Object versioning and retention controls can preserve earlier object versions after deletion or overwrite. S3 Object Lock can prevent protected object versions from being deleted during a retention period, but those controls affect how backup maintenance behaves. They should be tested with the repository's retention and prune workflow before production use.

A protected mirror or second repository can be easier to reason about than applying an undeletable policy directly to an actively maintained repository. Document who can change retention rules, how protected data is recovered, and how storage costs are bounded. “Immutable” is not useful if the team cannot locate and restore the preserved version.

A commonly used extension adds one offline, air-gapped, or immutable copy and zero unverified errors in the recovery process. It is a useful reminder rather than a substitute for a risk assessment: teams still need to define what counts as independence, how often validation runs, and which application checks make a restore acceptable.

Repository checks can find some forms of damage, while a restore rehearsal proves more of the actual path. Recover a selected point into an isolated location, validate representative data and application behavior, record the duration, and resolve every unexpected warning. The zero is earned through evidence, not inferred from a successful upload.

Rested can operate encrypted restic backups to storage the user controls, keep run history, and surface failed runs. That can provide and monitor one off-host repository in the wider design while keeping the recovery key under the user's control.

Rested does not by itself turn one repository into all three required copies. The user remains responsible for the additional independent copy or protected replica, storage-account separation, and a recovery procedure that still works if Rested or the primary application environment is unavailable.

Count copies only after testing the events they are meant to survive. Ask what remains when the VPS is gone, when the primary cloud account is locked, when a backup client credential is stolen, and when corruption is discovered after the normal retention window. If every answer depends on the same identity or repository, the diagram has more copies than recovery paths.

Review this map after provider, account, or architecture changes. A second copy can quietly lose independence when teams consolidate billing, reuse administrator credentials, or move storage into the same automation boundary. The periodic restore test is a good moment to recheck those assumptions.