Skip to content

Backups that work ​

The last lesson showed that drives fail and deletes on an SSD are final. A backup turns both into an inconvenience. By the end of this lesson you can plan a backup that survives the usual disasters, and prove that it works.

What a backup must survive ​

A copy is only a backup if it survives the thing that destroyed the original. Think through the usual causes of loss:

What happensWhat it destroysA copy that survives it
You delete or overwrite the wrong fileThat file, nowAn older version of the file
The drive failsEverything on that driveA copy on another drive
Ransomware or a bad script encrypts or wipes filesEverything it can reach, including connected drives and synced foldersA copy it cannot reach or change
The laptop is stolen, or the house floodsEverything in that placeA copy somewhere else
You lose the password or key to an account or encrypted driveEverything behind itA key stored separately, or a copy you can open without it

No single copy handles every row. That is where the 3-2-1 rule comes from.

The 3-2-1 rule ​

text
  3 copies of your data        the original + 2 backups
  2 different kinds of storage  e.g. laptop SSD + external disk
  1 copy somewhere else         e.g. the cloud, or a disk at work

Here is what that looks like for a home user with a laptop:

text
  ┌──────────────┐   weekly copy    ┌──────────────────┐
  │ Laptop SSD   │ ───────────────▶ │ External disk    │  at home, unplugged
  │ (original)   │                  │ (backup 1)       │  between backups
  └──────┬───────┘                  └──────────────────┘
         │ uploads new files
         ▼
  ┌──────────────┐
  │ Cloud folder │  somewhere else (backup 2)
  └──────────────┘

A burned disc or a USB drive kept at a relative's house also counts as the "somewhere else". What matters is that one event, a fire, a theft or one bad command, cannot reach all three copies.

Backup, sync and archive are different things ​

People use these words as if they were the same. They are not.

SyncBackupArchive
GoalThe same files on every deviceGet files back after a lossKeep files you no longer use, for years
When you delete a fileDeleted everywhereOlder backups still have itNot affected
When a file is damaged or encryptedDamaged copy spreads everywhereOlder versions are cleanNot affected
Original still exists?Yes, on every deviceYesOften not: the archive is the copy

Why sync is not a backup ​

A sync tool's job is to make two places match. It does that job equally well when the change is a mistake. Here is a one-way sync with rsync --delete, a common way to "back up" a folder:

bash
rsync -a --delete Photos/ Mirror/     # make Mirror match Photos
rm Photos/cake.jpg                    # a mistake
rsync -av --delete Photos/ Mirror/    # the next "backup" run
text
sending incremental file list
deleting cake.jpg

sent 104 bytes  received 31 bytes  270.00 bytes/sec
total size is 17  speedup is 0.13

deleting cake.jpg: the mistake reached the "backup" on the next run. The same happens if ransomware encrypts Photos: the next sync copies the encrypted files over the good ones. Delta View's Mirror left → right mode deletes files on the right in the same way, which is why it shows a preview and asks you to confirm. See Synchronize folders.

Sync is still useful: it keeps your devices in step. It is not the copy to rely on after a loss.

Versions: going back in time ​

A good backup keeps versions: several copies from different days. If you notice on Friday that a file was ruined on Tuesday, you restore Monday's copy.

A simple scheme keeps:

  • a copy for each of the last 7 days,
  • one for each of the last 4 weeks,
  • one for each of the last 12 months.

Backup tools call this retention. For example, lmdb-lws-backup, which backs up a database on a server, keeps 30 daily backups by default and deletes the oldest first, but never deletes the newest ones, even after an outage.

Many cloud services keep earlier versions of a file for a while. How long varies by service and plan, so check yours before you depend on it.

Encryption: protect the copy, keep the key ​

A backup is a full copy of your private life: photos, documents, tax papers, sometimes passwords. An external disk left in a bag, or a cloud account that is broken into, exposes all of it. Encrypt backups that leave your control:

  • Whole-disk encryption for external drives: LUKS on Linux, BitLocker on Windows. The disk is unreadable without the password.
  • Encrypting backup tools, which encrypt each backup file. lmdb-lws-backup, for example, encrypts every backup as it writes it, so no unencrypted copy ever lands on the disk, and checks each one after writing.

