How to Schedule Restic Backup, Forget, and Prune Jobs Without Lock Conflicts

Schedule backups frequently, apply forget through one repository controller, and run prune less often inside an exclusive maintenance window. Do not let every host own all three jobs.

A shared home-server repository needs two kinds of timing: per-host recovery points and repository-wide maintenance. Build the schedule from measured durations and recovery goals, not fixed internet examples. Centralize retention and prune, group snapshots correctly, order units explicitly, and give every skipped job a retry and alert. The schedule is complete only after two cycles and a sample restore prove that retention and locking behave as intended.

Inventory Every Job, Owner, and Worst Normal Duration

Create one table for every operation that touches the repository: backup, forget, prune, check, unlock, snapshot listing, and restore test. Record the initiating host, command or wrapper, credential, normal and worst recent duration, timeout, retry rule, and alert destination. Include jobs hidden inside backup applications or NAS interfaces.

A shared repository needs repository-level maintenance rather than one copy per client. Practical multi-host Restic practice assigns forget, prune, and check once per repository while grouping retention for the relevant hosts and paths.

Consolidate duplicate maintenance jobs under one controller. Keep per-host backup ownership where it helps source access, but make every host report its start and finish state to the controller. If a job has no measured duration or no owner, observe it before placing a maintenance window around it.

Set Backup Cadence First, Then Scope Forget

Choose each host's backup cadence from the amount of change you can afford to lose and the time a backup normally takes. Stagger large source scans if they compete for network or storage, but do not spread jobs merely to make a chart look tidy. Let the longest normal backup define the earliest maintenance start.

Run forget from the repository controller and preview its selection using the intended host, path, and tag grouping. Unexpected calendar grouping can make retention remove more restore points than a simple keep-count reading suggests.

Keep forget logically separate from physical prune during schedule design. The previewed retention policy can run after a successful backup or in its own controller phase, while prune gets a longer exclusive window. Do not attach prune to every host's backup just because one command can combine them.

Place Prune and Check in Repository-Wide Windows

Run prune less frequently than backup and usually less frequently than forget, because physical repository cleanup can take much longer and blocks other work. Place it after all expected backups and retention selection finish. Give check its own phase or window based on repository size and backend speed.

A systemd Restic configuration can keep backup and pruning in separate services so the scheduler observes their exit states instead of launching one opaque command.

If prune regularly overruns the window, do not allow backups to pile up silently. Reduce prune frequency, widen the window, investigate backend throughput, or split repositories when their operational needs no longer fit. Entry requires no active backup; exit requires a clean maintenance status and a released repository lock.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Encode Dependencies, Retries, and Alerts

Encode the intended order rather than relying on clock gaps: backup units report completion, forget runs only after the required backups, prune runs only after the repository enters its exclusive window, and check follows the chosen maintenance policy. Use a shared external gate that all relevant units respect.

Systemd targets can express that backup and maintenance dependencies must complete in order rather than merely start at different clock times.

Set bounded retries for lock contention and network faults, then alert when the deadline is missed. A late backup should delay prune; an overrun prune should delay the next backup and notify the operator. Forced unlock and no-lock options are not retry policies.

Verify Two Full Cycles and One Restore

Watch two complete cycles rather than declaring success after the timer files load. Confirm each source produces the expected snapshot, forget keeps the intended groups, prune runs only in its window, locks clear after clean exits, and alerts record any delay.

Restore files from a snapshot that survived the retention and prune sequence, not only from the newest backup. That proves the complete schedule preserves a usable recovery point rather than merely producing green job statuses.

The schedule passes when two cycles complete in order, no job disappears silently, kept snapshots match the preview, and the sample restore is correct. Roll back maintenance automation while keeping normal backups if retention removes the wrong group, prune cannot finish reliably, or lock conflicts recur. Adjust cadence from measured results, not by disabling repository protection.