Ce qui tourne mal, vraiment
La panne de disque est le scénario qu’on imagine, et c’est le plus rare et le mieux couvert.
Les scénarios réels sont ailleurs. Le rançongiciel, qui chiffre le poste et tout ce qui lui est accessible, disque de sauvegarde compris s’il est branché. La suppression par erreur, découverte trois semaines plus tard, quand toutes les copies récentes contiennent déjà l’absence. Le départ d’une personne, avec des fichiers qui n’existaient que sur son poste. La corruption silencieuse, où les fichiers existent, sont copiés fidèlement, et sont inexploitables.
Ces quatre scénarios ont un point commun : une simple copie du dernier état ne protège d’aucun. Il faut de l’historique, de la distance, et de la vérification.
Ce qu’on automatise
La copie. Quotidienne au minimum, plus fréquente sur les données qui bougent, sans intervention et sans y penser.
Le chiffrement avant départ. Les données sortent déjà illisibles. La confiance dans l’hébergeur du dépôt devient sans objet.
La rotation. Combien de versions quotidiennes, hebdomadaires, mensuelles on garde, et ce qu’on supprime — automatiquement, selon une règle écrite.
La vérification d’intégrité. L’archive est relue et ses empreintes recalculées, pour détecter une corruption au repos avant d’en avoir besoin.
Le test de restauration. Un échantillon est effectivement restauré chaque semaine, dans un espace isolé, et comparé à l’original. C’est le point qui distingue une sauvegarde d’un espoir.
L’alerte. Si une sauvegarde n’a pas eu lieu, si un test échoue, vous le savez le jour même — pas le jour du sinistre.
Comment ça marche techniquement — pour qui veut le détail
L’outil de sauvegarde. Restic pour les fichiers et les volumes. Trois propriétés en font le bon choix ici : chiffrement de bout en bout côté client — le dépôt ne voit jamais de clair —, déduplication par blocs de taille variable, de sorte qu’un fichier de 2 Go modifié à la marge ne recoûte pas 2 Go, et instantanés immuables avec une commande de vérification intégrée (restic check --read-data-subset). Les alternatives sérieuses — Borg, Kopia — partagent ces propriétés ; ce qui compte est le chiffrement côté client et la vérification.
Les bases de données ne se sauvegardent pas comme des fichiers. Copier le répertoire de données d’un PostgreSQL en fonctionnement produit une archive incohérente. On utilise pg_dump pour une sauvegarde logique rejouable, et l’archivage des journaux de transactions (WAL) avec un outil comme pgBackRest ou barman quand on veut pouvoir revenir à un instant précis — restauration à l’instant T, ce qui permet de se placer juste avant une commande destructrice. Même logique pour les autres moteurs.
Les conteneurs. Ce qui compte n’est pas l’image — elle se reconstruit — mais les volumes et la configuration. Un plan de sauvegarde qui archive les images Docker et oublie /var/lib/docker/volumes protège ce qui est jetable et perd ce qui est unique. Les fichiers compose, les variables d’environnement et les secrets font partie du périmètre, chiffrés.
La destination. Un dépôt distant chez un hébergeur différent de celui qui héberge la production — mettre les deux au même endroit annule l’intérêt du hors-site. Quand c’est possible, un stockage objet avec verrouillage (Object Lock, mode conformité) : une sauvegarde écrite ne peut plus être modifiée ni supprimée avant l’échéance, même avec les identifiants d’administration. C’est la seule protection réelle contre un attaquant qui a pris le contrôle et cherche d’abord à détruire les sauvegardes.
La séparation des droits. La machine sauvegardée possède des identifiants qui permettent d’écrire dans le dépôt, jamais d’y supprimer. La purge est exécutée par un second acteur, avec d’autres identifiants, depuis un autre endroit. Sans cette séparation, compromettre le serveur suffit à effacer l’historique.
La planification. Des timers systemd plutôt que cron : journalisation intégrée, Persistent=true pour rattraper une exécution manquée après une extinction, et état consultable (systemctl list-timers). Chaque exécution rapporte son résultat.
Le test de restauration, concrètement. Chaque semaine, un flux n8n tire un instantané au hasard, restaure un sous-ensemble dans un conteneur jetable, compare les empreintes SHA-256 avec la source, restaure un vidage de base dans une instance temporaire et y exécute quelques requêtes de contrôle — nombre de lignes des tables principales, date de l’enregistrement le plus récent. Le résultat est journalisé et publié dans un tableau de bord. Un test rouge déclenche une alerte au même titre qu’une panne.
La surveillance par battement. Chaque sauvegarde réussie appelle un point de contrôle Uptime Kuma en mode push. L’absence d’appel est ce qui déclenche l’alerte — une sauvegarde qui ne s’exécute plus du tout est silencieuse par nature, et c’est précisément le mode de panne le plus fréquent.
Syncthing n’est pas une sauvegarde. La synchronisation continue entre machines est excellente pour disposer de ses fichiers partout, et elle propage une suppression ou un chiffrement malveillant en quelques secondes. Les deux mécanismes sont complémentaires, jamais substituables.
Le document de reprise. Un fichier écrit, conservé hors de l’infrastructure sauvegardée : où est le dépôt, où sont les clés, dans quel ordre remonter les services, quels DNS changer, qui appeler. Une procédure de reprise stockée uniquement sur le serveur à restaurer est une plaisanterie classique du métier.