Sauvegardes de bases de données : testez la restauration.

Deux chiffres à fixer avec le métier

RPO (Recovery Point Objective) : la quantité de données que l'on accepte de perdre, exprimée en durée. Un RPO de 15 minutes impose des sauvegardes de journaux de transactions au moins toutes les 15 minutes.

RTO (Recovery Time Objective) : la durée maximale acceptable pour remettre le service en route. C'est ce chiffre que le test de restauration permet de vérifier, car on mesure le temps réel.

Ces objectifs se décident avec les équipes métier, pas seulement avec l'informatique : ils déterminent le coût de la solution.

La règle 3-2-1, et l'immuabilité

Trois copies des données, sur deux supports différents, dont une hors site. Aujourd'hui, on y ajoute une copie protégée contre la modification ou la suppression (stockage immuable ou copie déconnectée), car les attaques par rançongiciel visent aussi les sauvegardes accessibles depuis le réseau.

Ce qui fait échouer une restauration

• la sauvegarde est stockée sur le même volume ou le même serveur que la base ;
• il manque un maillon de la chaîne : sauvegarde complète, différentielle ou journaux ;
• la clé de chiffrement ou le certificat n'est pas conservé séparément ;
• la version du moteur ou de l'outil de restauration diffère de celle d'origine ;
• les comptes, droits, tâches planifiées et paramètres de l'instance n'étaient pas sauvegardés ;
• la durée réelle de restauration dépasse largement le RTO annoncé.

Comment tester concrètement

Le principe est identique pour tous les moteurs : restaurer sur un environnement isolé, vérifier que la base est cohérente et que l'application fonctionne, puis chronométrer.

• SQL Server : restauration complète sur un serveur de test, puis vérification d'intégrité (DBCC CHECKDB). Une simple vérification du fichier de sauvegarde ne suffit pas à prouver que la base est saine.
• Oracle : restauration avec RMAN sur un serveur de test, et validation des sauvegardes avec les commandes de validation de RMAN.
• PostgreSQL : restauration d'une sauvegarde physique ou d'un dump, rejeu des journaux (WAL) jusqu'à un instant donné, et test de la restauration à un point dans le temps.
• MySQL et MariaDB : restauration d'une sauvegarde physique ou logique, puis rejeu des journaux binaires jusqu'à l'instant voulu.

Dans les quatre cas, on vérifie ensuite quelques données connues, le nombre d'enregistrements des tables clés, et surtout que l'application métier démarre sur la base restaurée.

Quelle fréquence ?

• un test de restauration automatisé et régulier sur les bases importantes, au moins une fois par mois ;
• un exercice complet, avec les équipes, une fois par an : panne simulée, restauration, redémarrage des applications ;
• un nouveau test à chaque changement important : nouvelle version, migration, changement de stockage.

Chaque test doit produire une trace : date, durée, résultat, difficultés rencontrées. Cette trace nourrit une procédure écrite (runbook) que n'importe quel administrateur peut suivre, y compris en pleine nuit.