Why automate your backups with Restic
A VPS often hosts irreplaceable data: databases, Docker volumes, configuration files. Restic meets three key requirements of a sound strategy: encryption (AES-256; the repository is unusable without the password), deduplication (identical blocks are stored only once, which drastically reduces volume and cost), and support for varied backends (S3, Backblaze B2, SFTP, local storage). Self-hosting Restic on the VPS rather than relying on a managed backup service gives you full control of encryption: the key stays with you, and the storage provider sees only opaque blobs. This is the foundation of a serious 3-2-1 strategy.
What Restic brings you
- Client-side AES-256 encryption: the storage backend sees only unreadable data.
- Block-level deduplication that greatly reduces the size and cost of successive backups.
- Fast incremental snapshots: only new blocks are transferred on each run.
- Multiple backends (S3, Backblaze B2, SFTP, rest-server, local) without changing your workflow.
- Granular restore: a single file, a folder or an entire snapshot via
restic restore. - Automated retention policy with
forget --prune(keep N daily, M weekly...).
Prerequisites for this deployment
Restic is frugal: it runs on any VPS, including 1 vCPU and 1 GB of RAM, with deduplication consuming a little memory in proportion to the repository size. You need the restic binary (the distribution's package or a direct download), a remote destination backend (an S3-compatible bucket at a provider, or another server over SFTP) and its credentials. No Docker required here: Restic is a command-line tool. Plan for cron or a systemd timer for automation, and a safe location outside the VPS to keep the repository password.
Set up automated Restic backups
Install Restic and prepare the environment variables
Install the binary (apt install restic then restic self-update). Create a /root/.restic-env file containing RESTIC_REPOSITORY, RESTIC_PASSWORD and the backend access keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY for an S3-compatible bucket). Restrict its permissions with chmod 600.
Initialize the encrypted repository
Load the environment then run restic init. This command creates the repository structure and seals the encryption with your password. Back up this password somewhere other than the VPS: without it, no restore is possible.
Run a first backup
Back up your critical directories, for example restic backup /etc /var/www /opt/docker-data. For a database, dump it to a file and include that, or pipe the dump into restic backup --stdin.
Define a retention policy
Avoid endless accumulation with restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. The --prune pass physically deletes blocks that have become orphaned and frees space in the backend.
Automate via cron or a systemd timer
Create a backup.sh script that sources .restic-env, runs restic backup then restic forget --prune, and logs the result. Schedule it daily, for example 0 3 * * * /root/backup.sh in the crontab.
Test a restore and verify integrity
An untested backup is an illusion. List the snapshots with restic snapshots, restore to a temporary folder (restic restore latest --target /tmp/test-restore) and run restic check periodically to validate the repository's integrity.
Protect your backups against ransomware by enabling "append-only" mode on the backend: deploy a remote rest-server with the --append-only option, or use an S3 bucket with an IAM policy that forbids deletions. That way, even if your VPS is compromised and the attacker obtains the credentials, they will be unable to erase or encrypt your existing snapshots. Combine this with running restic forget --prune from a separate machine that does hold deletion rights.
