Table of Contents

• The 3-2-1 Backup Strategy for Homelabs

• Understanding the 3-2-1 Rule

• Our Backup Architecture

• Proxmox Backup Server

• ZFS Snapshots and Replication

• Database Backups

• Configuration as Code

• Offsite Backup

• Testing Your Backups

The 3-2-1 Backup Strategy for Homelabs

Data loss can happen in an instant. A failed drive, a mistaken deletion, ransomware. Without backups, your homelab progress disappears. This guide covers implementing a proper backup strategy.

Understanding the 3-2-1 Rule

The 3-2-1 backup rule states you should have three copies of data, on two different media types, with one copy offsite. This protects against drive failures, natural disasters, theft, and human error.

For homelabs, this means your production data plus two backups, stored on different media, with one backup at a remote location.

Our Backup Architecture

Production data lives on TrueNAS with ZFS. ZFS provides checksums to detect silent data corruption. Snapshots provide point-in-time recovery. Replication sends data to our secondary TrueNAS.

Proxmox Backup Server backs up all VMs and containers. It deduplicates data to minimize storage requirements. Backups are pushed to the secondary TrueNAS.

Git repositories sync to GitHub. Database containers run automated dumps to backup volumes before snapshots occur.

Proxmox Backup Server

PBS connects to our primary Proxmox cluster. It uses a datastore on the secondary TrueNAS. Each node backs up to PBS automatically.

Backup schedules run daily for most VMs. Critical VMs back up every four hours. Retention policies keep daily backups for a week, weekly for a month, monthly for a year.

Restore testing happens quarterly. We randomly select VMs and restore to a test environment to verify backup integrity.

ZFS Snapshots and Replication

ZFS snapshots are point-in-time captures of a dataset. They take seconds to create and use minimal additional space. Snapshots can be mounted read-only to recover individual files.

We schedule hourly snapshots for active datasets. Daily snapshots for archival data. Monthly snapshots for retention. Old snapshots are automatically pruned.

ZFS replication streams snapshots to our secondary TrueNAS via SSH. The secondary has a matching dataset hierarchy. Replication runs every hour during business hours.

Database Backups

Database containers need special handling. We use automated scripts that run before ZFS snapshots. Scripts use database-native tools for consistency.

PostgreSQL databases dump to SQL files with pg_dump. MySQL uses mysqldump. MongoDB uses mongodump. Each dump is compressed and timestamped.

Dump files go to a backup volume that is snapshotted with ZFS. This ensures database consistency in restores.

Configuration as Code

Configuration files are code. We store all configuration in Git repositories. Proxmox configuration, Docker Compose files, pfSense configs, everything.

This provides version history for configuration. Reverting a bad change takes seconds. Disaster recovery includes not just data but working configurations.

Ansible automates configuration deployment. Fresh installs can be provisioned from Git with a single command.

Offsite Backup

Cloud backups protect against site-wide failures. We use Rclone to sync critical data to B2 Cloud Storage. B2 is cheap and reliable.

Rclone runs daily during off-peak hours. Bandwidth throttling prevents interference with normal usage. Encryption protects sensitive data before upload.

Offsite backups include documents, photos, and configuration archives. VM backups are too large for practical cloud sync.

Testing Your Backups

Backups that are not tested are not backups. Quarterly restoration tests verify our backup procedures work. We document the restore process to ensure it is repeatable.

Random VM restores to our test environment happen monthly. These catches issues like failed backup jobs or corrupted data before they become critical.

Documentation includes estimated restore times. This helps set expectations during actual outages.