Cliffhanger: Les sauvegardes sont justes… ici… non?

Dans mon travail, les sauvegardes ont une priorité étonnamment faible. La stratégie de sauvegarde a été mise en œuvre il y a un certain temps, et depuis lors, on suppose simplement que les sauvegardes sont correctes. Si vous demandez aux administrateurs système, ils vous diront que tout est sauvegardé.

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

• Le disque est plein
• La bande a échoué
• On dirait que quelqu'un a désactivé le travail de sauvegarde
• La connexion réseau a eu un temps d'arrêt
• 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 mauvaise base de données
• Seules les sauvegardes du journal des transactions (inutiles sans une sauvegarde complète)

Il y a quelques semaines, la catastrophe s'est approchée de près, l'un des serveurs ayant perdu un trop de disques de raid. Heureusement, un disque était toujours assez aimable pour copier les données, si vous avez essayé plusieurs fois.

Mais même après cette quasi-catastrophe, je n'arrive pas à convaincre les administrateurs système d'améliorer la situation. Je me demande donc, des conseils pour ouvrir les yeux des gens? Il me semble que nous marchons le long d'une falaise.

Vous devez toujours faire réparer ces choses par le haut.

La stratégie de sauvegarde actuelle est-elle soutenue et comprise par la direction? Sinon, c'est inutile.

La direction générale doit connaître les problèmes et les risques impliqués (perdre les données financières que vous devez publier légalement pour survivre, ou les données des clients qui ont mis des années à être collectées?) Et peser cela pour décider des actions ou des décisions. laisser quelqu'un (comme vous) agir.

Si vous ne pouvez pas accéder à la gestion, essayez les contrôleurs d'entreprise ou d'autres postes financiers où la récupération des données et leur intégrité sont d'une grande importance pour les rapports de l'entreprise. Ils peuvent à leur tour "déclencher la tempête" si nécessaire ...

Où commencer? C'est un désastre qui attend de se produire. Une fonction de tâche principale de Sysadmins consiste à garantir que les données sont sauvegardées et récupérables. Tout le reste est secondaire. Non si c'est non mais c'est.

Voici quelques choses que vous pouvez faire:

1. Suivez les KPI pour les restaurations. Il devrait être possible de produire un rapport indiquant le nombre de demandes de restauration ayant abouti. Tout ce qui est inférieur à 100% doit faire l'objet d'une enquête approfondie. La direction aime les rapports et c'est une preuve tangible.

2. Il devrait y avoir des procédures documentées pour toutes les opérations de sauvegarde et de restauration, y compris tous les systèmes et leur stratégie de sauvegarde, les rotations de bandes, les plannings, les chemins d'escalade, les restaurations de test, etc. Demandez à les voir.

3. Parlez au gestionnaire des administrateurs système et exprimez vos préoccupations. Soyez armé de preuves que les restaurations ne fonctionnent pas. Si aucune joie ne va plus haut.

Sérieusement - lancez-vous. Des trucs comme ça peuvent détruire une entreprise.

Proposer (au minimum) des tests de reprise après sinistre annuels. Le travail requis pour exécuter le test avec succès devrait révéler des lacunes.

Là où je travaille, nous avons un service informatique vraiment bon, chaque année, ils se réunissent dans tous les bureaux en Europe et organisent un `` festival de restauration '' sur les serveurs loués dans un centre de données, simulant efficacement ce qui se passerait si le personnel venait travailler un jour et trouvait le le bureau avait brûlé pendant la nuit.

Impliquez le grand patron, rappelez-lui qu'en cas de catastrophe, il ne bénéficierait pas d'un bonus cette année-là (ou pire!) Et qu'il serait peut-être prudent d'organiser un exercice de récupération après sinistre similaire. Cela ne devrait pas prendre beaucoup de temps ou coûter cher - les administrateurs sont renvoyés avec leurs bandes de sauvegarde hors site et doivent leur proposer un environnement de bureau identique.

Ensuite, asseyez-vous et regardez l'informatique s'améliorer - une fois que la direction se rendra compte que les données de l'entreprise sont dangereusement proches d'être définitivement perdues, des étincelles voleront (des fusées qui seront stratégiquement placées dans lesdits administrateurs)

Il est facile de blâmer les administrateurs - mais Oskar a raison: ces choses sont conduites par le haut. Si la direction ne dépense pas l'argent pour faire des sauvegardes une priorité, les administrateurs système n'ont généralement pas de chance et font de leur mieux avec les ressources dont ils disposent.

La clé, si vous êtes l'un de ces administrateurs malchanceux - et j'ai été dans ce bateau pour certains engagements avec les clients - est que vous vous assuriez que la gestion est informée, à plusieurs reprises, et d'une manière confirmable sur papier, que c'est un risque pour l'entreprise.

Ma stratégie est de marteler constamment les problèmes. Si vous faites cela, parfois les problèmes seront résolus, mais c'est surtout pour que quiconque à qui je rapporte ne puisse pas se cacher derrière l'excuse "Je n'ai jamais été informé". En tant que consultant, je peux généralement aller mieux. Je peux demander à mes patrons de signaler à la direction plus que je ne le peux qu'il y a une vulnérabilité. Cela propage le blâme, ou au moins le concentre à un niveau supérieur à moi.

Dans le même temps, vous devez être inventif et travailler dur pour minimiser les risques avec toutes les ressources que le client peut fournir.

Alors que dans certains cas, les administrateurs peuvent être coupables, la direction est toujours responsable: soit de connaître le risque et de ne pas en faire assez pour l'atténuer, soit d'embaucher des personnes qui ne les alertent pas de ces risques.

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

Je configure la sauvegarde de sorte qu'à la fin, elle exécute un script (VBScript) qui examine 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ù la sauvegarde a signalé une erreur ou aucun 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.

Le point 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 écrit cette conclusion dans ma base de données. Cela garantit que les échecs de sauvegarde ne passent pas inaperçus.

Certains serveurs utilisent Backup Exec, certains NTBackup et certains copient simplement leurs fichiers sur un autre serveur du réseau. Peu importe le type de sauvegarde que font les serveurs, car il est facile de modifier mon VBScript pour vérifier les erreurs. Mon script est en fait assez basique, il ouvre simplement le rapport de sauvegarde sous forme de fichier texte et recherche des phrases comme «échec du montage», «bande pleine», «erreur CRC», etc., etc. Je suis sûr qu'un programmeur professionnel ferait un travail plus lisse. Cependant, le tout 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 de remarquer une erreur que si j'ai délibérément décidé 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. N'aimez-vous pas simplement les lusers :-)

Une sauvegarde qui n'est pas testée n'est absolument pas une sauvegarde.