Comment tester une restauration ? RTO et RPO en pratique

Deux sigles qui décident de votre nuit

RPO, recovery point objective : combien de données pouvez-vous perdre au maximum ? Une sauvegarde nocturne donne un RPO de 24 heures : un sinistre à 16 h signifie refaire toute la journée de travail. Pour une comptabilité, c'est pénible ; pour une boutique en ligne, c'est hors de prix.

RTO, recovery time objective : combien de temps cela peut-il prendre avant que tout refonctionne ? Pas le moment où la sauvegarde est « téléchargée », mais celui où vos collaborateurs peuvent retravailler.

Ces deux chiffres figurent souvent dans un document de politique. Bien plus rarement, ils ont été mesurés. Et un RTO estimé est un pari.

Pourquoi les sauvegardes échouent en pratique au moment de restaurer

• La sauvegarde a tourné, mais le chemin était vide ou une base a été sautée.
• Le dépôt semblait sain sur le serveur source, mais est illisible sur une machine neuve parce que le cache local masquait tout.
• Le dump est là, mais personne n'a jamais essayé de le charger dans une version plus récente de la base.
• La clé se trouve sur le serveur qui vient d'être chiffré.
• Restaurer 600 Go sur une connexion avec frais de sortie et 100 Mbit prend trois jours, et coûte de l'argent que personne n'avait budgété.

Chacun de ces problèmes n'apparaît que lorsque vous essayez vraiment. C'est pour cela qu'on teste.

Quatre niveaux de test

Chaque test ne doit pas être complet. Zekura utilise quatre niveaux, chacun avec sa fréquence, et ce modèle fonctionne aussi sans Zekura :

Niveau	Quoi	Question à laquelle on répond	Fréquence
L1 Intégrité	relire chaque objet de l'instantané sur une machine séparée, avec cache vide, contrôler toutes les sommes de contrôle	Tout est-il là, et lisible à partir de zéro ?	après chaque sauvegarde
L2 Échantillon	restaurer un échantillon de fichiers et comparer par sha256 à l'original	Ce qui revient correspond-il à ce qui était là ?	quotidien
L3 Application	charger la base dans une instance jetable et recompter ; démarrer l'application ; exécuter un contrôle de santé	Est-ce que ça fonctionne, et pas seulement les octets sont-ils justes ?	hebdomadaire
L4 Démarrage	restaurer une VM complète et la démarrer jusqu'à ce que l'agent invité réponde, et chronométrer	Combien de temps faut-il réellement avant que ça tourne ?	mensuel

Le cache vide en L1 n'est pas un détail. Une restauration se fait toujours sur une machine qui ne connaît pas encore les données. Tester depuis la source ne prouve rien à ce sujet.

Comment mesurer réellement le RTO

Mesurez tout le parcours : du moment où vous décidez de restaurer à celui où l'application répond. Notez par système :

• la durée de la restauration (les octets par seconde en disent plus que vous ne pensez sur votre réseau et votre fournisseur de stockage) ;
• le temps de démarrer une base de données et de la contrôler ;
• le temps de rétablir les accès (DNS, certificats, mots de passe qui étaient dans la sauvegarde).

Zekura note la durée mesurée de chaque restauration et de chaque restauration d'essai et la place dans la chaîne de preuve. L'aperçu affiche toujours la dernière restauration prouvée avec son temps : « 9 secondes » ou « 11 minutes 42 secondes » est un fait qu'un auditeur peut vérifier, « environ une heure » non.

Comment réduire le RPO sans sauvegarde complète toutes les heures

Pour les bases de données existe la restauration à un instant donné (point-in-time recovery) : une sauvegarde de base hebdomadaire plus un flux continu de changements (le write-ahead log pour PostgreSQL, les sauvegardes de journaux pour SQL Server). L'intervalle auquel ce journal part est votre RPO : toutes les cinq minutes donne au plus cinq minutes de perte. Et vous pouvez revenir à n'importe quel instant, y compris 14 h 06, juste avant que quelqu'un ne vide la mauvaise table.

Des résultats de test qui comptent comme preuve

Un test qui reçoit un « ok » dans un tableur a peu de valeur pour un auditeur. Ce qui compte :

1. Qui ou quoi a fait le test, et sur quelle machine (pas le serveur source).
2. Quand, avec un horodatage qui ne peut pas avoir été ajusté après coup.
3. Ce qui a été contrôlé exactement : nombre d'objets, nombre de fichiers, comptages de lignes.
4. Le résultat, y compris les échecs. Un registre qui ne contient que des succès est suspect.
5. Le lien : chaque test renvoie à la sauvegarde à laquelle il s'appliquait.

Chez Zekura, chaque vérification entre signée dans la chaîne de preuve, avec les éléments de preuve joints. Les vérifications échouées aussi ; le registre ne cache rien.

Un plan de test pour une PME

• Quotidien, automatique : intégrité de chaque sauvegarde, échantillon de fichiers.
• Hebdomadaire, automatique : restaurer et contrôler entièrement une base et une application.
• Mensuel, automatique : démarrer une VM depuis la sauvegarde.
• Trimestriel, avec des humains : un exercice de restauration accompagné d'un scénario (rançongiciel, incendie, erreur d'un collaborateur), avec un compte rendu. Le SLA Business de Zekura inclut un tel exercice chaque trimestre.
• Annuel : tester la clé. Sans la clé, tout autre test est vain.

Questions fréquentes

Une restauration d'essai n'est-elle pas dangereuse pour la production ?

Seulement si vous restaurez par-dessus la production. Testez toujours vers une machine séparée ou une instance jetable. Zekura ne restaure jamais par-dessus l'original sauf si vous le demandez explicitement.

Tester coûte-t-il beaucoup de trafic de stockage ?

Chez les fournisseurs qui facturent le trafic sortant, oui, et c'est exactement pourquoi on y teste si peu. Choisissez un stockage sans frais de sortie ; c'est pour cela que Zekura utilise Cubixion.

Quel est un bon RTO pour une PME ?

Vous répondez par système avec vos équipes : que coûte une heure d'arrêt de la boutique, de la comptabilité, du mail ? Mesurez ensuite si vous l'atteignez. Souvent, le RTO réel s'avère être un multiple de l'estimation.