A configuration file that is deleted or replaced too quickly can put a service in the wrong state. With Restic, the trap is restoring directly to the active path. First, recover the file in a test directory, then compare it before any copying.
The method starts from an already initialized repository that is accessible with the usual credentials. It targets a specific file, for example /etc/my-service/config.ini, and leaves the currently used version intact until the check is completed.
Identify the snapshot and the path to recover
Define the repository using the same variables or the same environment file as your backup. Avoid pasting the repository password into the Bash history. If the Restic service is already running in a script or a systemd unit, take its authentication mechanism instead of creating a new one for the restoration.
Start by listing the snapshots that contain the desired path:
export RESTIC_REPOSITORY=/srv/restic-repo
restic snapshots --path /etc/my-service/config.iniThe output displays the identifiers, date, host, and backed-up paths. Choose a specific identifier rather than latest if multiple machines or multiple backups can contain this file. In this example, replace 8f3a1c2d with the chosen identifier.
SNAPSHOT=8f3a1c2d
restic ls "$SNAPSHOT" --path /etc/my-service/config.inirestic ls confirms the path present in the archive before writing anything. If no result matches, stop there. A mistyped path or a snapshot taken after the incident will not be repaired by a second restoration.
Restore to a test directory
Create a directory reserved for checking. It must not be a production mount point or the affected service folder:
sudo install -d -m 0700 /srv/restore-restic-test
restic restore "$SNAPSHOT"
--target /srv/restore-restic-test
--include /etc/my-service/config.iniRestic recreates the hierarchy under the target. The restored file is therefore located here:
/srv/restore-restic-test/etc/my-service/config.iniThis separate directory prevents overwriting /etc/my-service/config.ini during the test. It is the choice to maintain for a service file, a configuration key, or an exported database. A direct restoration to the root turns a snapshot error into a production incident.
Compare the file before putting it back into service
First, check the permissions, size, and differences. The diff command does not modify any files:
sudo stat /etc/my-service/config.ini
sudo stat /srv/restore-restic-test/etc/my-service/config.ini
sudo diff -u
/etc/my-service/config.ini
/srv/restore-restic-test/etc/my-service/config.iniA diff with no output returns code 0: both contents are identical. If it displays removed and added lines, read them before deciding. An old address, a port, or an expired secret may be exactly the reason the file changed.
When the restored copy is the right one, first back up the active version, then replace it in a short maintenance window. Then check the syntax and status of the service with the commands appropriate for your software, for example systemctl status my-service and the associated log.
The restoration check deserves the same care as a backup. The guide BorgBackup applies the same logic with an extraction out of production. To find a path before launching Restic, the command find on Linux prevents restoring a homonymous file to the wrong location.
When not to restore a single file
An isolated file is sufficient for a deleted configuration or an overwritten version. It is not always sufficient for an application that spreads its state between a database, files, and a transaction log. In this case, restore a consistent set in a VM or an isolated directory, then validate the procedure with the service stopped or a test copy.
The Restic documentation on restoration describes targeting by snapshot, path, and destination directory. Keep the test directory until the final verification. Its deletion after validation does not affect the Restic repository or the active file.