Borg and Restic in daily backups

Nearly every company we meet has a backup that nobody has ever restored. The copy exists, it runs on some rhythm, and the actual question of what would happen in a loss stays open. Borg and Restic are the two tools that keep appearing in our practice when that question gets taken seriously. Both are mature, both encrypt by default, and both are old enough that their behavior is well documented. This post places them in context and shows the layout that sits on top of either.

What each tool does well

Borg descends from the incremental-archive tradition with deduplication: it cuts data into blocks, recognizes repetition across archive boundaries, and stores each block once. The result is archives that stay surprisingly small on similar data, plus an embedded mount capability for browsing a snapshot directly. The shell tooling is sharper-edged, the command-line surface consistently old-school. Restic chooses a different starting point: the data structure is a content-addressed store, and the tool family is built around one clear command series. Restic supports several backends by design, among them S3-compatible object stores and remote systems through rclone, which eases the offsite chapter considerably.

The practical difference lies in the workflow details: Borg shines where strongly repetitive volumes live on a familiar server; Restic shines where targets change more often and the simpler surface matters more than another percent of deduplication. Frankly, both are usually fast enough that speed is not the deciding factor.

The 3-2-1 layout on top of either

The 3-2-1 rule provides the frame: three copies of the data, two different media types, one copy off-site. The numbering comes from the classic document of the United States cybersecurity authority on backups; the substance is older, the format stays popular. For a typical server this means: copy one is the production system itself, copy two the local archive on separate media, copy three the remote target in a different building or data center. Borg and Restic are the tools for copies two and three; what they do not replace is the retention decision: how long, which versions, in which tiers (daily, weekly, monthly) the system stays readable.

One detail we always verify is encryption: both tools encrypt before upload, client-side, with their own keys. That means the remote target may, in theory, be unreadable to itself without compromising data safety; in practice we additionally rely on a key recovery procedure that has nothing to do with the tool data: without reproduction of the key, all archives are just compute.

The restore test

The point that ends every backup discussion is the restore test. A plan that has never been run is a guess. So we test on two levels: monthly, a targeted partial restore that unpacks a random sample on a separate system and compares it against the source, and once a year a scenario where the complete restoration of a system runs from the archives. Both are cheap compared to the failures they uncover: a missing directory path, an overlooked permission, an archive date further back than the retention promised.

Storage care belongs to the routine as well: an archive that grows without bounds eventually makes even the test impossible, because bandwidth runs out. Retention is not the opposite of safety but its border zone.

Where the copy goes

For the backup question the line here is: the remote copy needs different failure behavior than the local one, otherwise it is a duplicate illustration rather than a safeguard. In the end, the combination matters less than the real test question: is there truly a copy that becomes readable again on its own strength?

The key envelope is part of the package

Both tools encrypt before upload, so custody of the key decides the value of the entire copy. Our practice keeps a plain triad: the key lives outside the backed-up systems, a printed recovery note exists in a place the team's two worries both know, and the recovery from that note has actually been rehearsed once. The third point sounds pedantic and is not: a recovery path that exists only in imagination stayed in imagination, and a second person who knows the procedure is the difference between incident and catastrophe.

The envelope also carries the record of who changed the key and when. A forced key rotation is not a mishap but a planned event with announcement, verification and a fresh note.

One last note on the variety of sources: databases and container images fit the same layout but need their own paths to consistency. The server backup job does not disappear because of that; it gets clearly bounded neighbors. Describing the limits of the tools soberly removes exactly the false confidence that otherwise surfaces late, in the review meeting.

The restore side of this discipline, rehearsing restores as a procedure, is covered in our post on restore drills. If you want your backup layout brought onto the 3-2-1 footing, or existing procedures tested, the DevOps and backup service page is the right entry, and we enjoy turning untested plans into real promises.

Sources

• BorgBackup documentation, https://borgbackup.readthedocs.io/en/stable/index.html (accessed 2026-11-04)
• Restic documentation, https://restic.readthedocs.io/en/stable/100_references.html (accessed 2026-11-04)
• CISA, Data Backup Options, archived copy, https://web.archive.org/web/20230311041847/https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf (accessed 2026-11-04)