Sauvegarde et restauration de VPS : chiffrées, hors site, et réellement testées

Les instantanés ne sont pas des sauvegardes — et vous voulez les deux

Un instantané est une copie d'un volume à un instant donné, qui réside sur la même infrastructure de stockage que le volume qu'il copie. Ce n'est pas une critique, c'est une description, et elle explique précisément ce pour quoi un instantané excelle et ce qu'il ne peut pas faire. Chaque offre proposée ici inclut des instantanés horaires avec une rétention de sept jours ; en restaurer un prend environ trente secondes, et c'est la réponse adaptée à l'incident le plus courant dans l'exploitation d'un serveur : vous avez modifié un fichier de configuration à quatre heures de l'après-midi et le service n'a plus démarré depuis. Face à ce type de défaillance, rien d'autre ne s'en approche — c'est plus rapide que n'importe quel outil de sauvegarde, c'est déjà en cours d'exécution, et cela ne coûte rien de plus.

Ce qu'un instantané ne peut pas faire, c'est survivre à ce sur quoi il est stocké. Il partage le sort du volume, de l'hôte, de l'hyperviseur et, dans la plupart des architectures, du compte. Si la machine est saisie, si le compte est fermé, si le datacenter connaît une très mauvaise journée, les instantanés disparaissent aussi — ce sont une copie des données, et non une copie indépendante. Cette distinction n'a rien de théorique chez un hébergeur qui, délibérément, ne peut pas vous identifier : il n'existe aucune procédure de support qui reconstruit votre serveur à partir des dossiers de quelqu'un d'autre, aucun parcours de récupération rattaché à un numéro de téléphone, et aucun historique de facturation associé à votre nom légal. Ce que vous avez pris est ce que vous avez.

Une fenêtre de sept jours n'aide pas non plus face aux deux défaillances lentes. Le fichier que vous avez supprimé il y a cinq semaines a disparu de tous les instantanés bien avant que vous ne le remarquiez. La corruption silencieuse — une application défaillante qui écrit des données subtilement erronées, une mauvaise migration, un client de synchronisation qui propage fidèlement une erreur — est souvent découverte un mois plus tard, quand chaque copie conservée contient déjà la corruption. Ce sont les sauvegardes à rétention plus longue et à historique réel qui couvrent ces cas, et elles les couvrent précisément parce qu'elles ne sont pas des miroirs continus de l'état courant.

Le cadre de référence à retenir ici est ancien et reste valable. La règle du 3-2-1 demande trois copies des données, sur deux types de support différents, dont une hors site. Le complément moderne ajoute deux chiffres supplémentaires — 3-2-1-1-0 — où le 1 supplémentaire est une copie immuable ou hors ligne, et le 0 correspond au nombre d'erreurs constatées lors de votre dernière vérification. Ces chiffres forment un moyen mnémotechnique plutôt qu'une norme, mais ils codifient les trois propriétés qui comptent réellement : l'indépendance, l'immuabilité, et la preuve que cela fonctionne. Les instantanés horaires ne vous en donnent qu'une des trois.

Lisez ce tableau comme un argument en faveur de l'utilisation des deux plutôt que d'un choix entre les deux. Les instantanés prennent en charge la fréquence et la rapidité ; les sauvegardes prennent en charge l'indépendance et l'historique. Ils coûtent des choses différentes, ils échouent de façons disjointes, et la combinaison est bien plus solide que l'une ou l'autre doublée.

Les deux chiffres qui décident de tout le reste

Avant d'installer le moindre outil, notez deux chiffres. L'objectif de point de reprise correspond à la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps — si la dernière copie exploitable date de six heures, votre RPO est de six heures, et les six heures de travail effectuées entre-temps sont perdues. L'objectif de délai de reprise correspond à la durée pendant laquelle vous pouvez vous permettre d'être indisponible le temps de reconstruire. Tout ce qui en découle — calendrier, méthode, emplacement de la deuxième copie, montant dépensé — dépend de ces deux chiffres, et choisir un logiciel avant de les choisir est la façon dont on se retrouve avec une réponse élaborée à une question que personne n'a posée.

