Constructing a Backup

Jump to Examples

I have mentioned the 3-2-1 rule in almost every note so far, so it was about time to write the note itself. Backup is one of those things everybody agrees with and almost nobody does properly – me included, for many years. I had copies, sure. Copies on the same disk, copies on a USB stick in the same drawer as the laptop, and one very old copy on a DVD that I am not sure any of my computers can still read.

The honest test of a backup is simple: if this disk dies right now, or the laptop gets stolen, or a ransomware encrypts everything – what exactly do I lose, and how long does it take to get it back? If the answer is "I don't know", there is no backup yet.

From Tapes to Snapshots

Backup is as old as storing data. The first computers kept their data on punched cards and magnetic tape, and copying a tape to another tape was the backup. IBM's first tape drive for computers, the IBM 726, came out in 1952 – and tape is still here today. Big data centres keep huge libraries of LTO cartridges, because a tape on a shelf is cheap, lasts for decades and cannot be hacked while it is not in a drive.

At home it went from floppy disks to CDs and DVDs, then to external hard disks, and now to NAS boxes and the cloud. What really changed is not the media but the way of copying. Old backups copied everything, every time. Modern tools split files into small pieces, store every piece only once (deduplication) and keep many snapshots – the state of your files on a certain day – for almost no extra space. That is why I can keep a year of daily backups of my documents on a disk that would hold only two or three full copies.

My favourite backup story is from Pixar. In 1998, during the work on Toy Story 2, somebody ran a delete command on the server with the film's files, and most of the film disappeared. Then they found out that the backups had not been working for a while. The film was saved because technical director Galyn Susman had a copy on her computer at home, where she worked after her baby was born. A whole film saved by luck. Don't build your plan on luck.

What Is Not a Backup

• RAID. Two mirrored disks protect you from one dead disk. If you delete a file, or a virus encrypts it, the mirror deletes or encrypts it too – instantly and very reliably. How RAID works is in How Storage Works.
• Sync (OneDrive, Dropbox, Google Drive, Syncthing). Same as RAID, only over the network. A deleted file is deleted everywhere. Some services have a recycle bin or file versions for a few weeks – useful, but that is their rule, not yours.
• A copy on the same disk. Protects only against your own mistakes, never against the disk.
• A backup you never tried to restore. This is the Pixar case. Until you have restored a file from it, it is only a hope.

The 3-2-1 Rule

The rule is usually credited to photographer Peter Krogh, who wrote about managing digital photos in the 2000s, and it is still the best short answer:

• 3 copies of your data – the original and two backups,
• 2 different kinds of storage – for example the laptop's SSD and a NAS,
• 1 copy in another place – at a friend's, at work, or in the cloud (encrypted!).

