Data backups are one of those things everyone knows they should take seriously—but in practice, they often end up inconsistent, manual, and easy to neglect. For a long time, I relied on the well-known 3-2-1 backup strategy. While it worked on paper, it didn’t scale well in real life. I always told myself I would create monthly backups: copying to one drive, replicating it to two more, and storing these offsite. However, this process was time-consuming, and my last backup ended up being two years ago.

This post walks through how I transitioned to a fully automated backup architecture that delivers the same reliability—with far less effort and much more peace of mind.

My Old Approach: Manual and Time-Consuming

Previously, my setup looked like this:

1. Primary data stored on my main system.
2. Copies written to external hard drives (three in total), initially via copy-and-paste but later improved using an rsync script.
3. Offsite backups stored in protective cases across different locations.

While effective, this approach had a major drawback: it relied heavily on manual effort. Drives needed to be rotated, transported, and updated regularly. As my data grew, maintaining this system became increasingly difficult.

New Automated Approach

With a 200 Mbps up/down internet connection at home, I decided to modernize my backup setup. My goal was to have backup servers that could replicate data automatically, reducing manual effort and improving reliability.

Goals

• Reduce manual effort
• Increase backup frequency
• Maintain or improve redundancy

New Backup Architecture

My new backup architecture consists of:

1. Onsite Backup Server (Primary Storage)
2. Offsite Backup Server (Remote Replication Destination)
3. Offline HDD Backup

1. Onsite Backup Server (Primary Storage)

This is a VM running on my Proxmox hypervisor with dedicated 2×8TB WD Red HDDs in a RAID 1 (mirror).

It stores backups of my File Server VM, which contains shared music, movies, photos, and more. Computers on the network also back up here, including an Apple Time Machine share.

2. Offsite Backup Server (Remote Replication Destination)

This server is co-located in a remote datacenter and automatically syncs all backup data from the onsite backup server using rsync.

The hardware is a used Lenovo V530 (AMD Ryzen 3 2200G, 8GB RAM). It has a dedicated NVMe boot disk and 2×8TB WD Red HDDs in RAID 1 running under ZFS. I also replaced the DVD drive with a dummy drive to mount an additional 2.5" SATA HDD, which I mainly use as a scratch drive.

Using ZFS snapshots, I ensure at least three historical snapshots are always available to protect against accidental deletion.

3. Offline HDD Backup

I'll still maintain one offline hard drive as a fail-safe. This drive is disconnected to prevent corruption or malware (e.g., ransomware, viruses). I store it offsite and periodically copy data from the onsite backup server using rsync.

Conclusion

I believe this backup architecture should suit my needs and allows me to have some sort of automated; replicated backups.

All my server config is done with Ansible Playbooks so I can easily re-create or amend any changes quickly.