restic: dedup backups where the password is the only key, and the Makefile builds nothing but one binary

The password is the whole key and there is no recovery path

Creating a repository is a two-line exchange and a permanent obligation:

    $ restic init --repo /tmp/backup
    enter password for new backend:
    enter password again:
    created restic backend 085b3c76b9 at /tmp/backup
    Please note that knowledge of your password is required to access the repository.
    Losing your password means that your data is irrecoverably lost.

There is no escrow, no key file to copy aside, and no recovery command shown, and the message is unusually direct about the consequence. The credential is the encryption key, and every later operation re-prompts for it, as the backup example shows with its own enter password for repository line. Two details catch people. The prompt for a brand new repository says enter password for new backend rather than repository, which is confusing the first time you read it. And the README never says where that password should be kept, which is the single most important piece of advice for a tool with this failure mode. Store it in a password manager, not in the same bucket you are backing up to.

godebug winsymlink=0 freezes Windows junction behaviour on purpose

The module file carries a compatibility decision with a comment explaining it, which is the clearest statement of a known rough edge in the repository:

// keep the old behavior for reparse points on windows until handling reparse points has been improved in restic
// https://forum.restic.net/t/windows-junction-backup-with-go1-23-or-later/8940
godebug winsymlink=0

Restic is written in Go, and Go changed how symbolic links are resolved on Windows in a recent version. Rather than inherit the new behaviour, the module pins the old one, and the linked forum thread is the report that prompted it. The consequence lands on restore rather than on backup: a tree of junctions captured under one set of rules can come back under another, so a Windows restore is not guaranteed to reproduce the link structure of the source, and reparse point handling is listed as work that is not yet finished. The pin also means upgrading the Go toolchain alone will not change this, so the debt is deliberate and versioned rather than accidental.

The Makefile has four targets and no install step

The build file in the root is small enough to read in full, and its limits shape what you can do from a checkout:

test:
	go test ./cmd/... ./internal/...

The other targets are all, which depends on restic, restic, which runs go run build.go, and clean, which removes the resulting file. There is no install target, no package target, and no release target, so make produces one unversioned binary in the working directory and stops there. Note also the shape of the test command: it covers the cmd and internal trees and nothing else, while the repository root also carries helpers, doc, contrib, and changelog directories, so anything living under helpers is not exercised by the Makefile target that a contributor is most likely to run. Reproducible builds are a separate story again. The binaries shipped with each version from 0.6.1 onward are byte reproducible from source, but the instructions for doing that live in a separate builder repository, not in this Makefile.

The dependency list is the backend inventory in disguise

Read go.mod and the list of supported storage targets reappears as one client library per provider: minio-go for Amazon S3 and anything S3 compatible, ncw/swift for OpenStack Swift, blazer for Backblaze B2, the Azure blob and identity SDKs, cloud.google.com/go/storage plus google.golang.org/api for Google Cloud Storage, and pkg/sftp for the sftp backend over SSH. On top of that sit the parts that make it a backup tool rather than a file copier: restic/chunker, xxhash for content addressing, ProtonMail's go-crypto for the OpenPGP layer, and simple-scrypt for key derivation, which together are how the design principle of deduplicating before writing to the backend is actually implemented. The cost of that inventory is the long tail. Rather than ship a driver for every storage service, the escape hatch is rclone, which means an unusual destination pulls a second program and a second configuration language into your backup path.

Browsing old snapshots depends on a FUSE layer that is not everywhere

There are two ways to get data back, and the README offers both in a single sentence: restic restore to restore files, or restic mount to mount the repository via fuse and browse the files from previous snapshots. The difference is not cosmetic. Restore is a plain command that copies what you ask for out of the repository, and it is the path that works everywhere. Mount is a filesystem, and the repository carries github.com/anacrolix/fuse as a dependency to provide it, which means the browsing path is only available where a FUSE layer can run. On platforms that need an extra driver or do not support it, restic mount is not an option and restore is the whole story. That matters for a specific workflow rather than in general: if you want to open one file out of a snapshot from three months ago to check whether you already fixed a document, restore is a whole tree selection exercise, and the convenience the mount was meant to provide is simply missing.

The first backend on the list is the one the docs warn against

The backend list opens with a local directory and closes with a long tail reached through rclone, with sftp, an HTTP REST server, Amazon S3 and any S3-compatible store, OpenStack Swift, Backblaze B2, Microsoft Azure Blob Storage, and Google Cloud Storage in between. Immediately above the list sits the reason any of this exists: saving a backup on the same machine is nice but not a real backup strategy. That warning sits in an awkward spot, because the quick start then demonstrates the whole flow against /tmp/backup, which is a local path on the same machine and a directory that operating systems are free to clear. Copying the quick start verbatim therefore produces a repository that satisfies every command in it and fails the first time the disk dies. Treat the local directory backend as a scratch target for trying commands, and pick a remote one before you trust the output.

Prune, forget, and check never appear in the quick start

Four commands are demonstrated: init, backup, restore, and mount. That is the entire hands-on surface, and the omissions are the interesting part. Nothing in the quick start shows how to list snapshots, how to remove one, or how to reclaim the space a deleted snapshot occupied, even though the storage model is incremental, so every snapshot is cheap but the set of them is not free and grows forever if you never prune. Nor is there a check command, even though the design principles make verifiability a headline claim by arguing that restoring matters more than backing up. Searchers ask what restic prune does, and the answer is not in the README, because retention and integrity checking are handled in the online documentation. The backup example output is the one place with real figures, showing 764 directories, 1816 files, 2580 items, 1.582 GiB, and a 0:29 duration at 54.47 MiB/s, but those belong to the README's illustrative run, not to any machine you will use.

Editorial conclusion

restic fits anyone who wants encrypted, deduplicated snapshots on storage they do not control, and who can accept building or fetching the binary and storing the repository password somewhere other than the repository. Skip it if you need a documented retention story or a Windows restore that reproduces modern junction semantics. Before your first run, save the password outside the backend, because restic states plainly that losing it means the data is irrecoverably lost, and remember that the README documents no prune, forget, or check command at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes