Apply the 3-2-1 pattern

The 3-2-1 rule is the classic baseline: keep three copies of important data, on two kinds of storage or failure domains, with one copy offsite.

Each number defends against a different disaster. Three copies means one failure never leaves you with a single point of truth. Two storage types means a bad disk batch or a filesystem bug can’t take everything. One offsite copy means a fire, flood, or burglary at one location doesn’t end the story.

Map one dataset

Take a real dataset and write down where its copies live:

copy 1: live laptop data
copy 2: versioned backup on external disk
copy 3: encrypted versioned backup in remote object storage

Note that the live data counts as copy one. You only need two backups to satisfy the rule, but they must be genuinely independent.

Now name the failure each copy survives: accidental deletion, disk loss, device theft, account compromise, or site disaster. This is the verification step for a backup plan. If two copies fail for the same reason, they count as one:

accidental deletion  -> external disk (has history)
laptop disk death    -> external disk, object storage
house fire           -> object storage only
cloud account hacked -> external disk only

Every threat should have at least one surviving copy. If a row comes up empty, you’ve found the gap before the disaster did.

The counting mistake

The most common error is counting a synchronized mirror as a backup. A mounted mirror is vulnerable to the same deletion, malware, and operator mistakes as the live data. Delete a file, and Dropbox, RAID, or an always-connected rsync target deletes it too — instantly and faithfully. Same for ransomware: it encrypts the mirror right along with the source.

What makes a copy a real backup is version history and some independence from the live system: an offline disk, separate credentials, or snapshots the source machine can’t overwrite. Independence matters more than count alone.