Filesystem Backups with Restic: Encrypted and Deduplicated

Filesystem backups are the backbone of a VPS that runs more than a database: config in /etc, releases in /var/www, and user uploads somewhere under /srv. The tools that dump databases cannot see those trees. restic takes the other half of the job, whole-directory snapshots, and adds two properties that make it viable for cloud-sized archives: real client-side encryption and content-defined deduplication. This post walks through a working restic setup end to end on a single VPS.

Initialize a repository once

restic stores snapshots in a repository, which can live on the same box, on an SFTP host, or on object storage behind an rclone backend. Initialize the repository before the first backup. Password handling is the one design decision you make up front: the repository password protects the master key, so a lost password is a lost repository.

export RESTIC_REPOSITORY=sftp:offsite:/restic/app
export RESTIC_PASSWORD_FILE=/root/restic-password
restic init
restic backup /etc /srv/www /srv/uploads   --exclude='*.log' --exclude-file=/etc/restic/excludes

The password file is root-only and lives on the box; the human copy of that password belongs in a manager somewhere offline. restic never prompts interactively, which is exactly what you want from cron.

How deduplication and encryption actually work

restic splits each file into variable-size chunks using a content-defined algorithm, so inserting bytes shifts split points instead of invalidating whole files. Identical chunks are stored once across files and across snapshots. A server whose directories barely change can keep 90 daily snapshots in roughly the space of the first one or two.

Every chunk is encrypted with AES-256 using keys derived from the repository password. Snapshot names, directory metadata, and file sizes are not exposed as plaintext on the storage side, which makes a stolen repository look like noise rather than like your customer list.

Retention: forget, then prune

Deleting snapshots in restic is deliberately two steps. forget marks snapshots for removal according to a retention policy but leaves chunks on disk; prune removes chunks that nothing references anymore. Running both in one command keeps the repository lean, and the ordering keeps a mistake recoverable.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
restic snapshots

Run restic check --read-data every quarter; it reads the entire repository and catches silent bit rot that a quick check misses.

Restore is the whole point

restic's restore is deliberately boring: name a snapshot, name a target, wait. To catch a single file without restoring everything, use a path filter.

restic restore latest --target /restore-check
diff -rq /etc /restore-check/etc
restic restore latest --target / --path /srv/uploads

The diff against live /etc is a cheap assertion that the archive still contains what you think it does. Full restores belong in your restore drill, pointed at a scratch directory so they never collide with real data.

Make it daily with cron

# /etc/cron.d/restic
15 3 * * * root /usr/local/bin/restic_backup.sh
30 3 * * 6 root restic -r sftp:offsite:/restic/app prune

Keep the backup script idempotent: the same command at the same time every day, logging to syslog. If a snapshot fails, restic exits non-zero and cron mail catches it.

Takeaway

restic keeps a single server's filesystem safe in encrypted, deduplicated archives with a restore command you can memorize. Initialize the repository, schedule the daily snapshot, prune by policy, and verify a restore in the drill. A fresh VPS from netbayhosts.in is a fine first home for such a repository before you push copies off-site.