Learning Restic - The Ecosystem: rest-server, SDK & Wrappers

#Introduction

Episode 12 built rest-server; episode 18 optimized its scale. Now we step outside the binary itself: the ecosystem that makes restic manageable, monitorable, and integratable like an enterprise product. A great single binary is not enough — teams need centralized configuration, metrics, and pipelines.

#rest-server as a Product

rest-server is not just a daemon — it is a backup server product in one binary. What you already mastered in episode 12 (HTTPS, htpasswd, append-only) is its foundation. In production, it usually sits behind a reverse proxy with:

• Automatic TLS (Caddy/Let's Encrypt).
• Rate limiting and a firewall (episode 14).
• Process monitoring (systemd + healthcheck).
• Dedicated storage (a directory, or an S3 volume for object storage).

An example healthcheck for rest-server:

curl -fsS https://backup.example.com/ | grep -q "restic" || exit 1

#Wrappers: resticprofile & restic-compose

Running restic with 10 flags over and over scatters config across many crons. resticprofile solves this with centralized YAML configuration:

default:
  repository: s3:https://minio.example.com/backup-bucket
  password-file: /etc/restic/passphrase
 
daily:
  backup:
    source: /home/user
    exclude-file: /etc/restic/excludes.txt
    tag: daily
    upload-limit: 4096
 
prune:
  forget:
    keep-daily: 7
    keep-monthly: 6
    prune: true

Then run:

resticprofile daily backup
resticprofile prune forget

The benefits: one file for all schedules, versionable, and supports Prometheus metrics (episode 20).

restic-compose (docker-compose) manages backup containers with the same pattern — for those who have standardized deploys via compose (episode 12).

#Grafana Dashboards

For visualization, the community provides Grafana dashboards for restic (search for "restic" on grafana.com dashboards). Common metrics displayed: last backup status, duration, data added, and error rate. These dashboards live off Prometheus metrics exposed by scripts/wrappers — not from the restic binary itself.

#Prometheus Metrics via Wrapper/Script

Restic has no built-in metrics endpoint. The common solution: a wrapper that runs the backup and then publishes the status. With resticprofile, measurement is automatic:

resticprofile --source /etc/resticprofile.yaml backup --log-format json \
  --exporter-prometheus \
  --exporter-prometheus-listen-address :9090

For custom setups, a simple script can compute and export metrics:

start=$(date +%s)
if restic backup /data --json; then
  echo 'restic_backup_status 1'  >> /var/lib/node_exporter/restic.prom
else
  echo 'restic_backup_status 0'  >> /var/lib/node_exporter/restic.prom
fi
echo "restic_backup_duration $(($(date +%s)-start))" >> /var/lib/node_exporter/restic.prom

Full metric & alerting details are in episode 20.

#Integrating Backups into the CI/CD Pipeline

Backup can become part of the pipeline — for example a snapshot before deploy:

- name: Pre-deploy backup with restic
  run: |
    export RESTIC_PASSWORD="${{ secrets.RESTIC_PASSWORD }}"
    restic -r s3:${{ secrets.S3_ENDPOINT }}/${{ secrets.BUCKET }} \
      backup ./artifacts --tag predeploy

This applies the --keep-tag pattern from episode 8: predeploy snapshots are protected from the forget policy so you can roll back to the state before a problematic deploy.

#Conclusion

• rest-server = a backup server product: TLS, htpasswd, append-only, healthcheck.
• resticprofile: centralized YAML config for all schedules & flags.
• restic-compose: container patterns via docker-compose.
• Metrics: export Prometheus through wrappers/scripts, visualize in Grafana.
• Pipeline: predeploy snapshot with --tag predeploy + --keep-tag for rollback.
• CI needs secret injection and aggressive retention for build artifacts.

In the next episode, episode 20, we make backups observable: monitoring & alerting — exporters/scripts for backup status (success/failed/duration), alerts on failure, Email/Slack/Telegram notifications, and a dashboard for the whole fleet.