Meilleures pratiques pour la vérification des sauvegardes?

C'est une situation courante, lorsque l'administrateur crée un système de sauvegarde automatique et l'oublie. Ce n'est qu'après qu'un système échoue aux notifications de l'administrateur, que le système de sauvegarde est tombé en panne avant ou que les sauvegardes ne peuvent pas être restaurées en raison d'une erreur et qu'il n'a pas de sauvegarde en cours à partir de laquelle ...

Exécutez des exercices d'incendie ... tous les deux mois, c'est une bonne idée de dire que le système XYZ est en panne ... puis effectuez les mouvements pour le remettre en ligne sur une nouvelle machine virtuelle, etc. des erreurs.

mode soapbox: ON

Je dirais que c'est aussi simple que des sauvegardes qui ne sont pas testées régulièrement ne valent rien.

Lors de mon travail précédent, nous avions pour politique de restaurer tous les systèmes (production, test, suivi du développement, etc.) tous les 6 mois.

C'était aussi le travail de l'administrateur le plus junior afin que la documentation soit à jour. Junior étant défini par la quantité de travail qu'il / elle avait à faire sur le système spécifique, parfois (assez souvent en fait), c'était le "chef de groupe" qui le faisait

Nous avions un matériel spécial dédié à cela (un Intel et un boîtier IBM / AIX) qui était de faible spécification pour tout sauf l'espace disque, car nous n'avions pas besoin d'exécuter quoi que ce soit de réel sur l'hôte restauré.

Beaucoup de travail les deux premiers tours, mais cela nous a amenés à rationaliser le processus de restauration, qui est la partie importante de la sauvegarde.

Étant donné que vous semblez faire référence au fait que l'administrateur ne remarque pas que le travail de sauvegarde "s'arrête", et pas tellement qu'une sauvegarde de travail ne fonctionne pas correctement, je suggère de créer une sorte de scripts de surveillance autour des sauvegardes.

Lors de la création d'une solution de sauvegarde maison, je ferais quelque chose comme ceci:

• Créez un script pour sauvegarder vos données.
• Effectuez une restauration de test pour vous assurer que le script fonctionne correctement.
• Dans le script, ou via un autre moyen, implémentez un moyen de suivre l'état des sauvegardes (succès, échec, exécuté, n'a pas été exécuté).
• Faire surveiller l'état de suivi (e-mail, base de données, quelque chose)

Une fois que tout cela est fait, ça devrait aller. Une autre chose à faire serait d'effectuer des restaurations de test régulières. Si vous avez du matériel supplémentaire à donner à la cause, c'est.

Là où je travaille, nous avons un site chaud, une fois par mois, nous choisissons au hasard un système ou une base de données et allons sur notre site chaud et effectuons un exercice de restauration de test sur du métal nu pour garantir la capacité de récupérer nos données.

Honnêtement, si vos données sont très importantes pour vous, il serait dans votre intérêt d'investir dans certains logiciels pour gérer vos sauvegardes pour vous. Il existe des centaines de produits pour cela, du simple et bon marché à la classe entreprise.

Si vous comptez sur un ensemble de scripts manuscrits exécutés dans la crontab pour les sauvegardes de votre entreprise, tôt ou tard, vous serez probablement brûlé.

Nous avons des versions de référence de 60% de nos systèmes de production, nous les utilisons pour les tests finaux des modifications, nous restaurons les sauvegardes de production sur ces systèmes - il teste la sauvegarde et s'assure que les deux environnements sont en phase les uns avec les autres .

Une approche consiste à créer un script pour une tâche de «récupération» à exécuter périodiquement, par exemple une qui récupère un fichier texte spécifique à partir de la sauvegarde la plus récente et vous envoie par e-mail son contenu. Si c'est possible, cela devrait - au moins parfois - être fait en utilisant une boîte différente de celle qui a créé ou sauvegardé les données, juste pour vous assurer que cela fonctionnera si vous en avez besoin. L'avantage est que vous pouvez être sûr que vos mécanismes de chiffrement / déchiffrement, de compression et de stockage fonctionnent tous.

Cela est un peu plus complexe pour les sauvegardes spécialisées telles que les serveurs de messagerie et de base de données, bien qu'il soit certainement possible d'effectuer une sorte de récupération à petite échelle à partir d'une petite base de données ou d'une sauvegarde de boîte aux lettres au niveau de la brique et de vérifier le contenu.

Cette approche ne doit pas non plus remplacer une restauration complète périodique pour garantir que vous pouvez récupérer des données en cas d'urgence - elle vous permet simplement d'être un peu plus confiant quant à l'intégrité de votre travail de sauvegarde au jour le jour.

