28 votes

Cliffhanger: les sauvegardes sont bonnes... ici... non?

À mon travail, les sauvegardes ont une priorité étonnamment basse. La stratégie de sauvegarde a été mise en place il y a un moment, et depuis lors, on suppose simplement que les sauvegardes sont bonnes. Si vous demandez aux administrateurs système, ils diront que tout est sauvegardé.

Mais alors, quand vous demandez une sauvegarde SPÉCIFIQUE, la moitié du temps elles ne sont pas là :

  • Le disque était plein
  • La bande a échoué
  • Il semble que quelqu'un ait désactivé le travail de sauvegarde
  • La connexion réseau était en panne
  • Nous avons commandé ce disque il y a des années, mais les finances n'ont pas approuvé le bon de commande
  • Les fichiers sont corrompus
  • Le fichier contient une base de données incorrecte
  • Seules les sauvegardes du journal des transactions (inutiles sans une sauvegarde complète).

Il y a quelques semaines, le désastre s'est rapproché alors qu'un des serveurs a perdu un trop grand nombre de disques RAID. Heureusement, un disque a bien voulu copier les données, si vous avez essayé plusieurs fois.

Mais même après ce quasi-désastre, je n'arrive pas à convaincre les administrateurs système d'améliorer la situation. Alors je me demande, avez-vous des conseils pour ouvrir les yeux des gens ? Il me semble que nous marchons sur le bord d'une falaise.

3voto

John Rennie Points 7728

Je suis responsable d'environ 200 serveurs répartis dans le nord-ouest du Royaume-Uni, et c'est évidemment beaucoup trop pour les vérifier manuellement.

Je configure la sauvegarde de sorte qu'à la fin, elle exécute un script (VBScript) qui parcourt le journal de sauvegarde, détermine si la sauvegarde a fonctionné ou non et écrit un enregistrement dans une base de données centrale avec le résultat de la sauvegarde. Ensuite, au siège social, j'exécute un script qui interroge cette base de données et me présente une liste de sites où soit la sauvegarde a rapporté une erreur, soit il n'y a pas eu de rapport du site.

Le résultat final est que lorsque je m'assois à mon bureau, j'ai une liste de tous les sites où je dois vérifier la sauvegarde.

L'objectif de tout cela est que l'hypothèse par défaut est que la sauvegarde a échoué, et la sauvegarde est considérée comme ayant fonctionné uniquement si mon VBScript n'a détecté aucune erreur et a écrit cette conclusion dans ma base de données. Cela garantit que les échecs de sauvegarde ne passent pas inaperçus.

Certains des serveurs utilisent Backup Exec, d'autres NTBackup et certains se contentent de copier leurs fichiers vers un autre serveur à travers le réseau. Peu importe le type de sauvegarde effectuée par les serveurs car il est facile de modifier mon VBScript pour rechercher des erreurs. Mon script est en fait assez basique, il ouvre simplement le rapport de sauvegarde en tant que fichier texte et recherche des phrases comme "échec du montage", "bande pleine", "erreur CRC", etc. Je suis sûr qu'un programmeur professionnel ferait un meilleur travail. Cependant, tout le processus est simple et robuste, et il est proactif dans le sens où je vois le rapport d'échec de sauvegarde que je le veuille ou non, et je ne manquerais une erreur que si je décidais consciemment d'ignorer le rapport.

JR

PS 99% des échecs de sauvegarde sont dus au fait que les utilisateurs ont oublié de changer la bande de sauvegarde. Vous n'adorez pas les lusers :-)

2voto

Dave Cheney Points 18132

Une sauvegarde non testée n'est pas une sauvegarde du tout.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X