Interrogées de façon informelle, la plupart des personnes répondent zéro et zéro. Ce n'est pas un budget, c'est un vœu, et il a un coût qui mérite d'être énoncé clairement : un RPO proche de zéro implique une réplication continue plutôt que des copies planifiées, et un RTO proche de zéro implique une deuxième machine déjà active en veille chaude. Les deux sont réalisables, et les deux doublent à peu près le coût d'exploitation de ce que vous protégez. Pour l'immense majorité des charges de travail auto-hébergées, les réponses honnêtes se situent quelque part entre une heure et une journée pour le point de reprise, et quelques heures pour le délai de reprise, ce qui est confortablement couvert par une sauvegarde chiffrée planifiée et une reconstruction documentée.

Ces chiffres diffèrent aussi selon le jeu de données, sur une même machine, et c'est ce détail qui les rend utiles. La messagerie en est l'exemple le plus frappant : un message arrivé il y a vingt minutes n'existe nulle part ailleurs, ne peut pas être régénéré, et son expéditeur n'a aucune idée qu'il doit le renvoyer — un serveur de messagerie veut donc un point de reprise mesuré en minutes, même si le logiciel lui-même se réinstalle en un après-midi. Un nœud Bitcoin inverse complètement cette logique : les données de la chaîne représentent plusieurs centaines de gigaoctets que n'importe quel pair du réseau vous renverra volontiers, si bien que les sauvegarder est en grande partie un gaspillage d'espace disque, tandis que le fichier de portefeuille situé à côté est irrécupérable et mérite d'être protégé comme une clé privée, car c'est exactement ce qu'il est.

Cette dernière ligne mérite d'être dite à voix haute, car un guide sur les sauvegardes a une incitation évidente à ne pas le faire. Certaines machines n'en ont pas besoin. Un agent de build dont l'état tient entièrement dans un dépôt git, un bac à sable jetable, un reverse proxy sans état dont la configuration vit dans un gestionnaire de versions — pour ceux-là, les instantanés horaires inclus dans l'offre sont une réponse complète et défendable, et la juste quantité d'ingénierie de sauvegarde est nulle. Savoir lesquels de vos serveurs relèvent de cette catégorie a plus de valeur que de tous les sauvegarder, mais mal.

Quoi copier — et la pile, bien plus grande, que vous devriez laisser de côté

Le réflexe est de faire une image du disque entier, et sur une machine virtuelle louée, ce réflexe est erroné. Le système d'exploitation est jetable : ici, une nouvelle instance est provisionnée en quarante et une secondes en médiane, et réinstaller les paquets depuis un miroir de la distribution est plus rapide et plus fiable que de les restaurer depuis votre propre copie. Ce qui n'est pas jetable est un ensemble étonnamment restreint, et la discipline consistant à nommer explicitement cet ensemble constitue l'essentiel du travail — une sauvegarde que vous pouvez décrire en un paragraphe est une sauvegarde que vous pouvez vérifier, tandis qu'une image de disque entier est une chose que l'on ne fait qu'espérer.

L'ensemble irremplaçable comprend généralement quatre éléments. Premièrement, les données applicatives : le maildir, le répertoire de données, le stockage média, le dossier d'uploads. Deuxièmement, les bases de données, qui nécessitent un traitement à part et font l'objet de la section suivante. Troisièmement, les secrets — et c'est la catégorie que l'on oublie jusqu'à ce que cela coûte cher. Les clés privées TLS et la clé de compte ACME, les clés d'hôte SSH si vous préférez ne pas avoir à refaire confiance à l'empreinte sur chaque client, la clé de signature DKIM sans laquelle votre messagerie échoue à l'authentification, les clés privées WireGuard, et surtout la clé privée du service onion, qui est l'adresse .onion : perdez-la, et l'adresse a disparu pour toujours, sans aucun registre nulle part auprès duquel faire appel. Quatrièmement, la poignée de fichiers sous /etc que vous avez réellement modifiés, plus les unités systemd, les entrées cron et l'ensemble de règles du pare-feu qui font que la machine se comporte comme elle le fait.

