Est-ce qu’un backup existe vraiment si personne ne l’a jamais restauré? Le message Backup completed successfully confirme surtout qu’un logiciel a produit un média. Il ne prouve pas que les bonnes données étaient dedans, que la bande se lit ni que l’application peut repartir.

Avant de choisir l’outil, je veux deux nombres. Le RPO est la quantité de données qu’on accepte de perdre : avec une sauvegarde chaque nuit, il peut approcher 24 heures. Le RTO est le temps permis pour remettre le service en marche. Copier 500 Go depuis une bande lente peut respecter le RPO et manquer complètement le RTO.

Les types de copies changent la chaîne de restauration :

• une sauvegarde complète contient tout l’ensemble à un moment;
• une différentielle contient les changements depuis la dernière complète;
• une incrémentale contient les changements depuis la sauvegarde précédente;
• un journal SQL contient les transactions depuis le dernier point de journal.

Avec une complète dimanche et des incrémentales quotidiennes, restaurer jeudi demande la complète puis lundi, mardi, mercredi et jeudi dans l’ordre. Une différentielle de jeudi demanderait seulement dimanche et jeudi, mais grossit durant la semaine. Pour SQL Server en récupération complète, des backups de journal fréquents permettent de s’approcher d’une heure précise, à condition que la chaîne ne soit pas brisée.

Copier un fichier de base pendant qu’elle écrit n’est pas une sauvegarde cohérente. Une page peut provenir d’avant une transaction et une autre d’après. L’outil SQL coordonne données et journal pour produire une image restaurable. Pour une application composée d’une base et d’un répertoire de documents, il faut aussi savoir quel point commun relie les deux; restaurer la base de mardi avec les fichiers de vendredi peut créer des références impossibles.

Ma rotation pourrait ressembler à ceci :

chaque nuit      complète ou différentielle sur disque local de sauvegarde
chaque heure     journal SQL
chaque semaine   copie sur bande
chaque semaine   bande sortie du site
chaque mois      copie conservée selon la politique d'archives

Garder plusieurs versions protège contre une corruption remarquée tard, un fichier supprimé mardi ou un logiciel malveillant qui modifie la source. Sortir une copie du site protège contre le feu, l’eau, le vol et une panne électrique commune. La copie hors site doit être assez loin pour ne pas subir le même événement, avec un inventaire qui dit quel média se trouve où.

Le chiffrement protège une bande perdue, mais transforme la clé en dépendance critique. La clé ou le mot de passe doit être sauvegardé séparément et accessible pendant une urgence, même si le serveur d’authentification principal est en panne. Compresser et chiffrer ne remplacent pas un contrôle d’intégrité; je veux une empreinte ou la vérification native du média.

Un vrai exercice de restauration suit des étapes mesurées :

1. choisir une date et un système sans prévenir seulement la personne qui fait les backups;
2. localiser les médias et les clés à partir de la procédure;
3. restaurer dans un réseau isolé sur une autre machine;
4. appliquer complète, différentielle et journaux dans le bon ordre;
5. démarrer l’application avec ses fichiers et dépendances;
6. vérifier quelques transactions et permissions;
7. noter le temps, les étapes manquantes et le point de données obtenu;
8. corriger la procédure puis refaire le test.

L’isolement évite qu’une vieille copie envoie des courriels ou écrive dans un système de production. Il permet aussi de scanner les médias avant de reconnecter. Les comptes nécessaires à la restauration ne devraient pas dépendre uniquement du domaine qu’on essaie justement de restaurer.

Je préfère dix étapes courtes déjà exécutées à un énorme cartable jamais ouvert. Ma pratique sera de choisir un fichier au hasard chaque semaine et un service complet chaque trimestre, puis de comparer le résultat au RPO et au RTO annoncés. Le voyant vert dit qu’un job s’est terminé; seul un service restauré dit que la sauvegarde a fait sa job.