Requirements & hardware
Software
| Requirement | Notes |
|---|---|
| Linux (Ubuntu 22.04+ / Debian 12+) | The backup server host OS |
| ZFS (OpenZFS) | For snapshot storage — zfsutils-linux package |
| rsync on remote hosts | Version 3.x recommended |
| SSH access to remote hosts | fsbackup pulls via backup user over SSH |
| node_exporter (optional) | For Prometheus metrics |
Backup server hardware
fsbackup is designed to run on a dedicated backup server — a machine that exists solely to pull and store backups from other hosts on your network.
CPU and RAM
fsbackup is not CPU or RAM intensive. A modest machine (2+ cores, 4 GB RAM) is more than sufficient. The bottleneck is almost always disk or network I/O. ZFS ARC will use available RAM for read caching — more RAM helps with frequent restores.
Storage — ZFS pool
All snapshots are stored on a ZFS pool. The recommended topology for a two-disk setup is a mirrored vdev: both disks hold identical data, and a single disk failure is fully survivable.
# Create a mirrored pool on two disks
sudo zpool create -o ashift=12 backup mirror /dev/sdc /dev/sdf
sudo zfs create backup/snapshots
CMR (Conventional Magnetic Recording) drives are strongly recommended.
Avoid SMR drives for ZFS. SMR (Shingled Magnetic Recording) drives use a write-cache that causes severe performance degradation under ZFS's random-write workload, especially during resilver and scrub operations. This can cause jobs that should take minutes to run for hours.
Recommended drives:
- NAS-rated CMR drives (Seagate IronWolf, WD Red Plus/Pro)
- Any CMR drive 4 TB+ for meaningful retention depth
Storage — NOT recommended
- SMR desktop drives (Seagate BarraCuda, WD Blue) — avoid for ZFS; acceptable for archival/sequential use only
- USB drives — too slow and unreliable for regular rsync + ZFS workloads
- Network shares (NFS/SMB) — not supported as ZFS storage
Network
fsbackup pulls from remote hosts over SSH. All remote hosts must be reachable from the backup server on port 22 (or a configured alternative).
For home lab setups spanning multiple VLANs, ensure routing between the backup server's VLAN and the target hosts' VLANs is configured correctly.
Unsupported configurations
The following are not currently supported:
- Windows hosts as backup targets — fsbackup uses rsync over SSH; WSL2 can work but is not tested
- Pushing backups (agent on source host pushes to fsbackup) — fsbackup is pull-only
- Non-ZFS snapshot storage — v2.0 requires ZFS; the old hard-link snapshot model is no longer supported
- Incremental S3 sync — S3 export is a full snapshot upload per tier/target; no block-level deduplication