La pile à laisser de côté est bien plus grande, et pour l'essentiel évidente une fois énoncée. Les pseudo-systèmes de fichiers comme /proc, /sys et /dev sont des vues du noyau plutôt que des données. Les caches de paquets, les images de conteneurs, les environnements virtuels et les répertoires de dépendances sont tous re-dérivables en quelques secondes à partir d'un fichier de verrouillage. Les journaux au-delà de votre politique de rétention sont du bruit qui se déduplique mal et qui alourdit chaque exécution suivante. Et les grands jeux de données resynchronisables — l'état d'une blockchain, un miroir public, une bibliothèque multimédia que vous pouvez re-ripper — méritent une décision explicite plutôt qu'un choix par défaut : sauvegarder trois cents gigaoctets de données de la chaîne coûte de l'argent réel chaque mois, pour éviter une resynchronisation que vous pourriez effectuer gratuitement pendant que le service tourne en mode dégradé mais fonctionnel.

La partie dans laquelle presque tout le monde sous-investit est la réponse à « restaurer vers quoi ? ». Des données sans cible ne constituent pas une restauration. Si la manière dont votre serveur a été construit n'existe que dans votre mémoire et un historique de shell que vous avez depuis perdu, votre délai de reprise est illimité, quelle que soit la qualité du dépôt. Le correctif est bon marché et sans intérêt : conservez les étapes de provisionnement sous forme de script ou de runbook en texte brut, placez-le à l'intérieur du dépôt de sauvegarde afin qu'il soit restauré en même temps que les données, et mettez-le à jour chaque fois que vous modifiez la machine. Même une centaine de lignes de notes — paquets, versions, emplacements des fichiers de configuration, enregistrements DNS, l'ordre dans lequel les services doivent démarrer — transforme une mauvaise semaine en une mauvaise après-midi.

Une nuance mérite d'être signalée pour quiconque utilise le chiffrement intégral du disque : l'en-tête LUKS et ses emplacements de clés font eux aussi partie de votre ensemble irremplaçable. Un en-tête corrompu transforme un disque parfaitement intact en bruit aléatoire, l'en-tête ne pèse que quelques mégaoctets, et le sauvegarder ne coûte rien. Conservez-le avec autant de soin que la phrase de passe — quiconque détient les deux détient le disque.

Bases de données : le fichier que vous copiez n'est pas la base de données

C'est la manière la plus courante dont une sauvegarde par ailleurs compétente s'avère sans valeur. Un moteur de base de données conserve son état en mémoire, dans un write-ahead log ou un redo log, et dans des fichiers de données modifiés en continu. Copier ces fichiers pendant que le moteur fonctionne les capture à des instants différents — la page quatre d'une table avant une transaction, la page cinq après — et le résultat est un ensemble de fichiers individuellement intacts et collectivement incohérents. Le plus cruel, c'est qu'une telle copie se restaure généralement sans problème. Elle démarre, elle répond aux requêtes, et les dégâts n'apparaissent que des semaines plus tard, sous la forme d'un index corrompu ou d'une ligne qui viole une contrainte que le moteur jurait pourtant respecter. Une sauvegarde qui échoue bruyamment est bien préférable à une sauvegarde qui échoue silencieusement.

La bonne approche dépend du moteur, et elle est bien documentée dans chaque cas. Pour MariaDB et MySQL, un export logique réalisé dans une transaction unique et cohérente convient pour tout ce qui va jusqu'à quelques dizaines de gigaoctets ; au-delà, Mariabackup effectue une copie physique à chaud pendant que le serveur tourne. Pour PostgreSQL, pg_dump vous donne un instantané logique portable, et pg_basebackup combiné à des write-ahead logs archivés vous donne la restauration à un point dans le temps — la possibilité de restaurer jusqu'à 14:32 plutôt que jusqu'au moment où le dernier export a pu s'exécuter. Pour SQLite, utilisez la sauvegarde en ligne intégrée ou VACUUM INTO ; utiliser cp sur un fichier de base de données actif est exactement l'erreur décrite plus haut, et SQLite est le moteur sur lequel on la commet le plus souvent, parce qu'il ressemble à un fichier ordinaire.

