Configuring Server Backups with Restic – Turnkey Service

Configuring Server Backups with Restic – Turnkey Service

We set up server backups with Restic — chunk-level deduplication and client-side encryption. Restic works equally well with S3, SFTP, and any storage via rclone, giving flexibility in choosing the backend. Our engineers have over 5 years of production experience with Restic, including clusters of 100+ servers. In this article, we'll break down how Restic solves key backup problems and show a real configuration with systemd timer.

How Restic Solves Deduplication and Encryption

Restic splits data into 512 KB chunks and computes their hashes. On subsequent backups, only new or changed chunks are transferred — this reduces traffic by 10–20 times compared to rsync. Encryption is performed client-side before upload: a password generates an AES-256 key, and even if the storage is compromised, data remains inaccessible. For critical databases (PostgreSQL, MySQL), we additionally configure backups via pg_dump before sending to Restic. For Docker containers, we use a sidecar container with restic, mounting volumes.

Which Storage Backends Does Restic Support?

We help you choose a storage option that fits your budget: from cheap S3-compatible object storage to enterprise SFTP. The Restic repository is readable regardless of backend.

Example Configuration with systemd timer

# Installation
apt-get install restic
# or
wget https://github.com/restic/restic/releases/download/v0.17.3/restic_0.17.3_linux_amd64.bz2
bunzip2 restic_*.bz2 && chmod +x restic_* && mv restic_* /usr/local/bin/restic

# Initialize repository in S3
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=secret
export RESTIC_REPOSITORY=s3:https://s3.eu-central-1.amazonaws.com/my-backups/server1
export RESTIC_PASSWORD=strong-encryption-password
restic init

First backup:

restic backup /etc /home /var/www /var/lib/postgresql \
    --exclude="/var/lib/postgresql/*/pg_wal" \
    --exclude="/var/www/*/node_modules" \
    --tag server1 \
    --tag prod

Deduplication works at the level of content-addressable 512 KB chunks — on subsequent backups, only changed blocks are transferred. For a typical server, the second and later backups take 5–15% of the time of the first.

/etc/restic/env:

AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=secret RESTIC_REPOSITORY=s3:https://s3.eu-central-1.amazonaws.com/my-backups/server1 RESTIC_PASSWORD=strong-encryption-password 

Permissions 0600, owner root.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=restic backup /etc /home /var/www --exclude-file=/etc/restic/excludes
ExecStartPost=restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/restic-backup.timer
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
[Install]
WantedBy=timers.target

--keep-daily 7 --keep-weekly 4 --keep-monthly 6 — standard rotation: 7 daily, 4 weekly, 6 monthly snapshots. --prune removes unused data after applying the policy. For monitoring, you can add restic_exporter, which exposes metrics to Prometheus — execution time, data volume, status.

Why Restic is Better Than Traditional rsync Backups

Restic reduces secondary backup time by 10–15 times compared to rsync, and storage space savings from deduplication reach 80%. This is especially noticeable on servers with databases or large logs. Real case: a client with 50 servers switched from rsync to Restic and cut backup time from 3 hours to 15 minutes.

What's Included in the Turnkey Restic Setup

We provide a comprehensive service:

• Audit your data: determine what to backup and how often
• Install and configure Restic according to your stack (Linux, Docker, Kubernetes)
• Set up systemd timer or integrate with existing CI/CD
• Choose and connect storage (S3, SFTP, REST)
• Retention policy and automatic forget/prune
• Backup monitoring: alerts to Telegram/Slack on failures, Prometheus metrics
• Test restore (restore dry-run) — verify data readability
• Documentation and training for your engineers
• Data recovery guarantee — if we can't restore, we fix it for free

Contact us for a project assessment — we'll propose the optimal configuration and timeline.

Common Mistakes When Configuring Restic

1. Weak password: use a long password (20+ characters) — it's the only key to your data.
2. Missing exclude rules: don't exclude temporary files (node_modules, .git), otherwise the repository will bloat.
3. Incorrect retention policy: without --prune, unused chunks are not removed, leading to storage growth.
4. Ignoring monitoring: backups may silently fail (S3 access error). Set up alerts.
5. Lack of test restore: verify the restore process at least once a month.

Our engineers have experience restoring hundreds of servers — we guarantee your data will be available at any moment. Order turnkey Restic setup and get secure backup without surprises.