How data is stored, protected, and backed up. The primary NAS runs ZFS, serving media and personal files to the rest of the lab over NFS. A separate NAS is the dedicated backup target, kept on a different OS and filesystem so that no single failure can take out both the data and the backups. VM snapshots, dataset snapshots, and Restic backups run on overlapping schedules through the night.
The primary NAS runs as a VM on host1, with the three data drives passed through directly so ZFS has raw access to the hardware. The OS disk is separate and not part of the pool, which means the pool survives an OS reinstall and the OS disk can be backed up independently.
ZFS pool| Topology | RAIDZ1, 3 drives |
|---|---|
| Total capacity | 27.3 TB |
| Used | 5.79 TB (21%) |
| Status | Online |
| Last resilver | Recently, completed cleanly |
| Model | Capacity | Status |
|---|---|---|
| Seagate IronWolf 10 TB | 10 TB | Healthy |
| Seagate IronWolf 10 TB | 10 TB | Healthy |
| Toshiba 10 TB | 10 TB | Healthy Replaced Apr 2026 |
One of the original Seagates was approaching a concerning age. It was replaced with a Toshiba IronWolf equivalent in April 2026; the resilver completed without errors.
Datasets| Category | Size |
|---|---|
| Media | 2.1 TB |
| Personal files | 1.1 TB |
| Photos | 596 GB |
| Software | 341 GB |
| Shared files | 109 GB |
| Books | 74 GB |
| Music | ~0 |
All datasets are served over NFS to the application host. The media dataset is the largest and grows steadily; everything else is relatively stable.
ZFS snapshots| Schedule | Retention |
|---|---|
| Daily | 3 days |
| Weekly | 2 weeks |
| Monthly | 2 months |
Snapshots are applied recursively to the entire pool. They are copy-on-write, so they consume no space at creation and only grow as blocks are changed or deleted. This provides fast point-in-time recovery for accidental deletions without needing a full backup restore.
The backup NAS is the off-primary backup destination. It runs a different OS, a different filesystem, and is from a different vendor than the primary NAS, which means a bug, a misconfigured upgrade, or ransomware hitting the primary NAS cannot cascade into the backups. SMB is disabled; it serves NFS only. It is local-only with no remote access and no cloud sync, which means it is not reachable from the primary attack surface.
| Type | Synology NAS |
|---|---|
| OS | DSM |
| Volume | 9.1 TB usable |
| Used | 4.1 TB |
| Protocols | NFS only (SMB disabled) |
| Remote access | None, LAN only |
Proxmox vzdump backups of the primary NAS VM and the backup agent container, both from host1. These are kept separate from the primary NAS data drives to avoid a circular dependency: the NAS cannot back itself up to itself.
A Restic backup repository containing snapshots of the primary NAS datasets and VM dumps. This is the second layer of protection for the data on the primary NAS, stored on completely different hardware.
Three overlapping backup layers run independently. No single failure takes out more than one layer. The design principle is that primary NAS data goes to the backup NAS, VM configs go to the primary NAS, and everything on the primary NAS is also covered by Restic on the backup NAS.
Layers| Layer | What | Where | Tool |
|---|---|---|---|
| VM backups | host0 VMs (firewall, network management) | Primary NAS | Proxmox vzdump |
| VM backups | host2 VM (all services) | Primary NAS | Proxmox vzdump |
| VM backups | host1 VMs (NAS OS, backup agent) | Backup NAS | Proxmox vzdump |
| Config backups | Firewall configuration | Primary NAS | API pull + cron |
| Data backups | Primary NAS datasets and VM dumps | Backup NAS | Restic |
| App backups | Docker configs and database dumps | Primary NAS | Restic |
All VMs and containers across the three Proxmox hosts are backed up nightly using vzdump. The critical VMs (firewall, all services) back up to the primary NAS. The primary NAS VM itself and the backup agent container back up to the backup NAS instead, to avoid the circular dependency of the NAS backing up to itself.
The NAS backup covers only the OS disk, not the data drives. The data drives are covered separately by Restic. This keeps the VM dump small and fast.
A dedicated backup agent container on host1 mounts the primary NAS datasets over NFS and backs them up to a Restic repository on the backup NAS. This runs nightly and covers all datasets plus the VM dumps that land on the primary NAS. Pruning and integrity checks run on separate schedules.
The services VM on host2 runs its own Restic agent. Before backing up, it dumps the database for each running service to disk. The Restic backup then captures both the Docker configs and the fresh database dumps, so the VM-level backup that follows always contains a recent DB dump. Failed dumps are deleted immediately so no partial files are included.
| Keep daily | 3 |
|---|---|
| Keep weekly | 2 |
| Keep monthly | 2 |
Consistent across both Restic agents and the Proxmox vzdump jobs. Chosen to balance recovery window against backup NAS space usage.
All backup jobs are staggered overnight so that each layer completes before the next begins. The firewall config is first since it is the lightest job. Database dumps and Restic run in the early hours before the VM-level dumps start. A weekly integrity check samples the Restic repository to verify recoverability.