La cohérence entre la base de données et les fichiers qu'elle décrit constitue la seconde moitié du problème, et c'est la moitié qui touche particulièrement les logiciels de synchronisation de fichiers et les forums. La base de données indique qu'un fichier existe à un certain chemin ; le système de fichiers est l'endroit où vivent les octets ; si vous exportez la base de données à 02:00 et copiez le répertoire de données à 02:40, tout ce qui a été créé entre les deux existe soit comme des octets sans ligne correspondante, soit comme une ligne sans octets correspondants. Les applications qui proposent un mode maintenance — Nextcloud est l'exemple le plus évident — résolvent ce problème en refusant brièvement les écritures pendant que les deux sont capturés. Lorsque cela n'est pas acceptable, un instantané du système de fichiers ou du volume pris en un seul instant vous donne une paire cohérente à partir de laquelle copier à votre rythme, ce qui est exactement l'astuce qu'utilisent les instantanés horaires.

Un petit détail opérationnel se rentabilise immédiatement : écrivez les exports non compressés et laissez l'outil de sauvegarde gérer la compression. Restic et borg déduplent tous deux par découpage en blocs défini par le contenu, si bien que deux exports pris à un jour d'intervalle partagent l'écrasante majorité de leurs blocs, et le second ne coûte presque rien à stocker. Compressez d'abord l'export, et un seul octet modifié près du début se répercute sur l'ensemble du flux compressé, plus aucun bloc ne correspond à rien, et chaque exécution stocke une copie complète. Les équipes constatent régulièrement que leur dépôt grossit chaque jour de la taille complète de la base de données, précisément pour cette raison — le correctif consiste à supprimer un seul pipe d'un script shell.

Enfin, décidez délibérément si vous avez besoin de la restauration à un point dans le temps, car c'est la réponse à une défaillance que l'export quotidien ne peut pas couvrir. Si quelqu'un exécute une requête destructrice à 14:32 et que vous le découvrez à 17:00, restaurer l'export de la nuit précédente vous fait perdre une journée de travail. L'archivage continu, lui, rejoue le journal jusqu'à 14:31. Cela coûte plus de stockage et sensiblement plus de complexité opérationnelle, ce n'est donc pas un choix par défaut — mais dans tous les cas où un humain disposant d'un accès en écriture peut détruire des données plus vite que vous ne pouvez vous en rendre compte, c'est la différence entre un incident et une catastrophe.

Chiffrer avant que cela ne sorte : restic, borg, et la clé que vous ne devez pas perdre

La propriété qui rend possible tout le reste de ce guide est le chiffrement côté client : les données sont chiffrées sur la machine qui les a produites, avant qu'un seul octet ne traverse le réseau, à l'aide d'une clé que la destination ne voit jamais. Cette seule décision de conception transforme la cible de la sauvegarde en un stockage non fiable, et un stockage non fiable peut se trouver n'importe où — un serveur bon marché dans un autre pays, un stockage objet, le NAS d'un ami — sans qu'aucun d'entre eux ne soit en mesure de lire vos données. Les hébergeurs qui chiffrent côté serveur vous protègent d'un ensemble de menaces différent et bien plus restreint, et cette différence compte le plus précisément dans les situations pour lesquelles vous achetez un hébergement offshore afin d'y survivre.

Restic et Borg font tous deux cela correctement, et le choix entre les deux est réellement serré. Restic est un binaire statique unique sans dépendances, qui parle nativement une longue liste de backends — SFTP, stockage objet compatible S3, simples chemins locaux — et qui est le plus facile des deux à exécuter depuis un conteneur ou une image minimale. Borg est l'outil le plus ancien et, à certains égards, le plus chirurgical, avec des options de compression plus poussées, un excellent support de l'append-only côté serveur, et un format de dépôt que beaucoup trouvent plus facile à appréhender ; il exige que borg soit installé aux deux extrémités lorsqu'on passe par SSH, une contrainte mineure qui, à l'occasion, fait pencher la balance.

