How to restore one file or folder from a restic snapshot

Do not reach for latest until you know which backup set it means. A repository can contain snapshots from several hosts and several paths. In that repository, the newest snapshot overall may belong to another server or may not contain the file you need.

Start with the snapshot list and narrow it by host or original backup path. Record the exact snapshot ID. An explicit recovery point makes the work repeatable and prevents a newer backup from changing what latest resolves to while you investigate.

A restic snapshot has its own file tree. The path shown there is the path you pass to --include; it is not necessarily the path you remember from the current machine. This distinction matters after a migration or when a backup was made from a relative path.

Browse the chosen snapshot when you know roughly where the item lives, or search its index when you only know a name. Confirm the complete path inside the snapshot before creating a restore job.

The safest target is a newly created directory outside the live application tree. Restic recreates the original hierarchy inside that working directory, which lets the operator inspect the recovered item without touching production.

Limit the restore to the selected file or directory and preview the scope when the tooling supports it. A target reused from an older incident can hide stale files, so every rehearsal should start empty.

A zero exit code says the restore command completed; it does not tell you that you chose the right revision. Inspect the file type, owner, permissions, size, and modification time. Open a document or image with the application that normally reads it. For a configuration file, compare it with the current copy before replacing anything.

Checksums help when you have a trusted hash from another system, but they only prove byte equality with that reference. The application or file owner still has to decide whether the chosen historical version is the right one.

Restic overwrites existing target files by default. An interrupted in-place restore can therefore leave a live directory half old and half restored. Restic's own documentation recommends making a current backup before an in-place restore. For a single-file incident, a scratch restore followed by an explicit copy is easier to review and roll back.

Stop or quiesce the application if it may write the destination while you replace it. Preserve a copy of the current file, copy the recovered file with the ownership and mode the service expects, then start the service and run an application-level check.

Avoid --delete for this job. That option removes target files that are absent from the selected snapshot. It is useful for controlled directory reconciliation, but it is unnecessary risk when the goal is to recover one item. If you ever do use it, run the identical command with --dry-run -vv first.

Rested lets you choose a snapshot, browse its contents, select files or folders, and restore them to a separate location on the attached server. The web app coordinates the operation without receiving plaintext backup contents.

The result and logs remain in recovery history. Keep independent repository credentials and the recovery password so standard restic remains available if the original machine or dashboard is unavailable.