Backups rely on restic 🡕 : each host pushes its data to an encrypted repository, either local or remote via a zone REST server. The goal is a 3-2-1 strategy (multiple copies, multiple media, one off-site location).
Role Who What REST server Host with the restic service Stores zone repositories Client Host with enable = true Pushes its targets (backups)
A target saves one or more categories in sub-repositories:
Category Content systemRoot /, excluding volatile data and /nix, /srv… nfsShares /srv/nfs/... mediasMedia /srv/medias/...
A ~/Nextcloud folder (including numbered variants) replicates an original
already backed up on the server side, and restic does not deduplicate across
repositories: each replica would cost a full copy. Exclusion is done by path
and journal marker, across all categories.
Repository passphrase (restic-password-<zone>): encrypts the content.REST credential (restic/<host>/rest-password): authenticates the host. Both are generated by just configure-admin-host. See
Secrets .
The full operational configuration (REST server, targets, retention policy,
restoration) is detailed in the practical guide:
A rest: target whose server is unreachable is skipped , not marked as
failed : no immediate alert. It is ResticBackupStale (36 h) then
ResticBackupCritical (7 days) that report the missing backup. A remote
site that is down therefore shows up after a day, not after the first missed
night.
Each host exports the list of its jobs, along with their declaration date. A
job that has never succeeded is therefore reported 36 h after its
deployment. A removed job loses its metric at the next deployment : no
orphan alert.
