Sauvegardes : durée réelle d'un incident

Il ne suffit pas de faire des sauvegardes pour se sentir en sécurité. Outre que j'ai trop vu de serveurs mal voire pas sauvegardés du tout, j'en ai vu aussi où la capacité de reprise du travail normal suite à un plantage était douteuse.

Lors d’un incident, le stress est particulièrement important. La perte de temps et les erreurs qui en découlent peuvent être pires que l’incident lui-même. D’où l’importance de savoir restaurer une base dans la sérénité, donc de réaliser la manipulation de temps en temps.

Mais même en situation optimum :

• L'incident est repéré tout de suite.
• Les responsables peuvent facilement décider de restaurer la base affectée.
• Il n'y a pas de manip de matériel à changer.
• Les sauvegardes sont gentiment planifiées, y-compris le journal de transaction.
• Le DBA sait faire une restauration en sifflotant.
• Les fichiers sont en ligne...

... le temps incompressible d'interruption de productivité n'est pas négligeable.

A noter qu'on a ici affaire à un bug gentil, il est même plutôt coopératif. Ce n'est pas toujours le cas !

Le diagramme ci-dessous exprime l'enchainement des événements dans un cas favorable.



Malgré la bonne volonté de tous, le temps d'interruption est de cinq heures.

Or on a très vite un dérapage si un quelconque des intervenants n'accomplit pas sa tâche dans le temps minimum théorique imparti. Autant dire que le dérapage est inéluctable.

Ce qui se traduit par une perte sèche d'activité = Nombre employés (ou clients !) * Durée d'interruption.

Conclusion : Sachez mettre en place un mécanisme d'intervention d'urgence. La sérénité qui en découle n'a pas de prix.