Learning Restic - Backends: Local, SFTP, S3 & REST Server

#Introduction

So far your repository lives in a local directory. This episode widens the options: where your data lives determines reliability, cost, and backup speed. Restic uses one abstract backend layer — the commands stay the same, only the repository URL changes.

Choose a backend by weighing three things: where the data must be safe (off-site?), how much it costs, and how much bandwidth is available.

#Local Backend

The simplest, suited for laptops, mounted NAS, or external disks:

restic -r /backup/restic backup /data

Pros: no network, no credentials, zero latency. Cons: not off-site — if one disk fails, the backup is gone too. It should only be the first layer of a 3-2-1 strategy (three copies, two media, one off-site).

#SFTP Backend

Back up to another server over SSH without installing anything on the server side — a shell account is enough:

restic -r sftp:user@backup.example.com:/backup/restic backup /data

SSH keys and agent are used automatically by restic. Pros: off-site without extra software. Cons: performance limited to one SSH connection, and the SSH user needs write access to that directory.

#S3 & S3-Compatible Backend

The most popular type for the cloud: AWS S3, MinIO (self-hosted), GCS, Azure Blob, and Backblaze B2. They all speak the S3 protocol.

export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=minioadmin
restic -r s3:https://minio.example.com/backup-bucket backup /data

export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
restic -r s3:s3.ap-southeast-1.amazonaws.com/backup-bucket backup /data

#AWS Endpoint Styles

• s3:s3.ap-southeast-1.amazonaws.com/bucket — path style, region in the subdomain.
• s3:https://bucket.s3.amazonaws.com/ — virtual host style for global buckets.
• s3:s3.amazonaws.com/bucket — default region us-east-1.

Other backends use different prefixes — b2:, azure:, gs:. The details are in the official docs; the configuration principle is identical: URL + credentials via env.

#REST Server Backend

rest-server is a dedicated daemon that speaks restic's HTTP(S) protocol. It is the answer for multi-host backups with authentication and access control — we build it out fully in episode 12. Its URL:

restic -r rest:https://backup.example.com/restic-repo backup /data

The key difference from SFTP: rest-server cannot read the data contents (it only moves encrypted blobs), and each client can be restricted with --append-only for ransomware protection (episode 14).

#Configuration & Bandwidth Limits

#Credentials via Env

All backend credentials are read from the environment — never put them on the command line (visible in ps and history):

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_DEFAULT_REGION=ap-southeast-1

#Limit Upload/Download

To avoid saturating an office or home connection:

restic -r s3:... backup /data --limit-upload 4096
restic -r s3:... restore latest --target /tmp/r --limit-download 8192

--limit-upload 4096 limits to ~4 MiB/s; --limit-download applies during restore. Add both to your automation scripts (episode 9) so backups don't "swallow" working-hours bandwidth.

#Choosing a Backend

The principle: local for speed, cloud for durability. The best strategy combines both — a local backup every hour, then an encrypted copy to S3 every night.

#Conclusion

• Abstract backend: same commands, only the -r URL changes.
• Local = fast but not off-site; SFTP = off-site without server install.
• S3-compatible (AWS/MinIO/GCS/Azure/B2) for cloud production.
• rest-server is a dedicated HTTP daemon for authenticated multi-host.
• Credentials via env; --limit-upload/--limit-download for bandwidth.
• Combine backends: local for speed, cloud for durability.

In the next episode, episode 8, we manage history: forget & prune (retention policy) — composing restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6, setting policy based on RPO/RTO, using --keep-tag/--keep-within, and cleaning up unused blobs with --prune.