How to Automatically Create Versioned Backups When Files Change on Linux

On Linux, a file-watching program detects changes to selected files and starts a backup. Restic, a backup program, saves a snapshot: a record of those files at a particular time. Multiple snapshots let you restore an earlier version instead of only the latest files.

To watch a few known files, use a systemd path unit. This systemd configuration starts a service when a specified path changes. To watch a directory tree, use a watcher such as inotifywait that checks subdirectories recursively. Connect it to a backup job that runs one backup at a time. In either case, run scheduled backups too: Linux change notifications can be missed, so they should not be the only way your backups run.

Store snapshots with restic

First choose a backup destination separate from the files you want to protect. A different disk or remote destination helps protect the backup if the source disk fails. Initialize a restic repository, which is the storage location where restic keeps its encrypted backup data and snapshot records.

Run a test backup manually before automating it:

restic backup /path/to/data

Restic creates a snapshot for each backup run. It deduplicates data, so snapshots can share unchanged content instead of storing another full copy each time. By default, restic also creates a snapshot when it finds no changes; add --skip-if-unchanged to avoid that. The restic backup documentation describes snapshot creation and the option.

Keep the repository password and connection settings out of scripts that other users can read. Configure them through a secure method supported by your restic installation, then confirm the backup command works in the environment where the automated job will run.

Choose a trigger for the files you watch

For a few known files, a systemd path unit can start a service after a watched file is written and closed. In a path-unit file, PathChanged= watches a specific path; the associated service can run restic backup on the containing directory. For example, watching /home/alex/Documents/notes.txt and backing up /home/alex/Documents captures the file’s surrounding directory as well. Check the systemd path-unit documentation for the behavior supported by your installed version.

A path unit is not a recursive directory-tree watcher. If you need to watch a whole tree, use a recursive inotify-based watcher or another tool that manages watches for subdirectories. The inotifywait command can monitor events recursively. It can watch for close_write and create, as well as moved_to and delete. For example:

inotifywait --monitor --recursive \
  --event close_write --event create --event moved_to --event delete \
  /path/to/data

That command reports changes; it does not create backups by itself. Connect the watcher to a backup service that runs restic backup --skip-if-unchanged /path/to/data. Have the service run one backup at a time so two backups do not write to the same repository at once. A short debounce period, which groups a burst of events into one backup request, can also reduce unnecessary work when a program saves a file through several writes.

Add a scheduled backup and manage retention

Keep a scheduled backup even after you install a watcher. Linux’s inotify mechanism can combine repeated events, drop events if its queue overflows, and miss some changes on network filesystems. Recursive watch setup also has race conditions when new directories appear. The inotify manual and the inotifywait manual document these limits. A scheduled run gives restic another chance to capture files after a notification was missed.

Choose how long to keep snapshots separately from the trigger. Restic’s forget command removes snapshots according to a retention policy, which sets which snapshots to keep. prune later reclaims repository data no longer referenced by the snapshots you keep. Review proposed removals with --dry-run before applying a policy. For example, restic documents keeping daily and weekly snapshots, plus monthly and yearly snapshots. One snapshot can satisfy more than one period, so the total retained count is not necessarily the sum of those settings. Pruning can take time and hold a repository lock, which prevents backups from completing while maintenance is underway. See the restic retention documentation.

Test what you can restore

A successful backup run does not prove that the files you need can be recovered. List the snapshots, then restore a sample into a separate directory. Check that the restored files open correctly. Restic provides commands to inspect snapshots and restore their contents.

Live databases and other applications update several related files. A file-change notification does not guarantee a backup that captures those files in a consistent state. Use the application’s backup procedure or another method designed to capture a consistent state.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com