Quel que soit votre choix, la phrase de passe est désormais ce qui compte vraiment, et elle mérite d'être traitée comme vous traiteriez la phrase de récupération d'un portefeuille. Elle ne doit pas résider uniquement sur la machine qu'elle protège — une phrase de passe stockée à côté des données qu'elle chiffre ne vous protège précisément contre rien, parce que tout scénario qui emporte le serveur emporte la clé avec lui. Placez-la dans un gestionnaire de mots de passe sur un autre appareil, ou sur papier dans un autre bâtiment, et idéalement les deux. Borg permet d'exporter la clé du dépôt vers un fichier séparé, restic permet à un dépôt de porter plusieurs clés indépendantes, et l'un comme l'autre mécanisme vous donne un second moyen d'accès qui ne dépend pas de la mémorisation d'une chaîne de caractères. Il n'existe ni récupération, ni lien de réinitialisation, ni ticket de support qui puisse annuler cela : un dépôt chiffré sans sa clé est indiscernable de données aléatoires, ce qui est précisément le but recherché.

Il vaut la peine d'expliciter pourquoi un simple rsync vers un autre serveur n'en est pas un substitut, puisque c'est la première chose vers laquelle les gens se tournent. Rsync produit un miroir, et un miroir n'a pas d'historique : supprimez un fichier aujourd'hui, et l'exécution de ce soir le supprimera fidèlement là-bas aussi. Il n'a pas de déduplication, si bien que conserver trente jours signifie trente copies, à moins de ruser avec des liens durs. Il n'a pas de chiffrement au repos intégré, si bien que la destination lit tout. Et il n'a pas d'autre forme de vérification que de relire la source. C'est un excellent moyen de transport et une mauvaise sauvegarde, et la distinction se manifeste le jour où vous avez besoin de la version d'il y a trois semaines.

Append-only, ou ce n'est qu'une copie plutôt qu'une sauvegarde

Voici le scénario qui détermine l'architecture. Quelqu'un obtient les droits root sur votre serveur — via une application non corrigée, un jeton divulgué, une dépendance devenue malveillante. Il se trouve désormais à l'intérieur d'une machine qui détient des identifiants valides vers sa propre cible de sauvegarde, parce que c'est ainsi que fonctionnent les sauvegardes planifiées. Tout ce que cette machine peut supprimer, il peut le supprimer, et supprimer les sauvegardes n'est pas une réflexion après coup dans une intrusion moderne, c'est la première étape. La même logique s'applique sans adversaire : un script bien intentionné avec une variable mal placée, exécuté en tant que root, est parfaitement capable de purger un dépôt jusqu'à ne plus rien laisser.

Le contrôle qui referme cette faille est l'application de l'append-only côté réception. Configuré ainsi, le client peut créer de nouveaux snapshots et ne peut ni supprimer ni réécrire les anciens — la restriction est imposée par le processus sur l'hôte de sauvegarde, pas par la bonne volonté du client. Borg l'implémente avec borg serve --append-only, épinglé à la clé dans le authorized_keys de la cible, de sorte que le client ne puisse rien demander d'autre. Restic offre la même chose via rest-server avec --append-only. Sur du stockage objet, l'équivalent est le versionnement associé à une politique de rétention avec object lock, qui obtient le même résultat par un mécanisme différent.

La configuration SSH qui porte cela mérite d'être réglée avec exactitude, car c'est la ligne porteuse. Dans le authorized_keys de l'utilisateur de sauvegarde, préfixez la clé du client par une commande forcée et les restrictions que documente le manuel de sshd : command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict. Cette seule ligne signifie qu'une clé volée au client ne peut ni ouvrir de shell, ni rediriger de port, ni toucher au dépôt d'un autre hôte, ni supprimer quoi que ce soit. Donnez à chaque client sa propre clé et son propre chemin.

Ce qui soulève la question évidente : si le client ne peut jamais supprimer, qu'est-ce qui retire les anciens snapshots ? La purge se produit ailleurs, selon un calendrier, avec un identifiant que la machine protégée n'a jamais détenu. En pratique, cela signifie que l'hôte de sauvegarde purge ses propres dépôts depuis un cron local, ou qu'une troisième petite machine détient la clé privilégiée et applique la rétention chaque semaine. Borg présente ici une particularité connue — un dépôt append-only doit voir son compactage exécuté côté serveur plutôt que par le client — et traiter l'hôte de sauvegarde comme le propriétaire de la rétention résout cela proprement. Le principe se généralise : la machine qui écrit les sauvegardes ne devrait jamais être la machine capable de les détruire.

