Une sauvegarde jamais restaurée n’en est pas une

Tout le monde est d’accord avec le titre. Presque aucun tableau de bord ne le reflète.

La raison n’est pas la paresse. C’est que trois éléments de preuve réellement différents arrivent par le même tuyau, sont rangés dans des colonnes voisines, et finissent affichés sous la forme d’une seule coche verte. Une fois qu’ils ne font plus qu’une coche, l’affirmation la plus forte du groupe emprunte silencieusement la crédibilité de la moins chère, et un client lit « protégé » là où ce qui s’est réellement produit est qu’une tâche s’est terminée avec le code zéro.

Nous avons consacré une session à séparer ces trois preuves dans notre propre schéma, et une deuxième à mesurer un vrai Proxmox Backup Server pour découvrir lesquelles il peut effectivement nous donner. Voici où nous avons abouti.

Trois preuves, et elles ne sont pas interchangeables

La première est la moins chère et celle que tout produit affiche. Elle vaut exactement ce qu’elle dit : un processus s’est terminé. Les garanties de chaque mode vzdump portent sur ce que ce processus pouvait et ne pouvait pas promettre quant à l’état de l’invité, et aucune de ces garanties ne survit ensuite au contact d’un magasin de blocs corrompu.

La deuxième est une vraie preuve et elle est facile à sur-interpréter. Nous y revenons plus bas.

La troisième est la seule qui réponde à la question que pose réellement un client, et c’est la seule qui exige de construire quelque chose plutôt que de lire quelque chose. Cette asymétrie explique pourquoi elle manque d’habitude.

Ce qu’une vérification verte affirme réellement

Proxmox Backup Server peut vérifier un instantané : il relit les blocs et les contrôle contre le manifeste. Quand cela a eu lieu, la liste des instantanés porte un objet verification contenant un état.

C’est une chose réellement utile à savoir, et c’est plus étroit qu’il n’y paraît. Cela dit que les octets sur ce dépôt de données sont les octets qui ont été écrits. Cela ne dit pas que la machine démarrera. Cela ne dit pas que l’application à l’intérieur se lancera. Cela ne dit pas que la base de données était dans un état cohérent au moment de l’instantané. Et si la sauvegarde est chiffrée côté client, cela ne dit pas que quelqu’un possède encore la clé : un contrôle d’intégrité sur du texte chiffré passe très bien quand la clé a disparu.

L’état vit donc dans sa propre colonne de notre schéma, et il est documenté dans le code comme appartenant à la preuve numéro deux, à ne jamais mélanger avec « restauration prouvée ». La preuve numéro trois aura sa propre table le jour où quelqu’un la construira. Ajouter une quatrième valeur à une énumération existante aurait représenté une demi-journée de travail et une source permanente de confusion.

Un champ absent n’est pas un échec

Notre colonne a trois valeurs : ok, échec et inconnu. Celle du milieu n’est pas la plus intéressante.

Mesuré contre un Proxmox Backup Server 4.2 vivant portant de vrais instantanés : un instantané qui n’est jamais passé par une tâche de vérification n’a tout simplement pas de clé verification. Le champ est absent. C’est autre chose qu’une vérification qui a tourné et échoué, et les confondre vous coûte dans les deux sens. Mettez ok par défaut et chaque instantané non contrôlé devient un instantané contrôlé. Mettez échec par défaut et chaque instantané historique de votre base de données prend feu d’un coup. La troisième valeur existe pour dire la seule chose vraie : on ne sait rien.

Un stockage Proxmox ordinaire ne remplit jamais la colonne du tout, parce que sa liste de contenu ne porte aucune notion de vérification. Ce n’est pas un manque de notre intégration. C’est la réponse.

Un dernier détail honnête, parce que c’est le genre de détail qu’on arrondit. L’objet verification que nous avons mesuré porte un état et un identifiant de tâche, et aucun horodatage. Le moment « vérifié le » que nous enregistrons est donc le moment où nous avons vu cet état pour la première fois, ce qui est une autre question que « quand le stockage a-t-il vérifié ceci ». Il répond à « depuis quand le savons-nous ». Si une version future expose l’heure réelle, la colonne devra se mettre à la porter et le commentaire qui explique tout ceci devra être supprimé.

Vide doit vouloir dire vide

Voici la règle la plus tranchante de tout ce domaine, et elle n’a rien à voir avec la vérification.

Tout système qui liste périodiquement des points de restauration finit par déduire quelque chose de l’absence d’un instantané : il était là la semaine dernière, il n’y est plus, il a donc été élagué ou supprimé. Cette déduction est porteuse, et elle n’est valide que si une liste vide obtenue avec succès est réellement vide.

Nous avons donc mesuré ce qu’un serveur de sauvegarde répond réellement quand une liste tourne mal, parce que « un tableau vide » et « une erreur qui ressemble à un tableau vide » doivent pouvoir être distingués. Quatre cas, tous mesurés contre cette même instance 4.2 vivante :

• un espace de noms vide répond 200 avec un tableau vide ;
• un espace de noms qui n’existe pas répond 400 avec une erreur de type introuvable, pas une liste vide ;
• un dépôt de données que le jeton ne peut pas auditer répond 403 ;
• un jeton invalide répond 401.

