How I built my backup system

Self-hosting your digital life feels great. You control the services, the data, and the entire infrastructure behind it. But that freedom also comes with a quiet responsibility: if something breaks, there’s no company behind the curtain fixing it for you.

Once that realization hits, backups stop being a “nice to have” and quickly become one of the most important parts of the whole setup.

Backups became real once I owned the stack

Ever since I started moving my entire digital life into a self-hosted setup, one thought kept popping up in my head:

If I control the infrastructure, I also become responsible for protecting it.

My services run on a NAS, which already gives me a good level of fault tolerance. The drives are configured in RAID 5 with four disks, so if one fails, the system keeps running and I can simply replace it. At first glance that sounds safe.

But there’s a very important distinction here.

Redundancy is not the same thing as backups.

RAID protects you from hardware failure, not from things like accidental deletion, corrupted data, ransomware, or a catastrophic event affecting the whole device. If the NAS disappears, the RAID array disappears with it.

A proper backup strategy needs something more structured.

The 3-2-1 backup rule

A widely accepted approach is the 3-2-1 backup strategy:

• 3 copies of your data: the original plus two backups
• 2 different storage media: for example NAS + external drive
• 1 copy stored off-site: somewhere physically separate from the main location

The goal is simple: a single failure should never destroy your data.

Once I looked at my setup through that lens, it was clear that RAID alone wasn’t enough.

Taking stock of what actually matters

At this point my NAS had already become the center of my digital life.

All my photos live there.
My music library too.
Containers and their configurations.
Work documents.
School projects.
Family trip videos.

Basically everything I cannot reproduce or download again.
All in all, we’re talking about roughly 2.5 TB of data.

So I sat down and defined two clear goals:

1. Create an on-site backup of the entire NAS; and
2. Create an off-site backup of the truly essential data;

Let’s start with the simpler one.

The on-site backup

My NAS runs four 8 TB drives in RAID 5. That leaves me with roughly 21 TB of usable capacity and protection against a single drive failure.

To create a local backup, I kept things intentionally simple.

I bought a 10 TB hard drive and one of those hot-swap drive docking stations. The dock stays connected to the NAS and ready at all times, but the disk itself stays unplugged and safe somewhere else.

Whenever I want to perform a backup, I simply:

1. Insert the drive;
2. Run a sync from the NAS;
3. Remove the drive again;

That’s it.

No complicated infrastructure. Just a separate copy of the entire NAS stored on a different medium.
Simple systems tend to fail less.

The off-site backup

This is where things get a bit more interesting. And complicated too. But exciting nonetheless.

Instead of buying new hardware, I reused two 4 TB drives from an old PC build. These went into a two-bay drive enclosure connected via USB 3 to a Raspberry Pi 4 that I also had sitting in a drawer for quite some time. It was just waiting for some project like this, really.

Even though the enclosure itself supports RAID, I ignore that feature completely and run it in JBOD mode—Just a Bunch of Disks.

The Raspberry Pi manages everything, not the enclosure.
On the Pi, I installed Raspberry Pi OS Lite and a few packages, the most important one being cloudflared.

If you know where this is going already, you’re probably smiling by now.

The Cloudflare tunnel trick

cloudflared creates a Cloudflare Tunnel that exposes the Pi through a subdomain like backup.mydomain.com. But here’s the interesting part: Accessing that address from a browser returns nothing.
Trying to reach it normally over SSH also returns nothing.

The only way in is through SSH over the Cloudflare tunnel, which also gives me end-to-end encryption, as a bonus.

In practice, the device isn’t exposed to the public internet at all. Only those with access to this specific tunnel—that’s me—will be able to even reach the SSH front door.

But even then…

Encrypting the backup drives

Before using the drives, I encrypted them and configured them in RAID 1. This means both disks are identical mirrors of each other.

Again, the RAID is managed by the Pi, not the enclosure.
And, the drives stay locked by default.

To perform a backup I need to:

1. Unlock the encrypted drives;
2. Mount the volume;
3. Run the data sync;
4. Unmount everything;
5. Lock the drives again;

This adds friction, but in this specific case friction is actually desirable. Convenience is not the priority here—privacy and safety are. Although you could also argue that without convenience backups don’t happen frequently enough in the first place. And that would be fair.

But for me, the most important aspect is that if someone physically gets the drives, the data is useless without the encryption key. And the key is not locally stored neither in the drives, nor in the Pi.

Even if someone somehow compromised the Raspberry Pi itself, the disks would still be locked most of the time.

Why the backup is manual

At first I considered automating everything with a cron job using rsync from the NAS. But I intentionally chose not to automate it.

The reason is simple: I don’t want corrupted data, accidental deletions, or mistakes to automatically propagate to the off-site backup.

This is the “when everything goes wrong” backup. If all goes well, I should never need to restore from it.

Manual syncing also forces me to be present for the process:

• unlock the drives;
• mount them;
• run the transfer;
• lock them again;

It’s a bit more work, but this is exactly the kind of place where convenience can backfire.

Thinking through the attack surface

With this setup, gaining unauthorized access would require a very specific chain of events, which are very unlikely to happen.

An attacker would need to:

1. Gain access to the Raspberry Pi;
2. Wait for a backup session where the drives are unlocked;
3. Somehow bypass the Cloudflare Tunnel restrictions;

That combination of events is extremely unlikely. And even then, the window of opportunity would be very small.

Peace of mind

With this strategy in place, I now have:

• The NAS itself
• A full local copy of the NAS
• An off-site encrypted backup of the most important data

If the NAS dies, I can recover quickly from the on-site copy.
If something catastrophic happens and both are lost, I still have a safe off-site backup of what truly matters to me.

There is no such thing as a 100% secure system, and I’m definitely not a security expert. But for a personal setup, this gives me a level of redundancy and protection that feels solid enough to sleep well at night.

Takeaways

The biggest lesson here is that RAID is not a backup. It protects against disk failure, but it does nothing for accidental deletions, corruption, or disasters affecting the entire device. A proper backup strategy needs multiple copies in multiple places.

Following the 3-2-1 rule gives a strong baseline: keep three copies of your data, store them on two different media, and keep at least one copy off-site. This drastically reduces the chances of losing everything.

Finally, simplicity beats cleverness in backup systems. A straightforward setup that you actually maintain is far more valuable than a complex system that silently breaks or propagates mistakes.