La rétention elle-même est une question de politique dont la réponse conventionnelle fonctionne : conserver les quelques dernières sauvegardes quotidiennes, quatre ou cinq hebdomadaires, et six à douze mensuelles. Les deux outils expriment cela de façon déclarative, si bien que vous énoncez la forme souhaitée et laissez l'outil décider quels snapshots la satisfont. Ce sont les mensuelles qui détectent la corruption lente, et ce sont aussi celles que l'on supprime en premier lorsque le dépôt grossit — ce qui est exactement à l'envers, puisqu'une mensuelle compressée et dédupliquée d'un jeu de données qui change à peine ne coûte presque rien.

Où va la seconde copie quand personne ne peut vous identifier

Le hors site porte une bonne partie de la charge dans la règle du 3-2-1, et chez un hébergeur no-KYC, cela signifie quelque chose de plus précis qu'« un autre bâtiment ». Cela signifie une copie dont la survie ne dépend ni de la même entreprise, ni du même compte, ni de la même relation de paiement, ni de la même juridiction que l'original. Deux serveurs sur un seul compte sont deux serveurs avec un seul destin, aussi éloignés que soient leurs centres de données : un compte fermé pour quelque raison que ce soit emporte les deux, et un acte juridique signifié à une entité atteint tout ce que cette entité détient. L'indépendance est une propriété de la relation, pas seulement de la géographie.

La version pratique de cela est plus simple qu'il n'y paraît, car le même panneau propose déjà quatre juridictions. Une instance de production aux Pays-Bas dont le dépôt est poussé vers une offre Starter en Islande coûte $8.50 par mois et place votre récupération hors d'atteinte de toute procédure nationale unique — et comme les juridictions diffèrent dans ce à quoi elles résistent réellement, cet appariement mérite un instant de réflexion plutôt qu'un tirage à pile ou face. Puisque le dépôt est chiffré avant de quitter la source, l'hôte de sauvegarde n'est par conception pas digne de confiance : ce que vous achetez avec ce second emplacement, ce sont la disponibilité et la distance juridique, pas la confidentialité. La confidentialité, vous l'avez déjà.

Pour une troisième copie réellement indépendante, l'architecture la plus solide inverse le sens de la connexion. Au lieu que le serveur pousse vers une cible pour laquelle il détient des identifiants, une machine que vous contrôlez — un boîtier à la maison, un NAS, un ordinateur portable qui se réveille selon un calendrier — tire les données depuis le serveur. La machine de production ne détient alors aucun identifiant vers quelque destination de sauvegarde que ce soit, ce qui rend le scénario de compromission de la section précédente structurellement impossible plutôt que simplement atténué. Cela vous coûte une machine qui doit être joignable ou éveillée selon un calendrier, ce qui explique pourquoi elle complète une copie hors site poussée plutôt que de la remplacer.

Deux contraintes propres à ce type d'hébergement méritent d'être énoncées sans fard. Il n'existe aucune récupération de compte : aucune pièce d'identité à présenter, aucun numéro de téléphone pour recevoir un code, aucun représentant capable de confirmer que vous êtes bien vous. C'est exactement la propriété que vous payez à l'inscription, et elle s'applique symétriquement — ce qui rend la phrase de passe et le runbook véritablement porteurs, d'une manière qu'ils ne sont tout simplement pas chez un hébergeur grand public. Et si la cible de sauvegarde doit être payée, elle doit l'être elle aussi de façon anonyme, sans quoi la seconde copie réintroduit discrètement le lien d'identité que la première était censée éviter. Payer les deux machines depuis le même portefeuille crypto ne pose aucun problème ; payer la sauvegarde par carte est une décision, pas un oubli.

L'exercice, et comment découvrir qu'il ne fonctionne plus

