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 happens | What it destroys | A copy that survives it |
|---|---|---|
| You delete or overwrite the wrong file | That file, now | An older version of the file |
| The drive fails | Everything on that drive | A copy on another drive |
| Ransomware or a bad script encrypts or wipes files | Everything it can reach, including connected drives and synced folders | A copy it cannot reach or change |
| The laptop is stolen, or the house floods | Everything in that place | A copy somewhere else |
| You lose the password or key to an account or encrypted drive | Everything behind it | A 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
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 workHere is what that looks like for a home user with a laptop:
┌──────────────┐ 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.
| Sync | Backup | Archive | |
|---|---|---|---|
| Goal | The same files on every device | Get files back after a loss | Keep files you no longer use, for years |
| When you delete a file | Deleted everywhere | Older backups still have it | Not affected |
| When a file is damaged or encrypted | Damaged copy spreads everywhere | Older versions are clean | Not affected |
| Original still exists? | Yes, on every device | Yes | Often 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:
rsync -a --delete Photos/ Mirror/ # make Mirror match Photos
rm Photos/cake.jpg # a mistake
rsync -av --delete Photos/ Mirror/ # the next "backup" runsending incremental file list
deleting cake.jpg
sent 104 bytes received 31 bytes 270.00 bytes/sec
total size is 17 speedup is 0.13deleting 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 computer | What CloudDrop does in the cloud |
|---|---|
| Add a file | Uploads it |
| Edit a file | Updates the same cloud file |
| Delete a file | Keeps it. The file becomes cloud-only and stays listed on the Files page |
| Put a different file where a cloud-only one was | Updates 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:
Pick a folder you care about and note what is in it.
Restore it from your backup to a new place, never over the original.
Here the backup is a dated archive of the
Photosfolder, made earlier withtar -czf photos-2026-11-09.tar.gz Photos. Restore it into a test folder:bashmkdir restore-test tar -xzf photos-2026-11-09.tar.gz -C restore-testCompare the restored folder with the original.
bashdiff -r Photos restore-test/Photos && echo "identical"textidenticaldiff -rprints nothing when the two folders match (soechoruns), and lists every difference when they do not, for exampleOnly in Photos: new.jpgfor 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.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
Question 1 of 6
Which setup follows the 3-2-1 rule?
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
- Recovering lost files: what to do when there was no backup
- CloudDrop beginner guide
- How upload-only works