Today people often add a 0 and another 1: one copy offline or immutable (ransomware can't touch a disk that is not connected) and 0 errors after a test restore. For me at home that means:

1. Laptop and PC – the originals.
2. Synology NAS at home – automatic backup every night (Example 1), with a test restore every three months (Example 2).
3. An external USB disk that I connect once a month and then put away – this is the offline copy.
4. An image of the whole system disk before anything big – a new SSD, a big Windows update, a new Linux (Example 3).
5. An encrypted copy of the most important folders outside the house (Example 4).

What AI Changed

A few years ago this note would end with the rule above. Today AI already plays a big role in backup – on both sides.

• The attackers got faster. Phishing e-mails without spelling mistakes, in perfect Slovenian, and malware written or changed with the help of AI. Ransomware is not a "big company problem" any more – it is cheap to run against everybody. The offline copy and the copy outside the house are the answer to that, not a better antivirus.
• AI agents now have hands. An assistant that can run commands and change files can also delete them. In July 2025 a well-known case went around the Internet: an AI coding agent on Replit deleted the database of a project during a "code freeze", and then said it could not be undone. Luckily, the platform's own rollback brought it back – a backup saved the day again. My rules: before I let an AI tool work on a folder, there is a fresh snapshot; and no AI tool (and no script it wrote) ever gets the password or write access to the backup repository.
• The defenders use it too. Bigger backup products (Acronis, Veeam and others) use machine learning to notice when files suddenly start changing like ransomware does – thousands of files rewritten in minutes, the content turning into random-looking bytes – and they stop the process or warn you. Even without that, a simple check helps: if tonight's backup is suddenly ten times bigger than usual, something happened.
• It helps me write the boring parts. The restic commands, the systemd timer, a script that e-mails me when the backup fails – an AI assistant writes them in a minute and explains every line. But I read them before running, I never paste passwords into a chat, and the test restore is still mine to do. An AI can tell you that the backup "should work"; only a restored file proves it.
• The things I make with AI are data too. Prompts, project notes, custom instructions and skills (see Tokens and Context) live on somebody else's server. What I would miss goes into a normal folder – and then into the normal backup.

Examples

Example 1: Backup to a NAS with restic

restic is one program file with no installation. It encrypts everything, makes snapshots and deduplicates. The backup place is called a repository; it can be a folder on a disk, a NAS share over SFTP or a cloud service. On Linux the NAS share is mounted at /mnt/nas/backup in this example; on Windows the same works with a drive letter, for example Z:\restic.

# once: create the repository (restic asks for a password - write it down somewhere safe!)
restic init --repo /mnt/nas/backup/restic

# every day: back up the folders that matter
restic -r /mnt/nas/backup/restic backup ~/Documents ~/Pictures ~/Projects

# what do I have?
restic -r /mnt/nas/backup/restic snapshots

# keep 7 daily, 4 weekly and 12 monthly snapshots, delete the rest
restic -r /mnt/nas/backup/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# check that the repository is not damaged
restic -r /mnt/nas/backup/restic check

The password is the backup. Without it, the encrypted repository is just random bytes, also for you. Mine is in KeePassXC, and the KeePassXC file itself is part of the backup – and there is a printed copy of the master password in a place my family knows about.

To run it every night on Linux, the same systemd timer as in Constructing a Program works fine. The password can be given in a file with --password-file that only root can read.

Example 2: The Test Restore

This is the part everybody skips. Restore into a different folder, never over the originals:

# restore the last snapshot into a test folder
restic -r /mnt/nas/backup/restic restore latest --target /tmp/restore-test

# or only one folder from it
restic -r /mnt/nas/backup/restic restore latest --target /tmp/restore-test --include /home/jernej/Documents/Invoices

Then actually open a few files – a photo, a spreadsheet, something old. A file that is there but damaged is not restored. I put a reminder in the calendar to do this every three months.

Example 3: An Image of the Whole Disk

File backup is great for documents, but when a system disk dies, I don't want to reinstall Windows and fifty programs. So before I change anything big on a computer – a new SSD, a big upgrade, a new operating system – I make an image of the whole disk with Clonezilla. It is free, it runs from a USB stick, and it copies only the used parts of the disk, so a 1 TB disk with 200 GB of data gives an image of less than 200 GB. If you prefer clicking to menus, Rescuezilla does the same with a normal window and mouse.

1. Make the USB stick. Download the Clonezilla live ISO (the stable amd64 version) and write it to a USB stick with Rufus or balenaEtcher.
2. Connect an external disk with more free space than the used space on the computer's disk. This is where the image goes.
3. Boot from the USB stick (the boot menu key is usually F12, F11, F8 or Esc right after power on).
4. Save: device-image → local_dev → choose the external disk → Beginner → savedisk → give the image a name with the date → choose the computer's disk → say yes to checking the image at the end.
5. Restore when needed: the same way, but restoredisk. The target disk must be at least as big as the original one. Clonezilla asks twice before it overwrites – read the disk names and sizes carefully both times, because restore deletes everything on the target.

One trap on Windows: if the disk is encrypted with BitLocker (many new laptops do it automatically), Clonezilla cannot see which parts are used and copies the whole disk, sector by sector – slower and bigger. And after a restore, Windows may ask for the BitLocker recovery key. Find it before you start (for a Microsoft account it is at aka.ms/myrecoverykey) and keep it in the password manager.

Example 4: A Copy Outside the House

Fire, flood or burglary take the computer and the NAS at the same time. That is why the "1" in 3-2-1 is there. Three ways to do it, from the most comfortable to the simplest:

A second NAS at a family member's place. On a Synology this is Hyper Backup: on the other NAS you install Hyper Backup Vault, and on yours you create a backup task with "Remote Synology NAS" as the target. Two settings matter: turn on client-side encryption (Hyper Backup then gives you a key file – keep it outside the NAS, otherwise it burns together with it), and set the version rules so that older versions are kept for weeks and months, not only the last one. The family member gets the same in return: their backup on my NAS. Nobody can read the other's data, because it is encrypted before it leaves the house.

An encrypted restic repository in the cloud. restic can use any cloud that Rclone knows (more than 70 of them). Set up the cloud once with rclone config – here it is called cloud – and the rest is the same as in Example 1:

# once
restic -r rclone:cloud:restic-backup init

# every night, only the folders that really matter
restic -r rclone:cloud:restic-backup backup ~/Documents ~/Pictures

restic encrypts everything before upload, so the cloud provider sees only random bytes. That's the difference from simply syncing a folder to OneDrive: there the provider (and anybody who gets into the account) can read everything, and a deleted file is deleted in the cloud too.

A USB disk in a drawer at work. No network, no account, no subscription. Two disks, swapped once a month: one is at home being written, the other is far away. It is not automatic, so a reminder in the calendar is part of the setup.

Whichever way: write down how to get the data back – where the backup is, which password or key file opens it, and which program to use. Put that in the password manager and on paper. A backup only you can restore is not much help to your family if something happens to you.

A Few More Thoughts

The good thing about backup is that it is boring once it works. The tools are free and very good; the hard part is deciding what matters and then checking now and then that the copies are really there. Start small: one folder, one external disk, one test restore this week. That is already more than most people have.

And with AI the advice has become more important, not less. The more tools can change our files on their own – helpful assistants as well as ransomware – the more it is worth having one copy that nothing can reach: encrypted, versioned, and sometimes simply unplugged.