Dossier Stockage (volet 7) : Planification de la reprise : quand quoi et comment

Cloud

Il convient tout d’abord de définir avec précision deux concepts importants :
le point de recouvrement et le temps de recouvrement.

Le point de recouvrement est le moment se situant juste avant le crash est ou il est encore possible de prendre une image des données (on parle aussi de cliché ou de snapshot, ce qui traduit bien l’idée d’une prise d’un instantané du système et des données utilisées à un instant t), cette image pouvant être ensuite remontée sur le système après sinistre afin de redémarrer l’activité.

En règle générale, la plupart des entreprises ne prennent en compte que le temps de recouvrement, c’est-à-dire le temps de redémarrage nécessaire pour relancer le système.

Bien souvent, on oublie de définir précisément les moyens mis en oeuvre pour réduire au minimum la taille de l’image (plus l’image est volumineuse, plus il faudra de temps pour la réinstaller sur le ou les serveurs concernés et plus longue sera l’incapacité de l’entreprise d’accéder à l’ensemble de ses applications métier).

En fonction de l’activité de l’entreprise et de certaines applications, le point de recouvrement et le temps de recouvrement varient grandement. Dans le cas d’un serveur de développement, par exemple, l’entreprise peut se permettre de redémarrer au bout d’une journée.

En revanche, dans le cadre d’un site d’e-commerce ou d’une banque, la contrainte se situe le niveau de la perte d’information (perte minimale) ainsi qu’à celui du délai de redémarrage (lequel doit s’avérer le plus bref possible). Ces deux moments doivent donc être définis dès le départ en fonction des besoins de l’entreprise.

Quelques conseils avant la mise en oeuvre d’un site de secours
Tout d’abord, lors de la conception de l’exploitation du site principal, il est largement préférable de choisir des acteurs majeurs du marché et de réduire au strict minimum le recours à des acteurs opérant sur certaines niches. Ensuite, il vaut mieux choisir des outils d’administration indépendant de toute plate-forme en s’orientant vers la solution unique et couvrant l’ensemble des plates-formes utilisées dans le cadre du site de production de l’entreprise. Cela facilite d’autant l’administration sur l’ensemble des sites (y compris sur le site de secours).

Enfin, au niveau des ressources humaines, il est nécessaire que l’entreprise est toujours à sa disposition suffisamment de personnes formées pour pallier toute absence du personnel dûment entraîné lors de la survenance d’un accident. D’où l’importance d’une formation large et de l’attribution en doublon de rôles et de fonctions devant être remplis lors de la survenance d’un désastre.

Soulignons encore que plus les données seront dupliquées à différents endroits, plus l’entreprise sera prête en cas de sinistre. La procédure met en oeuvre dans ce cadre et le plan de reprise d’activité. Celui-ci mixe procédures et ressources humaines affectées à des tâches précises.

Lorsqu’il est nécessaire, le site secondaire peut se répartir en trois catégories :

  • le site secondaire vide est une infrastructure informatique a minima permettant de réimplanter le ou les serveurs de l’entreprise;
  • le site partiel dispose d’une certaine infrastructure (alimentation électrique, onduleurs, batterie de disques) permettant déjà une exploitation plus une émise en production plus rapide que dans le premier cas ;
  • le site complet comprend l’ensemble des infrastructures présentes sur le site principal (matériels, logiciels, données répliquées depuis le site principal). Pour qu’un tel site soit parfaitement opérationnel, il est indispensable de lui affecter des ressources humaines qui l’exploitent en permanence et qui assureront son bon fonctionnement en cas de basculement vers ce site

Exemple type d’une architecture de stockage incluant un site de secours

Depuis peu, on a vu apparaître des logiciels permettant, outre une restauration des données d’un point de recouvrement très proche dans le temps, d’avoir une protection des données en continu. Autrement dit, ces softs se prétendent capables de fournir une image du système à quelques secondes (voire moins) du moment de la panne, leurs fonctions permettant notamment de déclencher automatiquement le basculement vers un site ou un serveur secondaire (dans le cas d’architectures de plus faible ampleur).

Dauphiné Libéré : de la sauvegarde au disaster recovery
Avec plus de 300 000 exemplaires imprimés en moyenne par jour et plus d’un million de lecteurs, le Dauphiné Libéré et le quotidien le plus lu dans la région Rhône-Alpes. Les données stratégiques du journal sont les données système des serveurs de production. Le moindre retard, dû à une défaillance système, peut entraîner l’arrêt de la production ayant pour effet la suppression d’une parution, soit une perte de 250 000 euros minimum.

Compte tenu de ces différentes contraintes le quotidien choisi d’installer le logiciel Time Navigator de la société Atempo. Grâce à ce progiciel, le quotidien a pu structurer la sauvegarde dans tous les services de l’entreprise et automatiser celle-ci. Comme le souligne Louis Lafranceschina, responsable projet de sauvegarde : “nous pouvons déclencher des sauvegardes non plus via le planificateur interne du logiciel, mais directement depuis des applications. De cette manière, en cas de sinistre, nous sommes capables de recréer un serveur à l’identique avec son catalogue du moment”.

Par exemple, lorsque le Dauphiné Libéré souhaitait sauvegarder la base de données de la facturation journalière, il faisait souvent face au problème de savoir quand la déclencher. S’il y avait des retards sur le serveur qui avait généré cette facturation, la sauvegarde pouvait partir trop tôt et donc ne pas être valable en termes de sécurité.

Raison pour laquelle le groupe de presses à désormais intégrer des ordres de sollicitation du logiciel de sauvegarde dans la chaîne qui a lancé la facturation. Dans ce cas, c’est la chaîne elle-même, à la fin de la génération des facturations, qui propose au serveur de sauvegarde d’enclencher la sauvegarde programmée, celle-ci étant reconnue directement au niveau du système d’information.

La sauvegarde par ailleurs n’est plus uniquement centralisée, elle est également sécurisée, afin de faire face aux différents sinistres potentiels. Pour ce faire, le quotidien dispose d’un second local hébergeant le serveur de sauvegarde. Celui-ci exploite un catalogue de sauvegarde disposant d’une base de connaissances sur l’identité de toute sauvegarde connue par le serveur.

Ce catalogue est sauvegardé ainsi que les données nécessaires à la reconstruction du serveur secondaire. De plus, il est dupliqué sur un autre serveur entièrement externalisé.


Lire la biographie de l´auteur  Masquer la biographie de l´auteur