Why Your Backup Strategy Probably Has a Weak Point
Most people running home servers or self-hosted setups treat backups as an afterthought – a cron job pointed at a local drive, maybe mirrored to a NAS. That works right up until the moment the house floods, the NAS fails at the same time as the primary disk, or ransomware encrypts everything it can reach on the local network. Offsite backups solve the physical separation problem. Encryption solves the trust problem. Restic solves both, and it does it without requiring you to hand control over to a third-party service.
Restic is a fast, open-source backup program written in Go. It deduplicates data across snapshots, compresses where it can, and encrypts everything client-side before a single byte leaves your machine. It supports a wide range of storage backends – local paths, SFTP, S3-compatible object storage, Backblaze B2, and more. This guide walks through setting up Restic to run automated, encrypted, offsite backups on a Linux system, with a focus on getting it production-ready rather than just functional.
Installing Restic and Initializing a Repository
On most Debian-based systems, Restic is available directly from the package manager, though the version in the default repos can lag behind upstream releases. The safer approach is to grab the latest binary from the official GitHub releases page, verify the SHA-256 checksum, and install it manually to /usr/local/bin. Once installed, confirm the version with restic version before doing anything else – some older builds have deduplication quirks that were fixed in later releases.
Before Restic can store anything, it needs a repository. The repository is the structured directory where all your encrypted backup data lives. Run restic init pointed at your destination – whether that is an SFTP server, a Backblaze B2 bucket, or an S3-compatible endpoint like Wasabi or Cloudflare R2. Restic will prompt you to set a password. That password is the only thing standing between your encrypted data and anyone who gets access to the repository, so treat it accordingly. Store it in a password manager and separately in a physically secured location. Losing it means losing access to every snapshot, permanently.
For SFTP-based offsite storage, the init command looks like: restic -r sftp:user@remotehost:/backups/myrepo init. For B2, you export your B2 application key ID and application key as environment variables (B2_ACCOUNT_ID and B2_ACCOUNT_KEY), then run restic -r b2:bucket-name:/path init. Restic handles the rest. The repository structure it creates is opaque by design – filenames are hashed, and the actual content is encrypted with AES-256 in counter mode, authenticated with Poly1305-AES. Even if someone compromises your storage backend, the data is unreadable without your password.
Storing Credentials Securely for Automation
Running automated backups means the password cannot be typed interactively, which creates an obvious problem. Restic handles this through the RESTIC_PASSWORD environment variable, or better, through RESTIC_PASSWORD_FILE, which points to a file containing the password. That file should be owned by root, with permissions set to 0400, stored outside of any directory included in the backup itself. If you are using a secrets manager or something like systemd credentials, those are cleaner options for production environments – the password never touches disk in plaintext.
For cloud backends that require API keys, use a dedicated environment file sourced only by the backup script or systemd unit. Set the file permissions to 0600, owned by the user running the backup. Never hardcode credentials directly in a shell script that sits in a world-readable location. The pattern that works well is a single /etc/restic/env file with all required variables, loaded via EnvironmentFile= in the systemd service definition. This keeps credentials out of process lists and shell history.
Writing the Backup Script and Scheduling with systemd
A minimal Restic backup script needs to do four things: load environment variables, run the backup, prune old snapshots according to a retention policy, and check repository integrity. Skipping any of these turns an automated backup into a liability. The backup command itself is straightforward: restic backup /home /etc /var/lib --exclude /var/lib/docker, adjusted for whatever directories matter on your system. The exclude list deserves real thought – Docker volumes, build caches, and temporary directories waste bandwidth and storage without adding recovery value.
Retention policy is where most setups go wrong by either keeping too much (storage costs spiral) or pruning too aggressively (you discover you needed that snapshot from three weeks ago). A sensible starting policy uses Restic’s forget command with flags like --keep-daily 7 --keep-weekly 4 --keep-monthly 6. Follow that immediately with restic prune to actually reclaim space. The forget command alone only removes references – prune does the actual cleanup. Running both together in the script avoids the common confusion where people run forget and wonder why their storage usage hasn’t changed.
After pruning, run restic check. This verifies the repository’s internal consistency – it confirms that all pack files referenced in the index actually exist and that the structure is intact. For deeper validation, restic check --read-data-subset=10% samples a portion of the actual encrypted data and validates it against stored hashes. Running a full --read-data-subset=100% monthly catches silent data corruption that basic consistency checks miss, though it does generate significant egress traffic on cloud-backed repositories, so factor that into your storage costs.
For scheduling, systemd timers beat cron for this use case because they handle missed runs, provide structured logging through journald, and let you set dependencies. Create a restic-backup.service unit that calls your backup script, then a restic-backup.timer that defines the schedule – OnCalendar=daily with Persistent=true ensures the backup runs even if the machine was off at the scheduled time. If you want push notifications when a backup fails, pairing the service with a self-hosted Ntfy instance gives you instant alerts without routing through a third-party notification service.
Testing Recovery and Handling Edge Cases
A backup you have never restored from is a hypothesis, not a backup. Run restic restore latest --target /tmp/restore-test on a regular basis and verify that the files are actually there and readable. For critical data, script a checksum comparison between the live source and the restored copy. This is the only way to confirm that the encryption, deduplication, and transfer pipeline is working end to end, not just that Restic reports success.
One edge case worth addressing explicitly: if your offsite destination is a remote SFTP server, network interruptions mid-backup leave Restic in a locks state. Run restic unlock if a backup fails partway through and subsequent runs report a locked repository. Restic’s lock files are stored inside the repository itself, so a stale lock from a crashed process will block every future backup until it is cleared. Adding restic unlock as a pre-backup step in your script is safe – Restic checks lock age and will only remove locks older than a configurable threshold.
Bandwidth throttling is a practical concern on residential connections. Restic does not have a built-in rate limiter, but running it through trickle or using the upload limits available in rclone (if you are using rclone as a backend via the rclone Restic driver) handles this without touching the backup logic itself. For large initial backups, many people seed locally first and ship a drive – Restic supports this by initializing a local repository, doing the first full backup locally, then copying the repository to the remote destination and switching the script’s target. Subsequent incremental backups are then small enough to transfer over the wire without saturating the connection.
The question of how often to test a full bare-metal restore from an offsite Restic repository – not just a file-level restore – is one most self-hosters delay longer than they should.
