Publicité en cours de chargement...
Sauver la sauvegarde, à l’usage des DSI
Bref, comme le disait l’un de mes formateurs à qui je brandissais une disquette quand il me demandait si j’avais bien fait les sauvegardes : non, ça, c’est un bout de plastique, ce n’est pas une sauvegarde ; si tu arrives à la restaurer, alors c’est une sauvegarde. J’ai toujours été étonné de la légèreté avec laquelle est traité le sujet de la sauvegarde, d’autant que c’est certainement l’un des motifs qui ont dû valoir à pas mal de DSI malchanceux de passer au bureau du personnel pour aller chercher leur solde de tout compte. Mais en même temps le sujet est sacrément plus compliqué qu’il n’y paraît.
Le problème de fond provient de la déconnexion entre la vision du technicien ou de l’ingénieur informatique et celle de l’utilisateur : le premier copie des 0 et des 1 sur un support (bande magnétique, support optique, flash, disque dur, etc.) et rendra ces 0 et ces 1 quand on le lui demandera, alors que le second a besoin de revenir « un peu en arrière dans le temps » en cas d’effacement accidentel de données et s’attend à retrouver un environnement de travail opérationnel, au delta près de la perte de données de quelques heures ou quelques jours. Aussi ballot qu’il en paraisse – outre la question de la fiabilité du support physique, ceux qui en ont bavé avec les bandes magnétiques coincées dans un lecteur savent de quoi je parle –, la plupart des « incidents » de sauvegarde proviennent du fait que l’on n’a tout simplement pas sauvegardé ce qu’il fallait. Il manque un fichier, un répertoire, un tablespace ou que sais-je, et lorsque l’on s’en aperçoit, c’est justement le jour où l’on a besoin de restaurer, et on vit alors un grand moment de solitude – j’ai testé pour vous.
Pour sortir de cette situation kafkaïenne, il faut – selon votre humble serviteur – raisonner en classe de services. La sauvegarde est un service que la DSI rend à ses utilisateurs (ou, dans les grosses DSI, que le secteur Infrastructure rend au secteur Applicatif/MOA), et pour tout service il existe des conditions d’entrée et une limite d’usage. Une approche possible est la suivante :
Premier point : les progiciels se divisent en deux catégories, ceux qui sont critiques et ceux qui ne le sont pas.Deuxième point : il est nécessaire de définir des niveaux de prestation, qui sont cumulatifs. Par exemple :
Niveau 1 : la DSI sauvegarde des 0 et des 1, et assure qu’elle est capable de les restaurer.
Niveau 2 : en plus, la DSI garantit que les 0 et les 1 sauvegardés permettent de remonter un service applicatif (un processus DB, un batch, etc.). À ce stade, la DSI ne garantit pas que l’application refonctionne.
Niveau 3 : en plus, la DSI est capable de garantir que l’application refonctionne, au sens où l’on est capable d’ouvrir un écran, de naviguer dans les données, etc. Mais, à ce stade, l’application en question fonctionne en mode « standalone », c’est-à-dire sans aucune interopérabilité avec le reste du SI.
Niveau 4 : en plus, la DSI garantit que l’interopérabilité est fonctionnelle, au sens où l’application en question est en phase avec l’état des autres applications connexes au sein du SI.
Troisième point : la DSI doit effectuer des tests de restauration, qui ne sont pas les mêmes selon que les applications sont critiques ou pas.
Dernier point : conformément à Itil, l’engagement de service n’est jamais atteint à 100 %, mais à 80 %.
Ce découpage peut donner l’engagement suivant (c’est un exemple) :
Pour les serveurs de fichiers, le service garanti par la DSI est de niveau 1 et aucun test n’est réalisé (on considère que les restaurations régulières demandées par les utilisateurs tiennent lieu de test).
Pour les applications non critiques, le service garanti par la DSI est de niveau 2 et le test de restauration n’est effectué qu’une seule fois, à la première mise en production de l’application.
Pour les applications critiques hors DPI, laboratoires et Imagerie, le service garanti par la DSI est de niveau 3 et les tests de restauration sont effectués à chaque changement majeur.
Pour le DPI, les laboratoires et l’imagerie, le service garanti est de niveau 4 et les tests sont les mêmes que pour les autres applications critiques.
Dernières remarques : d’une part, je n’ai jamais vu aucune DSI (tout au moins dans le monde de la santé) capable de garantir le niveau 4. D’autre part, ne pas formaliser le niveau de service, et surtout ne pas le communiquer ni l’afficher, est une excellente méthode pour un DSI de raccourcir le délai qui le sépare du jour où il ira chercher son solde de tout compte.
À vos marques…
Avez-vous apprécié ce contenu ?
A lire également.

Dedalus France : une nouvelle étape dans la trajectoire de transformation
24 juin 2025 - 07:50,
Actualité
- DSIHDedalus France annonce le départ de Frédéric Vaillant, Directeur Général Délégué, au 30 juin 2025, après plus de 25 ans d’engagement. Fondateur de Medasys, acteur central des grandes étapes de structuration de l’entreprise, il a contribué à façonner Dedalus France comme acteur majeur du numérique en...

HLTH 2025, un Salon sous le signe de l’innovation distribuée
23 juin 2025 - 21:18,
Actualité
- DSIH, Mehdi LebranchuHLTH Europe 2025, qui s’est tenu cette année à Amsterdam, a offert un panorama dense et incarné de l’écosystème européen de la santé numérique. Le Salon a rassemblé géants technologiques, institutions publiques, start-up prometteuses et hôpitaux à la recherche de nouveaux modèles de collaboration. U...

Cour de cassation versus RGPD : 2-0. Et ce n’est pas une bonne nouvelle !
23 juin 2025 - 18:14,
Tribune
-Ça fait deux fois.

Approche hétérodoxe du concept de risque résiduel
02 juin 2025 - 22:42,
Tribune
-Vous voulez être le bon élève de l’auditeur 27001 qui vient constater, de visu, comment vous mettez en œuvre un SMSI. Le bon élève, avec les félicitations, le bisou sur le front et le petit papier qui va bien.