Les sauvegardes reposent sur restic 🡕 : chaque hôte
pousse ses données vers un dépôt chiffré, local ou distant via un serveur
REST de zone. L’objectif est une stratégie 3-2-1 (plusieurs copies, plusieurs
supports, un site distant).
Rôle Qui Quoi Serveur REST Hôte avec le service restic Stocke les dépôts de la zone Client Hôte avec enable = true Pousse ses targets (sauvegardes)
Une cible sauvegarde une ou plusieurs catégories dans des sous-dépôts :
Catégorie Contenu systemRacine /, hors données volatiles et /nix, /srv… nfsPartages /srv/nfs/... mediasMédias /srv/medias/...
Les dossiers de synchro cloud ne sont jamais sauvegardés
Un dossier ~/Nextcloud (variantes numérotées comprises) réplique un original
déjà sauvegardé côté serveur, et restic ne dédoublonne pas entre dépôts :
chaque réplica coûterait une copie pleine. L’exclusion se fait par chemin et
par marqueur de journal, sur toutes les catégories.
Deux secrets, à ne pas confondre
Passphrase de dépôt (restic-password-<zone>) : chiffre le contenu.
Credential REST (restic/<hôte>/rest-password) : authentifie l’hôte.
Les deux sont générés par just configure-admin-host. Voir
Secrets .
La configuration opérationnelle complète (serveur REST, cibles, politique de
rétention, restauration) est détaillée dans le guide pratique :
Une sauvegarde hors-site absente ne crie pas tout de suite
Une cible rest: dont le serveur est injoignable est sautée , pas mise en
échec : pas d’alerte immédiate. C’est ResticBackupStale (36 h) puis
ResticBackupCritical (7 jours) qui signalent l’absence de sauvegarde. Un
site distant éteint se voit donc au bout d’une journée, et non à la première
nuit manquée.
Un job jamais réussi alerte aussi
Chaque hôte exporte la liste de ses jobs, avec leur date de déclaration. Un job
qui n’a jamais réussi est donc signalé 36 h après son déploiement. Un job
retiré perd sa métrique au déploiement suivant : pas d’alerte orpheline.