Comment tester une restauration, pas seulement un backup

Toutes les consoles de backup du monde peuvent vous montrer une colonne de coches vertes. Aucune ne peut vous dire si votre entreprise tournera de nouveau avant midi après une mauvaise nuit. Seule une restauration peut vous le dire, et la seule restauration à laquelle vous pouvez faire confiance est celle que vous avez déjà faite. Voici comment tester les restaurations pour que le résultat signifie quelque chose.

Ce qu'un job vert prouve réellement

Un job de backup réussi prouve qu'un job a tourné, a lu des données et les a écrites quelque part sans une erreur que le logiciel a reconnue. Il ne prouve pas que les données sont complètes, que la machine qui vous importe était dans le job, que la copie peut être relue, ni que l'application démarrera à partir d'elle.

Il y a trois choses à tester : la couverture (tout ce qui devrait être sauvegardé l'est-il réellement), la récupérabilité (la copie peut-elle être lue et démarrée) et le temps (combien de temps prend réellement une reprise). La plupart des organisations ne testent aucune des trois de façon régulière.

Étape un : vérifiez la couverture face à la réalité

Les jobs de backup sont définis à un instant donné. L'infrastructure continue de changer. Une nouvelle machine virtuelle créée à côté des anciennes, une base de données déplacée sur un nouvel hôte, un serveur renommé : chacun peut sortir de tous les jobs sans qu'une seule erreur soit levée.

Comparez donc la liste de ce qui existe à la liste de ce qui est protégé. Exportez l'inventaire depuis l'endroit qui sait ce qui tourne, l'hyperviseur, la plateforme cloud ou le DCIM, et la liste des objets protégés depuis le système de backup, puis comparez-les :

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

La première liste est la dangereuse. La seconde est du désordre qui la cache. Chaque entrée de la première liste exige une décision : l'ajouter à un job, ou écrire noir sur blanc qu'elle n'a délibérément pas de backup, et pourquoi.

Étape deux : restaurez à plus d'un niveau

La récupérabilité a des niveaux, et chaque niveau attrape des problèmes que celui du dessous manque.

Niveau fichier. Restaurez un échantillon de fichiers vers un emplacement alternatif et comparez-les par checksums à la source ou à une copie connue bonne. Cela attrape les supports illisibles et les chaînes de backups incrémentaux cassées.

Niveau machine. Démarrez un serveur ou une machine virtuelle entière depuis le backup. Cela attrape les volumes de boot manquants, les pilotes et le disque discrètement exclu du job. La plupart des plateformes de backup d'entreprise, Veeam parmi elles, peuvent démarrer une machine directement depuis le dépôt de backup dans un lab isolé exactement pour cela.

Niveau application. Prouvez que l'application fonctionne à partir de la copie restaurée. Pour une base de données, cela signifie qu'elle démarre, passe son propre contrôle de cohérence, et contient les enregistrements les plus récents que vous attendez pour l'instant du backup :

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Pour les outils de backup au niveau fichier, il existe des contrôles d'intégrité qui relisent les données stockées, par exemple borg check --verify-data sur un dépôt Borg.

Étape trois : restaurez dans un lab, pas en production

Une machine restaurée est une copie de la production, avec les adresses, les identifiants, les tâches planifiées et le courrier sortant de la production. Démarrez-la sur le vrai réseau et elle peut répondre à des requêtes destinées au serveur en service, envoyer aux clients une série d'e-mails en double, ou exécuter une seconde fois le job de facturation de la veille.

Les tests de restauration appartiennent donc à un réseau isolé sans route vers la production et sans route vers l'internet. Avant de démarrer une application dans ce lab, désactivez le planificateur et le courrier sortant sur la copie restaurée. Faites-en une étape écrite du test, pour que personne n'ait à s'en souvenir.

Étape quatre : chronométrez

Le temps de reprise sur le papier est une estimation. Celui qui compte est mesuré : du moment où quelqu'un décide de restaurer, en passant par la recherche du bon point de restauration, le déplacement des données, le démarrage des services et la vérification de l'application, jusqu'à la première transaction réelle réussie. Les grandes restaurations sont souvent limitées par un débit que personne n'a mesuré, ou par une étape qu'une seule personne sait faire. Chronométrer toute la séquence trouve les deux.

Étape cinq : écrivez-le

Gardez une courte entrée pour chacune :

• La date, et qui l'a exécutée.
• Ce qui a été restauré, depuis quel point de restauration.
• Quel niveau a été testé : fichier, machine ou application.
• Le temps pris, de bout en bout.
• Tout ce qui a échoué, vous a surpris ou a exigé une connaissance qui n'est pas écrite.
• Ce qui a été changé en conséquence.

Le design en dessous compte aussi

Les tests prouvent que les backups existent et fonctionnent aujourd'hui. Le design décide s'ils existeront encore après une mauvaise journée. La règle qui compte le plus est que les backups sont tirés. Le système de backup entre dans la production et prend ce dont il a besoin. La production n'a aucune route réseau vers le système de backup et aucun identifiant pour lui. Un intrus qui possède un serveur de production ne peut alors pas atteindre les backups de ce même serveur pour les supprimer. L'accès append-only pour les outils au niveau fichier ajoute un second verrou, et l'historique du dépôt signifie qu'une copie d'avant le problème existe toujours.

Comment nous le faisons

Nos backups sont pull-only par conception et imposés sur les appliances firewall, seul le réseau de gestion pouvant atteindre les systèmes de backup et de reprise. Nous utilisons Veeam pour les machines virtuelles, les serveurs physiques et les serveurs SQL, et un hub de backup dédupliquant qui tire les données de fichiers et de bases Linux avec des clés restreintes, append-only. La couverture est vérifiée face à l'inventaire vivant, les plannings sont fixés d'après des durées d'exécution mesurées, et des restaurations complètes sont exécutées jusqu'à chaque semaine.

Si vous n'avez jamais chronométré une restauration complète de votre système le plus important, c'est par celui-là qu'il faut commencer, et nous serons heureux de vous aider à la planifier.

CTA

Parler à un ingénieur

Related

Sur le même sujet : Disaster recovery et réplicas entre sites · Réplication du stockage entre Athènes et Amsterdam · Services de fichiers NAS, NFS et SMB