> Tech > Reprise après sinistre

Reprise après sinistre

Tech - Par iTPro - Publié le 24 juin 2010
email

Supposons qu’une catastrophe frappe soudain. Les plans et techniques de la HD et de la COOP sont largement transparents aux yeux des utilisateurs finaux et d’une organisation en dehors de son site IT. Les catastrophes sévissent à une échelle bien plus large. Généralement, elles empêchent d’utiliser un centre informatique ou

d’y accéder.
Ce peut être à cause d’un événement local, comme un incendie, une inondation ou une panne électrique étendue dans l’immeuble du data center, ou d’une perturbation bien plus vaste qui met en quarantaine le site et tout son voisinage. A noter que les deux scénarios peuvent isoler le coeur des données. C’est pourquoi les plans de reprise après sinistre doivent supposer qu’il n’y aura « pas d’avertissement » et « pas d’accès ». Peut-être même pas d’accès à distance.

Les sinistres peuvent affecter plus qu’un simple service informatique ; ils peuvent bouleverser toute une organisation. C’est pourquoi le plan de reprise doit être à l’échelle de l’organisation, la restauration IT n’étant qu’une composante. Pour planifier la reprise après sinistre, il est important de considérer soigneusement trois domaines séparés :

• L’objectif de temps de reprise (RTO, Recovery Time Objective) est le laps de temps qui sépare une défaillance d’une reprise. Autrement dit, la période pendant laquelle il est tolérable d’être immobilisés.
• L’objectif point de reprise (RPO, Recovery Point Objective) est le point dans le temps jusqu’auquel on peut récupérer. Vu sous un autre angle, c’est la quantité de données que l’on peut se permettre de perdre. Par exemple, avec des sauvegardes quotidiennes, le RPO est la fin du jour précédent, et les données perdues représentent les transactions d’une journée.
• Le temps de reprise du réseau (NRT, Network Recovery Time) est le laps de temps nécessaire pour commuter le réseau de manière à accéder au site de reprise.

La HD n’est d’aucun secours en cas de calamité. COOP peut faire partie d’un plan de reprise après sinistre si le site secondaire est suffisamment éloigné du point de la catastrophe. Le plan plus simple consistant à stocker hors site des bandes de sauvegarde est soumis aux mêmes contraintes, parce que les bandes de sauvegarde et le site de secours doivent être suffisamment éloignés de l’axe. Les spécialistes de l’audit regardent désormais de beaucoup plus près l’emplacement des sites de stockage, de sauvegarde et de traitement, pour déterminer le risque de les voir frappés en même temps. Katrina a démontré que ce souci est fondé. Il est un autre point à considérer : différentes zones présentent des risques de catastrophes différents.

Un autre problème que les ouragans de l’automne dernier ont mis en lumière, est le déplacement du matériel et du personnel sur un site de secours. Si votre site de reprise n’a pas un effectif complet, est-ce que le personnel informatique pourra et acceptera de s’y rendre en cas de catastrophe ? Les autoroutes serontelles praticables et les avions volerontils ? Vos collaborateurs devront-ils s’occuper de leur famille plutôt que d’appliquer votre plan de reprise ? Ces questions concernent tout le personnel essentiel de l’entreprise, pas simplement les membres de l’équipe informatique. C’est pourquoi le plan de reprise informatique doit s’inscrire dans un plan plus large. L’état de préparation sur le plan de l’organisation est en train d’entrer dans le domaine de la responsabilité judiciaire qui inclut bien sûr l’informatique, mais va bien au-delà.

Les redbooks IBM Total Storage Business Continuity Solutions Overview (SG24-6684) et IBM Total Storage Solutions for Disaster Recovery (SG24- 6547) offrent davantage d’informations ainsi que des scénarios montrant plusieurs types de préparation. Pour une explication des niveaux de préparation, voir l’encadré « Niveaux de continuité de l’activité ». Le simple fait d’avoir un serveur opérationnel ne constitue en rien une reprise après sinistre. Souvent le traitement central a été restauré, mais tout a échoué parce qu’on n’a pas tenu compte de l’infrastructure d’appui : serveurs supplémentaires, logiciels des postes de travail, systèmes de communication et documents importants non stockés électroniquement. (Pour plus d’informations sur la gestion de l’infrastructure liée au sinistre, voir l’encadré « Prévoir l’impensable ».) En effet, si la préoccupation du site IT est de restaurer les systèmes, celle de l’entreprise est de reprendre l’activité.

Téléchargez gratuitement cette ressource

Endpoint Security : Guide de Mise en œuvre

Endpoint Security : Guide de Mise en œuvre

Détournement d’applications légitimes, élévation de privilèges, logiciels malveillants furtifs : comment les solutions de Endpoint Security permettent elles de faire face aux nouvelles techniques d'attaques complexes ? Découvrez, dans ce Guide Endpoint Security, les perspectives associées à leur mise en œuvre.

Tech - Par iTPro - Publié le 24 juin 2010