La définition inconfortable d'une sauvegarde
Voici la phrase qui devrait être affichée au-dessus de chaque script de sauvegarde : une sauvegarde que vous n'avez jamais restaurée est une hypothèse, pas une sauvegarde. Un cron qui copie des fichiers quelque part, c'est facile. Un dépôt que vous pouvez déchiffrer, lire et restaurer dans un système fonctionnel le pire jour de votre année, c'est tout autre chose, et l'écart entre les deux est exactement là où l'on découvre — trop tard — que l'archive était vide, que la passphrase est perdue, ou que la copie « hors site » reposait sur le même disque qui vient de mourir.
Cet article ne porte donc pas sur l'installation d'un outil de sauvegarde. Il porte sur le montage dans la forme qui survit au contact d'un vrai incident : chiffrée avant de quitter la machine, planifiée pour que personne n'ait à y penser, et prouvée par une restauration réelle. restic et Borg font tous deux cela très bien ; les commandes sont triviales, et la discipline autour d'elles est tout le travail.
Avant le premier paquet : lire ce que vous protégez
Une sauvegarde qui pointe vers le mauvais dossier, ou qui double un dépôt déjà existant, est pire que rien — elle a l'air d'une protection sans rien protéger. La reconnaissance fait la différence.
- L'outil est-il déjà là ?
command -v restic && restic version, oucommand -v borg && borg --version. Si oui, vous avez peut-être déjà un dépôt et un timer — auditez-les avant d'en ajouter un second, concurrent. - La source existe-t-elle vraiment ?
test -d /var/www && echo ok || echo missing. Une sauvegarde d'un chemin absent est une coche verte au-dessus de rien. Confirmez le dossier avant de planifier quoi que ce soit dessus. - Où est le dépôt, et est-il hors de cette machine ? Un dépôt local sur le même disque que vos données vous protège d'un
rm -rf, pas d'une panne de disque. Si le plan est S3 ou un hôte distant, vérifiez que vous pouvez l'atteindre avant la première exécution, pas pendant la première panne.
1. Installer l'outil — et savoir ce que le « chiffrement côté client » vous apporte
L'installation est l'étape la moins intéressante : apt-get update && apt-get install -y restic, ou apt-get install -y borgbackup. La preuve que ça a marché est une chaîne de version de restic version ou borg --version — pas le fait qu'apt soit sorti à zéro.
Ce qui compte réellement, c'est une propriété que les deux outils partagent : ils chiffrent sur la machine, avant que quoi que ce soit ne soit écrit dans le dépôt. Le bucket, l'hôte distant, le disque externe — aucun ne voit jamais vos fichiers en clair. C'est la même forme qu'un système zero-knowledge : l'endroit qui stocke vos données ne peut pas les lire. Cela signifie qu'un bucket S3 qui fuit, ou un fournisseur de stockage à qui vous ne faites pas pleinement confiance, fuit du chiffré. Cela signifie aussi que la clé de chiffrement est désormais quelque chose dont vous êtes responsable, ce qui est l'arbitrage que vous faites et le risque traité plus bas.
2. Initialiser le dépôt, délibérément
Avec restic, restic init contre la cible — un chemin local, une URL S3, un hôte SFTP — crée le dépôt chiffré. Avec Borg, le choix à rendre explicite est le mode de chiffrement : borg init --encryption=repokey-blake2 garde le matériel de clé dans le dépôt, protégé par une passphrase, ce qui est le défaut sensé pour un serveur qui se sauvegarde lui-même.
La décision la plus lourde de conséquences de tout cet exercice est l'endroit où vit le mot de passe du dépôt ou la passphrase Borg. Il ne doit jamais se trouver dans un fichier lisible par tous, dans l'historique du shell, ni dans une ligne de log. Mettez-le dans un fichier lisible uniquement par le compte qui lance la sauvegarde (mode 600), gardez une copie dans un gestionnaire de mots de passe hors de la machine, et comprenez la conséquence en entier : ce secret est la seule chose entre une panne de disque et une reprise totale — et aussi la seule chose qui, perdue, rend les données irrécupérables pour toujours. Ce n'est pas un bug. C'est le prix du chiffrement côté client, et il vaut la peine d'être payé les yeux ouverts.
La vérification de cette étape n'est pas « la commande est sortie à 0 ». C'est restic snapshots ou borg info "$BORG_REPO" qui répond — un dépôt qui rapporte son propre état est un dépôt qui existe et que votre clé peut ouvrir.
3. Planifier avec un timer systemd, et pruner avec intention
L'exécution planifiée est un timer systemd, pas une ligne enfouie dans un crontab que personne ne lit. Un timer est introspectable — systemctl list-timers montre quand il a tourné pour la dernière fois et quand il tourne ensuite — et cette visibilité est tout l'intérêt. Vérifiez qu'il existe avec systemctl list-timers | grep -c restic (ou borg), et vous avez la preuve que le job est planifié plutôt que la croyance qu'il l'est.
La rétention est là où une sauvegarde reste utile ou vire en silence à la facture sans limite. Les deux outils prunent les vieux snapshots selon une politique — garder tant de quotidiens, d'hebdomadaires, de mensuels — avec restic forget --prune ou borg prune. La règle qui compte : un prune supprime des archives, c'est donc la seule partie du pipeline à traiter avec le même soin qu'une suppression. Ne prunez jamais des archives dont vous n'avez pas confirmé qu'elles sont remplacées, et ne pointez jamais un prune vers un dépôt dont vous n'avez pas lu la rétention. Une politique de rétention trop agressive est un incident de perte de données au ralenti qui ressemble à du ménage.
Ce qu'une sauvegarde ne vous donne pas
Un timer qui tourne n'est pas une restauration qui marche — les deux ne sont liés que par l'espoir jusqu'à preuve du contraire. Un dépôt n'est pas un rollback : restic et Borg servent à récupérer des données sur des minutes ou des heures, pas à défaire un mauvais déploiement en secondes ; c'est le rôle d'un snapshot avant un changement risqué. Le chiffrement côté client ne vous protège pas de la perte de la clé — perdez la passphrase et le dépôt est du bruit, pour toujours, par conception. Et une copie unique n'est pas une stratégie de sauvegarde : la vieille règle du 3-2-1 — trois copies, deux médias, une hors site — existe parce que la panne qui emporte vos données emporte souvent tout ce qui est juste à côté. La commodité n'est pas la récupérabilité.
La vérification qui prouve que vous pouvez récupérer
Dans l'ordre : restic version ou borg --version pour l'outil ; un dépôt qui répond à restic snapshots / borg info pour savoir que votre clé l'ouvre ; systemctl list-timers montrant le timer planifié et sa dernière exécution réussie ; et — celle qui compte réellement — une vraie restauration de test dans un dossier temporaire, comparée à la source, pour avoir restauré les données au moins une fois avant d'en avoir besoin. Une restauration que vous avez effectuée est la seule vérification qu'une sauvegarde réussit vraiment.
Ce que Servor apporte là-dedans
Servor livre les sauvegardes restic et Borg comme des recettes — parmi 150+ playbooks vérifiés — et la forme d'une recette est ce qui empêche une tâche « on la pose et on l'oublie » d'être oubliée de la mauvaise façon. Une recette n'est pas un script tiré à l'aveugle : elle commence par la reconnaissance, en lisant si l'outil est installé et si le dossier source existe seulement, pour ne jamais planifier la sauvegarde de rien. Chaque étape porte sa propre vérification — la chaîne de version, le dépôt qui répond, le timer listé — si bien que le run prouve qu'il a marché. Le playbook est idempotent : un dépôt existant est vérifié et rapporté, pas réinitialisé par-dessus, et il ne supprimera pas d'archives en silence.
Les guardrails sont écrits parce que les défauts sont dangereux : le mot de passe du dépôt n'est jamais placé dans un fichier lisible par tous ni dans un log, et un prune est traité comme l'opération destructrice qu'il est — proposé et expliqué, pas glissé en douce. Et l'exécution ne quitte jamais le chemin zero-knowledge : chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l'agent sur la machine avant de s'exécuter. L'agent atteint le plan de contrôle via une connexion sortante, si bien qu'une cible de sauvegarde sur un réseau verrouillé n'a jamais besoin d'un trou entrant.
Pour l'angle spécifique aux bases de données — dumps, reprise à un instant donné, la différence entre une copie et un snapshot cohérent — voyez l'article PostgreSQL en production. Pour la discipline qui rend tout changement risqué réversible, lisez l'article sur les opérations destructrices sûres, et la boucle approuver-signer-vérifier derrière tout cela est dans l'article Plan-Execute-Verify. Parcourez le reste du catalogue de recettes, ou voyez comment tout s'articule dans notre guide d'exploitation des serveurs.