Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests

The most expensive homelab lesson is learning that redundancy is not backup. RAID can keep a storage pool online after a disk fails. Snapshots can roll back a dataset after a bad change. Neither one saves you by itself from deletion, ransomware, theft, fire, bad sync jobs, or a backup tool that was never tested.

Backups are not glamorous, but they are the difference between a hobby outage and losing family photos, documents, configs, keys, and years of work. CISA's ransomware guidance and backup guidance both stress recoverability, separation, and testing. NIST also publishes guidance on protecting data from ransomware and other data-loss events. The homelab version should be practical, not performative.

Design principle: Your backup is not real until you restore from it. Build the plan around recovery, not around feeling protected.

Reference diagram
Homelab Backup Architecture
A real backup plan has versioning, separation, offsite or offline copies, and tested restores.
Sources VMs / apps / NAS Snapshots fast rollback Local Backup PBS / NAS / disk Offsite Copy cloud / remote NAS Offline Copy rotated USB disk Restore Test prove recovery Snapshots are useful. They are not the backup by themselves.Restore path must be practiced before failure day.
3-2-1 shape
Three copies, two media or systems, one offsite or offline.
Protect credentials
Backup jobs should not be able to delete every copy everywhere.
Restore drills
A backup is a theory until a restore proves it.

What To Back Up

Data ClassExamplesBackup Priority
Irreplaceable personal dataPhotos, documents, scans, family videos, keysHighest. Multiple copies, offsite, restore tested.
Service configsDocker compose, app databases, firewall exports, controller backupsHigh. Small data, huge recovery value.
VMs and containersProxmox VMs, LXCs, app hostsHigh for critical services, selective for disposable labs.
Media librariesLarge replaceable mediaDepends on rebuild cost, bandwidth, and personal value.
SnapshotsZFS/Btrfs/NAS snapshotsUseful for fast rollback, but not enough alone.

A Practical 3-2-1 Shape

  • Primary copy: the live data on your NAS, server, or application host.
  • Local backup copy: a separate backup target such as Proxmox Backup Server, a NAS share, or a dedicated backup disk.
  • Offsite copy: cloud object storage, a remote NAS, or rotated disk stored away from the house.
  • Offline or immutable layer: a copy that routine credentials cannot rewrite or delete.
  • Restore test: a scheduled proof that the data can actually come back.

Backup Architecture Patterns

PatternGood ForWatch Out For
Proxmox Backup ServerVM and LXC backups with dedupe and retentionStill needs offsite replication or export.
NAS snapshots plus replicationFast rollback and remote NAS copiesSnapshots on the same box are not enough.
Restic / Borg / KopiaEncrypted file-level backups to local or cloud targetsTest restore speed and retention policies.
Rotated USB diskOffline copy protected from online mistakesNeeds calendar discipline and encryption.
Cloud object storageOffsite durabilityCosts, egress, lifecycle rules, and credentials need design.

Credential Design

The backup job should not hold unlimited power over every copy. If malware, a bad script, or a compromised host can delete the primary data and all backups with the same credentials, the backup design is fragile. Use separate credentials for writing backups, restrict deletion where possible, and protect cloud or NAS admin accounts with MFA and hardware keys.

Restore Drill

  1. Pick one small but real service, such as a wiki, DNS resolver, or test VM.
  2. Record the current version, data path, database path, and expected behavior.
  3. Restore it to an isolated test host or separate VM name.
  4. Verify the app starts, data is present, logins work, and dependencies resolve.
  5. Record restore time, missing steps, surprises, and exact commands.
  6. Fix the backup job or documentation immediately while the lesson is fresh.

Example Restic Flow

# Initialize once
restic -r sftp:backup.example.com:/backups/homelab init

# Back up app configs and important data
restic -r sftp:backup.example.com:/backups/homelab backup \
  /srv/docker \
  /etc \
  /home/dan/Documents

# Prove you can see snapshots
restic -r sftp:backup.example.com:/backups/homelab snapshots

# Restore a snapshot to a test path
restic -r sftp:backup.example.com:/backups/homelab restore latest \
  --target /tmp/restore-test

Monitoring

  • Alert when a backup job fails.
  • Alert when no successful backup has completed within the expected window.
  • Alert when the backup target is low on space.
  • Log retention pruning so it does not silently remove more than intended.
  • Schedule quarterly restore tests for critical data.

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

NeedGood ChoiceWhy It FitsAffiliate Link
NAS chassisSynology, QNAP, TrueNAS, or DIY NASCentral backup target and storage platform. Pick by maintenance appetite and drive needs.Search Amazon: 2 bay 4 bay NAS
NAS drivesWD Red Plus or Seagate IronWolf CMR drivesDesigned for NAS workloads. Avoid mystery drives for important data.Amazon: WD Red Plus 8TB
Amazon: Seagate IronWolf 8TB
Portable offline copySamsung T7 Shield or external HDDGood for encrypted rotated backups and grab-and-go recovery copies.Amazon: Samsung T7 Shield 2TB
Search Amazon: external backup drive
UPSAPC or CyberPower UPSProtects against dirty shutdowns while backups or writes are running.Amazon: CyberPower CP1500PFCLCD
Amazon: APC BR1500MS2

Common Mistakes

  • Believing RAID is backup.
  • Backing up only files and forgetting app databases.
  • Backing up to the same host with the same admin credentials.
  • Never restoring until the day everything is broken.
  • Forgetting encryption keys, recovery codes, and password vault exports.
  • Letting backup jobs silently fail for months.

References

Final Thought

A homelab backup strategy should be boring, visible, and practiced. You do not need a perfect enterprise disaster recovery program on day one. You do need copies that survive the failure you are afraid of, credentials that cannot erase every layer, and a restore drill that proves the plan before it becomes urgent.

This article is part of the TechGeeks homelab foundation series. The series is designed to build practical home infrastructure in the right order: remote access, segmentation, exposure control, DNS, IoT isolation, and recoverable backups.

Need help applying this?

Bring TechGeeks into the real environment.

If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.

Request helpGet field notesRecommended gear

Leave a Reply

Your email address will not be published. Required fields are marked *