Requirements & hardware
Software
| Requirement | Notes |
|---|---|
| Linux (Ubuntu/Debian recommended) | The backup server host OS |
| Docker Engine + Docker Compose v2 | Required for the Docker deployment |
| 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, 4GB RAM) is more than sufficient. The bottleneck is almost always disk or network I/O.
Storage — primary drive
The primary backup drive is where snapshots are written. CMR (Conventional Magnetic Recording) drives are strongly recommended for the primary drive.
Avoid SMR drives for your primary snapshot drive. SMR (Shingled Magnetic Recording) drives use a write-cache that causes severe performance degradation under rsync's random-write workload, especially as the drive fills. This can cause backup jobs to run for hours instead of minutes.
Recommended drives for primary backup storage:
- NAS-rated CMR drives (Seagate IronWolf, WD Red Plus/Pro)
- Any CMR drive 4TB+ for meaningful retention
Storage — mirror drive
The mirror drive receives a copy of primary snapshots. The same CMR recommendation applies. A smaller drive is acceptable if you only mirror selected classes or tiers.
Storage — NOT recommended
- SMR desktop drives (Seagate BarraCuda, WD Blue) — avoid for snapshot storage; acceptable for archival/sequential use only
- USB drives — too slow for regular rsync workloads
- Network shares (NFS/SMB) — not supported as snapshot 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
- NFS/CIFS as snapshot storage — the hard-link snapshot model requires a POSIX filesystem
- Databases without Docker —
fs-db-export.shusesdocker execto dump databases; bare-metal databases require a custom pre-backup script - Incremental S3 sync — S3 export is full snapshot upload per tier/target; no block-level deduplication