Encryption moves the risk to the key. As the lmdb-lws-backup guide puts it, if you lose the key, every backup is permanently unreadable. So:

  • keep a copy of the key or password away from the backups, for example in a password manager;
  • test that the stored copy works, by restoring or verifying a backup with it;
  • when you change the key, keep the old one for as long as backups made with it exist.

See Keys and security for how one tool handles this.

Where CloudDrop fits ​

CloudDrop uploads everything in one folder to your own cloud storage. It is upload-only: changes go one way, from your computer to the cloud, and it never deletes anything in the cloud. That makes it very different from a sync folder:

You do on your computerWhat CloudDrop does in the cloud
Add a fileUploads it
Edit a fileUpdates the same cloud file
Delete a fileKeeps it. The file becomes cloud-only and stays listed on the Files page
Put a different file where a cloud-only one wasUpdates it, and keeps the old content

So the delete mistake from the rsync example does not spread: a file deleted on your computer stays in the cloud, and you bring it back with Download on the Files page. See How upload-only works for every case.

Three things to understand before you count CloudDrop as one of your 3-2-1 copies:

  • Edits go up. If a file that is still on your computer is changed, by you or by ransomware, CloudDrop uploads the change like any edit. Whether you can get the earlier content back then depends on your cloud's own version history.
  • A delete is not a checked operation. If you delete a file before its upload has finished, there may be no complete cloud copy.
  • Freeing space leaves one copy. Free Up Space removes the copy on your computer only after checking that the cloud holds identical content. After that, the cloud copy is the only copy. It is safe from CloudDrop, which never deletes in the cloud, but not from you or anyone else with access to the account. A freed file is stored, not backed up. If it matters, keep another copy elsewhere. See Free up space safely.

Test a restore ​

A backup you have never restored is a hope, not a backup. Backups fail quietly: a disk fills up, a password expires, a folder was never included. The only proof is getting files back.

A restore test, by hand:

  1. Pick a folder you care about and note what is in it.

  2. Restore it from your backup to a new place, never over the original.

    Here the backup is a dated archive of the Photos folder, made earlier with tar -czf photos-2026-11-09.tar.gz Photos. Restore it into a test folder:

    bash
    mkdir restore-test
    tar -xzf photos-2026-11-09.tar.gz -C restore-test
  3. Compare the restored folder with the original.

    bash
    diff -r Photos restore-test/Photos && echo "identical"
    text
    identical

    diff -r prints nothing when the two folders match (so echo runs), and lists every difference when they do not, for example Only in Photos: new.jpg for a file added since the backup. Delta View does the same with a window: compare two folders and read the modified, left only, right only and identical counters.

  4. Open a few of the restored files, to be sure they are readable, not just present.

Do this once when you set up a backup, then every few months, and after any change to how you back up. Tools for servers often build it in: lmdb-lws-backup decrypts and reads every backup right after writing it, and its --verify option checks an older one on demand.

Stay safe ​

  • Never restore over the original. Restore to a new folder, compare, then move what you need.
  • Unplug the backup disk between backups, so ransomware or a wrong command cannot reach it.
  • Do not rely on sync, RAID (several disks working as one, so a dead disk does not stop the computer) or a second copy on the same disk. All of them repeat your mistakes at once, or fail together.
  • Keep keys and passwords apart from the backups, and check that you can still open them.
  • Know what you have freed. After CloudDrop's Free Up Space, the cloud copy is the only copy; keep access to the account and do not delete the CloudDrop folder in the cloud.

Check yourself ​

QuizBackups that work

Question 1 of 6

Which setup follows the 3-2-1 rule?

Score: 0

What you learned ​

  • 3-2-1: three copies, on two kinds of storage, one somewhere else.
  • Sync copies mistakes and encryption by ransomware; a backup keeps older versions.
  • Encrypt backups that leave your control, and store the key separately.
  • CloudDrop never deletes in the cloud, but edits still go up, and freed files have only one copy.
  • Test a restore into a new folder and compare it with the original.

Next steps ​