Les tâches de sauvegarde échouent rarement de façon spectaculaire. Elles échouent par degrés : un motif d'exclusion élargi lors d'un nettoyage, un identifiant renouvelé d'un seul côté, un disque qui se remplit sur la cible, une entrée cron perdue lors d'une mise à niveau de distribution. Dans chacun de ces cas, la machine continue de tourner, rien n'alerte, et le dépôt cesse discrètement de croître. La conception qui détecte cela n'est pas « alerter en cas d'échec » — une tâche qui ne s'exécute plus ne peut pas signaler son propre échec — mais alerter en l'absence de succès. Faites en sorte que chaque exécution réussie envoie un ping à un point de terminaison dead man's switch, et que ce point de terminaison hurle lorsque le ping n'arrive pas à temps. Cela représente dix minutes de configuration, et c'est la différence entre s'en apercevoir en un jour et s'en apercevoir lors d'une restauration.

La vérification de l'intégrité en est la seconde moitié. Les deux outils peuvent vérifier que les métadonnées du dépôt sont cohérentes, et plus utilement encore que les blocs stockés se déchiffrent réellement et correspondent à leurs empreintes. Tout relire coûte cher en bande passante, si bien que les deux proposent une forme partielle — restic vérifie un pourcentage des données à chaque exécution, borg vérifie les données à la demande — et une cadence raisonnable consiste en une vérification complète des métadonnées chaque semaine et une vérification partielle des données chaque mois, dimensionnée pour qu'un passage complet se produise sur un trimestre. Le stockage se dégrade, et l'intérêt de la vérification est de le découvrir tant que vous disposez encore d'une autre copie.

Rien de tout cela ne prouve que vous pouvez restaurer. Cette preuve n'a qu'une seule source, qui est la restauration elle-même. Déployez une nouvelle instance — la plus petite offre coûte $8.50 et vous la détruirez dans l'heure — restaurez le dépôt dedans, puis faites la partie que les gens sautent : démarrez l'application et regardez les données réelles. Connectez-vous. Ouvrez un document du mois dernier. Envoyez un message de test via le serveur de mail. Interrogez une table qui devrait contenir les lignes d'hier. L'existence des fichiers n'est pas le test ; c'est le fonctionnement du service au-dessus qui l'est. Faites cela la première fois que vous mettez en place la sauvegarde, puis à un intervalle calendaire que vous respectez réellement, car l'exercice valide également le runbook, et le runbook se dégrade plus vite que les données.

Le runbook mérite son propre paragraphe, car c'est l'élément le moins coûteux ici et le plus souvent absent. Notez, dans l'ordre : où se trouve le dépôt et comment y accéder, où est conservée la phrase de passe, comment provisionner une machine de remplacement, quels paquets et quelles versions installer, quoi restaurer et dans quel ordre, quels enregistrements DNS modifier, et comment confirmer que cela a fonctionné. Conservez-le en dehors de la machine qu'il décrit — dans le dépôt lui-même, dans un gestionnaire de mots de passe, sur papier — et supposez que la personne qui le lit est fatiguée, travaille à une heure indue, et n'est peut-être pas vous. Cette dernière hypothèse est ce qui transforme un ensemble de notes en quelque chose qu'un collègue ou un membre de la famille peut exécuter.

Mis bout à bout, l'ensemble du dispositif est banal, et c'est précisément sa vertu : les snapshots horaires que votre offre inclut déjà pour les accidents des derniers jours, un dépôt chiffré poussé chaque nuit vers une seconde juridiction où il ne peut pas être supprimé, une phrase de passe quelque part que le serveur n'a jamais vue, un ping qui se plaint lorsque la tâche devient silencieuse, et une répétition inscrite au calendrier. Rien sur cette liste n'est difficile, la majeure partie tient en un après-midi, et le tout coûte par mois moins cher que le café que vous achèteriez en reconstruisant tout depuis rien. Si vous mettez cela en place maintenant, la seconde machine prend environ une minute à provisionner — commencez par la restauration que vous n'avez jamais testée, car c'est la seule partie de tout cela qui vous dit la vérité.