When I think about defense‑in‑depth, the last line of the fence is always the backup. If everything else fails, a good backup is the only thing that can keep you from losing data completely. The 3‑2‑1 rule is the classic recipe, but it’s easy to treat it as a checklist and miss the details that actually make it work.

What 3‑2‑1 Really Means

Three copies of your data: the primary set you work with every day, plus two separate backups. Two different storage media: one might be a local external drive, the other a cloud bucket or a NAS. One copy off‑site: that copy lives somewhere you can’t lose it to a fire, flood, or a stolen laptop.

Sounds simple, right? The devil is in the implementation. I’ll walk through each piece, the typical mistakes, and a concrete way to get it right.

1. Three Copies – No Shortcut

The primary data is obvious – it lives on your workstation or a server. The first backup is usually a direct copy on a separate drive. The second backup is often a snapshot or an image stored elsewhere. The key is that the two backups are not just two folders on the same disk. If that disk dies, you’ve lost everything.

In practice I use rsync for the first local copy and restic for the second, encrypted copy. Here’s a quick snippet that I run nightly:

# sync to a second internal drive (e.g., /mnt/backup1)
rsync -a --delete /home/andrei/ /mnt/backup1/home/

This keeps the local copy identical to the source. The --delete flag makes sure you don’t accumulate old files that you already removed.

2. Two Different Media – Keep It Diverse

Most people put both copies on external USB drives and think they’re covered. That’s a mistake because USB drives share the same failure modes – voltage spikes, firmware bugs, wear‑out. I prefer to pair a spinning HDD with a solid‑state drive, or a NAS with a cloud bucket. The point is that if one technology fails, the other likely survives.

For the second backup I push the data to a cloud bucket using restic. Restic handles encryption and deduplication, which saves bandwidth and storage.

# initialize a remote repository (e.g., S3 bucket)
restic -r s3:s3.amazonaws.com/your-bucket init

# backup the same data to the remote repo
restic -r s3:s3.amazonaws.com/your-bucket backup /home/andrei

The command line is short, but the underlying setup (AWS credentials, bucket policy) takes a few minutes to get right. I usually store the credentials in ~/.aws/credentials and keep the bucket private.

3. One Off‑Site Copy – Test It

Having a copy in another location is the whole reason for 3‑2‑1. I have a small office in a different city, so I ship a hardened external drive there once a month. If you’re a solo home labber, you can drop a drive at a trusted friend’s house, or use a low‑cost cloud provider.

The important thing is that you actually verify the off‑site copy. A broken USB cable or a corrupted bucket can render the backup useless. Every quarter I run a restore test:

# restore a random file from the remote repository
restic -r s3:s3.amazonaws.com/your-bucket restore latest --target /tmp/restore-test --include path/to/file.txt

If the file comes back intact, I know the chain is solid. If not, I investigate the error right away – better than discovering the problem when you need the data.

Automation Saves Your Bacon

I keep the backup scripts in a simple cron job. Nothing fancy, just reliable:

# crontab entry – run at 2 am every day
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

The backup.sh script contains the rsync and restic commands above, plus a log rotation step. I also add a health check URL so I get a ping if the job fails. It’s a tiny addition that catches a lot of silent failures.

Common Pitfalls and How I Avoid Them

• Copying to the same filesystem. I always mount the backup drive to a separate mount point and double‑check with df -h before running the job.
• Leaving backups unencrypted. Restic handles encryption automatically; for local drives I use cryptsetup with LUKS.
• Forgetting to rotate off‑site media. Monthly swaps keep the drive fresh and mitigate drive‑age failures.
• Assuming “cloud” equals safe. I verify bucket policies and enable MFA delete where possible.

Putting It All Together

My final backup plan looks like this: primary data on the main workstation, a nightly rsync to a local USB‑3 HDD, a daily encrypted upload to an S3‑compatible bucket using restic, and a monthly rotation of a sealed external SSD that I ship to a friend’s house. The whole system runs on a cron job, logs to /var/log, and I test restores quarterly.

If you’re just starting, pick one piece and make it reliable before adding the next. Don’t try to buy the most expensive drive for each layer; use what you have, but keep the diversity and off‑site aspect real. That’s the essence of the 3‑2‑1 rule – it’s not a buzzphrase, it’s a practical safety net.

And that’s where I land on backups. No fancy jargon, just a few commands, a bit of discipline, and you’re ready for the worst case.

Photo by Jakub Zerdzicki on Pexels