restic

Overview

restic is an open-source backup program started around 2015 and primarily developed in Germany, written in Go as a single binary. It organises backups as snapshots, where each run produces a snapshot sharing content-addressed data blocks, so incremental backups need no fragile incremental chain.

That design matters for Backup & Migration work. Classic incremental backups depend on the previous link being intact, and one damaged run can break later restores, while restic snapshots are independent, so deleting any snapshot leaves others recoverable and restic check verifies repository integrity on demand.

It supports local directories, SFTP, S3, B2, Wasabi, and Azure backends with encryption and deduplication on by default. The trade-off is no official GUI or scheduler, so cron and monitoring are yours to build, which is exactly where it diverges from commercial backup products.

Core Strengths

• Snapshot structure keeps runs independent, so one damaged snapshot does not break others
• Content addressing plus block dedup makes multi-version archives far smaller than stacked fulls
• AES-256 encryption and HMAC verification are default, so repositories stay ciphertext in third-party storage
• restic check turns whether a backup can be restored into a concrete, runnable action

Product Ecosystem

Repository and snapshot management

init creates an encrypted repository, backup writes snapshots, and forget plus prune control retention. Prune reclaims space at the cost of rewriting indices, which is slow on large repositories, so schedule it off-peak and watch duration trends.

Integrity checks and restores

check offers structural and full data verification, the latter reading all blocks and closely approximating a real restore. Run structural checks weekly and sampled data checks monthly in production, alongside real restores into a scratch directory.

Drawbacks

• No official GUI or scheduler, so cron, logging, and alerting are self-built
• Prune is slow on large repositories and can consume significant IO and time windows
• Beyond block-level dedup there is no delta algorithm, so some data types such as large database files deduplicate poorly
• Community support only, with no vendor SLA or managed offering

Use Cases

• Scheduled Linux server backups (★★★★★) - Single binary plus snapshots plus verification is a standard server pattern
• Offsite copies in object storage (★★★★★) - S3, B2, and Wasabi backends work out of the box, and rclone can redistribute
• Database dump backups (★★★★) - Dumps deduplicate poorly, so pair with compression and retention policy
• Teams needing GUI and managed service (★★) - No GUI or scheduler, so operations must be built

Pricing

The software is free and cost sits in storage and operations. Prune time grows with repository size, so plan a monthly prune window as a fixed cost rather than an optional step.

FAQ

• How is restic different from borg? Both do deduplicated encrypted backups, and the difference is ecosystem and backends. restic speaks S3, B2, and other object stores natively as a single binary, while borg leans toward local and SSH targets, so restic is easier when pushing straight to object storage.

• How do I verify backups? Run restic check with a read-data subset for sampled verification, then restore into a scratch directory periodically and diff the file list. A successful backup exit code alone proves nothing about restorability.

• Can it back up a live database? Not the data files directly. Take a logical dump such as mysqldump or pg_dump and back that up, or use the database's own physical backup tool, since copying live data files tends to produce inconsistent snapshots.