Lors de la restauration de test, je ne me sens pas vraiment à l'aise au point "cela a l'air bien, les fichiers sont restaurés, il semble qu'aucun fichier ne manque, même les tailles correspondent", ou au point "cela a l'air bien, j'ai commencé mon application. .. ne plante pas, affiche des données correctes ".

Je veux restaurer le serveur / cluster à partir de zéro, puis l'utiliser réellement pour la production . Pas pour une minute, pas pour une heure, mais de façon permanente . Si vous prétendez que votre restauration a réussi, il n'y a absolument aucune raison de ne pas démarrer une production. Ce n'est pas un système "sale", qu'il faut oublier. C'est le système auquel vous serez confronté après une véritable catastrophe. Donc, si ça passe la scène "ça a l'air sympa", vivez avec. Sauvegardez-le la nuit prochaine. Oubliez l'original. Vous avez probablement vous découvrirez quelques problèmes en utilisant cette approche, et vous serez forcé de corriger tous . La prochaine restauration du même système a de bonnes chances de réussir à 100%.

Cela inclut votre logiciel de sauvegarde et votre serveur. Oui, vous devez également les restaurer.

Vous n'avez pas de budget pour acheter du matériel dédié à la restauration?

• Faites valoir que vous avez absolument besoin d'un budget. À chaque occasion, rappelez aux décideurs qu'un test de restauration valide et complet ne s'est pas encore produit. (Et oui, rassemblez les preuves pour couvrir votre cul. Monde difficile.)
• Dans la plupart des organisations, il est parfois nécessaire de migrer un système vers un autre matériel, alors profitez-en. Choisissez toujours la méthode de «restauration à partir d'une sauvegarde» pour la migration, en prétendant que vous venez de perdre le matériel d'origine. Oui, cela signifie plus de temps d'arrêt, désolé. Au moins, vous aurez l'assurance que votre sauvegarde est utile.
• Pas de migration? Vous pouvez peut-être emprunter du matériel pendant deux semaines et effectuer deux tests de restauration (restaurer le matériel emprunté, attendre plus d'une semaine, restaurer de l'emprunté à l'original, vivre avec). Habituellement, si un nouveau matériel est acheté pour un nouveau système et que vous organisez les choses correctement, vous pouvez facilement l'emprunter - en proposant de le tester de manière exhaustive pendant deux semaines. Si le nouveau matériel n'est pas 100% identique à l'ancien, cela rendra votre test encore meilleur. Comment savoir si vous obtenez du matériel identique en cas de catastrophe réelle?
• Y a-t-il actuellement un nouveau système que vous implémentez? Pouvez-vous tester la restauration maintenant? N'utilisez pas de matériel supplémentaire, remplacez simplement le nouveau système car vous avez de nouvelles connaissances pour le réimplémenter rapidement. Cela fonctionne s'il n'a pas encore de données significatives. Encore une fois, passez en production sur la version restaurée, pas sur la version fraîchement réinstallée.

1. Exercices d'incendie.
2. Une politique de test de toutes les sauvegardes tous les 6 mois est une très bonne idée
3. En ce qui concerne les tests, vous devez examiner chaque application ou système que vous sauvegardez. Idéalement, ce qui constitue une sauvegarde «réussie» ou «récupérable» doit être répertorié dans la description du service ou SOP (documentation opérationnelle) pour votre sauvegarde, ainsi que d'autres détails tels que le temps de rétention, bladibla.

Vous constaterez probablement que certains types de sauvegarde peuvent être facilement testés par des scripts de restauration (tels que les bases de données) tandis que d'autres nécessitent une entrée manuelle (restauration Active Directory). Automatisez autant que vous le pouvez, assurez-vous qu'une sorte de rapport est en place et assurez-vous que "quelqu'un" effectue également les tests manuels à intervalles réguliers. Un environnement isolé (copie réduite de prod) facilitera les tests de restauration.

Bien que nous ne testions pas les sauvegardes, nous avons le composant de vérification et de rapport de sauvegarde centralisé dans le système que nous avons développé BackupRadar.com. N'hésitez pas à le vérifier pour voir si cela aide avec ce composant. Il joint une copie des e-mails de réussite / d'échec à la politique de sauvegarde et il joindra également des captures d'écran si votre logiciel de sauvegarde est également capable de les envoyer.

Merci, Patrick

Assurez-vous que l'activité de sauvegarde est enregistrée, puis écrivez quelque chose (en perl bien sûr) qui analyse ces journaux à la recherche d'échecs, les distille et les envoie sous forme d'e-mail quotidien.