BUILD PROJECT · BACKUPS
How to Build a Simple Backup Server
Use a small computer as a useful backup host, while keeping copies, permissions and restoration more important than the server label.
What a backup server is
A backup server stores recoverable copies of data from other devices. It is not the same as a file server, synchronisation service or RAID array. RAID may improve availability, but RAID is not a backup. A simple 3-2-1 plan keeps three copies, on two kinds of media, with one copy offline or off-site.
Hardware and storage planning
Choose a supported base machine with enough known storage and a reliable network connection. Plan version retention and growth before buying disks. You do not need a multi-disk NAS claim for this guide; a single backup destination can be useful when a second copy exists elsewhere.
A simple rsync copy
Assume Ubuntu or Debian. Create a dedicated destination and use a named source account. This example copies a directory while preserving metadata; replace paths only after checking them:
rsync -aHAX --delete --info=progress2 \
/home/your-user/Documents/ \
backup-user@backup-host:/srv/backups/your-host/Documents/--delete removes destination files no longer in the source, so test without it first and keep snapshots or another copy. Use SSH keys restricted to the intended backup account where practical. Never paste a password into a command.
Encrypted backups
For laptops and sensitive data, consider restic or Borg-style encrypted repositories. Store the repository password in a password manager and keep a recovery copy of the repository key. Encryption protects the backup if the destination is stolen; it also means a lost key can make the backup unusable.
Scheduling, permissions and monitoring
Run backups as a dedicated account with only the permissions required. Use a systemd timer or cron job, record logs and alert yourself when jobs fail. Keep the backup destination unwritable from every ordinary account. Check free space and storage health, but do not treat a health check as proof that files can be restored.
Restore testing and retention
- Restore a few representative files to a temporary directory.
- Check ownership, timestamps and whether the files actually open.
- Practise restoring a whole small project and record the steps.
- Keep multiple generations so accidental deletion is not immediately copied everywhere.
- Disconnect or protect the secondary copy when ransomware risk is a concern.
Common mistakes
A backup that has never been restored is an assumption. Watch for wrong source paths, permissions, a full destination, a dead SSH key and jobs that succeed while copying an empty mount. Keep the mountpoint and restore notes documented.
Make failure visible
systemctl list-timers
df -h /srv/backups
find /srv/backups -maxdepth 2 -type f | headCheck the timer, free space and that a recent file exists on the expected mounted destination. A successful command is not enough: open a restored test file and record when the last restore test passed.
Encrypted backups and recovery plan
Restic or Borg-style encrypted repositories can protect sensitive data, but the repository password or key must be recoverable by the people responsible for the system. Keep an offline or off-site copy and test the key before relying on it. RAID is not a backup; synchronising a deletion immediately is not a backup either.
What next?
Use this with the file-server guide and home-lab foundation. Build a backup host after planning the second copy.