Trois de ces quatre cas doivent devenir des erreurs spécifiques plutôt que des résultats. Si l’un d’eux est autorisé à atteindre votre logique de rapprochement sous la forme « la liste a réussi et il n’y a rien », alors une seule faute de frappe dans un nom d’espace de noms marque tout l’historique de sauvegarde d’un client comme disparu. Le mode de défaillance n’est pas une panne. C’est un écran qui cesse discrètement de mentionner que des sauvegardes existent.

C’est la même classe de piège que un hyperviseur qui répond 200 avant que le travail ait commencé : le code de réponse est correct, et il n’est pas la réponse à votre question.

Le jeton d’accès ne devrait rien pouvoir casser

La décision de sécurité la plus utile ici est aussi la plus ennuyeuse.

Le jeton qu’un client crée pour une cible de sauvegarde doit lire les instantanés et l’état du dépôt de données. Il n’a besoin ni de supprimer, ni d’oublier, ni d’élaguer, ni de vérifier. Ce sont des opérations distinctes qui appartiennent à celui qui possède le stockage, selon son propre calendrier, avec sa propre identité.

Nous avons construit l’intégration sans aucune commande d’écriture, ce qui rend l’affirmation structurelle plutôt qu’aspirationnelle, puis nous l’avons contrôlée depuis l’autre côté : avec un jeton ne portant que des droits d’audit, une suppression sur un instantané répond 403. C’est la forme à viser. Une intégration en lecture seule dont le jeton est capable d’élaguer est une intégration en lecture seule exactement jusqu’au jour où quelqu’un écrit une boucle avec une erreur de décalage dedans.

Il y a un corollaire que les hébergeurs manquent dans l’autre sens. Si votre plateforme supprime un serveur, la question de la rétention est une décision que le client doit prendre, pas une valeur par défaut que votre code choisit. Retirer la dernière copie restante des données de quelqu’un comme effet de bord du rangement d’une ligne est une chose qui est arrivée à de vraies entreprises.

Ce que doit être un test de restauration, si vous en construisez un

La preuve numéro trois est là où se trouve le travail, et il vaut la peine d’en écrire les contraintes avant d’écrire le code, car la plupart d’entre elles consistent à ne pas provoquer d’incident avec votre test.

Un test de restauration a besoin d’un endroit isolé où restaurer : un réseau sans route vers la production, des identifiants temporaires, des adresses temporaires, des adresses matérielles temporaires. Jamais l’adresse de production, et jamais l’adresse matérielle de production, car un doublon sur un réseau vivant est une panne que vous avez causée en vérifiant que vous saviez vous relever d’une panne. Il a besoin de quotas stricts, car la restauration de la plus grosse machine d’un parc dans un pool de test est un événement de capacité. Il a besoin d’une échéance et d’un nettoyage garanti, puisque la machine échouera parfois à démarrer et que quelque chose doit la retirer de toute façon. Et il a besoin de ne pas envoyer de notifications, car une alerte de supervision venant d’une copie de test qui se fait passer pour le vrai système réveillera quelqu’un.

Il a aussi besoin d’une politique d’achèvement explicite, et c’est là que l’ensemble mérite son nom. Démarré est un niveau. Joignable en est un autre. L’agent invité qui répond en est un autre. Les systèmes de fichiers montés en sont un autre. Une application qui répond à un contrôle de santé défini par le client est le niveau qui correspond à ce qu’un client entend par « récupérable ». Choisissez-en un, notez lequel vous avez choisi à côté du résultat, et ne laissez jamais un niveau inférieur être affiché avec l’étiquette d’un niveau supérieur.

Alors seulement un serveur a le droit d’afficher « restauration prouvée », et il devrait porter la date, le point de restauration exact, l’environnement où le test a tourné, les contrôles qui sont passés et la durée de conservation de la preuve. Rien de moins, sinon la formule est décorative.

Ce que nous écririons

1. 01Nommez les trois preuves séparément dans votre schéma, avant de les avoir toutes les trois. Les nôtres sont des colonnes distinctes et une table qui n’existe pas encore, ce qui se lit mieux qu’une seule colonne avec un commentaire d’excuse.
2. 02Stockez « inconnu » comme une vraie valeur. Toute valeur par défaut qui n’est pas « inconnu » est un mensonge sur au moins une de vos lignes.
3. 03Faites qu’une liste vide prouve qu’elle est vide, et transformez toute autre réponse en une erreur distincte avant qu’elle n’atteigne quoi que ce soit qui fasse du rapprochement.
4. 04Donnez à l’intégration un jeton qui ne peut pas supprimer, puis vérifiez de l’extérieur qu’il ne le peut pas.
5. 05Écrivez ce que « restaurer » devrait vouloir dire pour vous, à quel niveau d’achèvement, avant que quiconque ne place une coche verte à côté.

Notre propre état, dit simplement : les deux premières preuves sont construites et mesurées, et nous n’avons pas de test de restauration. La fonction de sauvegarde est derrière un drapeau et n’est pas à vendre. C’est la différence entre un projet et une affirmation, et c’est la même différence dont parle tout cet article.

L’intégration derrière ces mesures a été construite pour Provibr. La question de temporisation voisine, ce qui se passe quand une sauvegarde dure plus longtemps que le délai que vous lui avez donné, est dans un délai n’est pas un bouton d’arrêt ; le versant conteneur des sauvegardes Proxmox est dans VM ou conteneur sur Proxmox.