Si les sinistres IT sont par définition imprévisibles, la restauration des données ne devrait pas l’être. Elle devrait au contraire être planifiée, prévisible et contrôlée. Voici quelques recommandations pour développer une stratégie pour un plan de reprise après sinistre au cohérent avec le fonctionnement de votre entreprise.
Tribune par Christopher Géraud, Field Channel Manager, Quest Software
- Faire un inventaire des actifs
Toute planification de reprise après sinistre devrait toujours commencer par un inventaire des actifs IT afin de dénouer la complexité de l’environnement. Cet inventaire doit commencer par la liste de tous les actifs sous la responsabilité de l’IT, tous les serveurs, dispositifs de stockage, applications, données, commutateurs réseau, points d’accès et appliance réseau. Il faut ensuite localiser physiquement chaque actif, le réseau auquel il est connecté et identifier les dépendances.
- Effectuer une évaluation des risques
Une fois tous les actifs IT, des réseaux et des dépendances cartographiés, la liste des menaces internes et externes potentielles pour chacun de ces actifs doit être établie en imaginant le pire scénario, de la panne IT ordinaire à la catastrophe naturelle.
Puis, chaque scénario et impact potentiel doit inclure une notion de probabilité : Quelles seraient les conséquences de chaque scénario sur l’entreprise ? Pour cet exercice, les collaborateurs doivent être sollicité tout en leur rappelant que les petites pannes ordinaires sont plus fréquentes que les catastrophes naturelles et en attirant leur attention sur les incidents les plus probables comme les pannes électriques ou les défaillances matérielles.
- Définir l’importance critique des applications et des données
Avant d’élaborer le plan de reprise après sinistre de l’entreprise, on doit classer les données et applications selon leur importance pour l’entreprise en commençant par en parler avec les collaborateurs et équipes du support.
Il faut rechercher les points communs et les regrouper par importance pour les opérations, par fréquence de changement et par règle de rétention plutôt que de devoir appliquer une technique de reprise après sinistre différente à chaque application ou fichier. En regroupant des actifs avec des caractéristiques similaires, la mise en œuvre de la stratégie est simplifiée.
Et pour ne pas prendre seul des décisions fondées sur des hypothèses, les autres managers et membres des équipes de support doivent participer à cet exercice. Il faudra surement faire des compromis pour limiter le nombre de catégories de données. Pour les entreprises de taille moyenne, trois et cinq catégories suffisent.
- Définir les objectifs de reprise
Les objectifs de restauration sont différents selon les catégories d’actifs et de données. Par exemple, les objectifs de restauration peuvent être très stricts pour les bases de données de e-commerce, les entreprises ne pouvant se permettre de perdre des transactions ou d’être indisponibles trop longtemps. A l’inverse, pour un système interne hérité, les objectifs de restauration peuvent être plus lâches étant donné que les données ne sont pas modifiées très souvent et que la nécessité de restauration n’est pas si urgente.
De nombreux professionnels de l’IT se confrontent lors de cette étape à des difficultés. Fixer des objectifs de restauration sans consulter en amont les responsables de divisions est la raison principale d’un désalignement. Il est nécessaire de les impliquer dans le processus. Il s’agit ici d’apporter des réponses aux questions spécifiques des principaux concernés, de comprendre les besoins et d’accorder le niveau de disponibilité du service en fonction de la priorité pour l’entreprise. Une fois ces informations en main, elles doivent être traduite en objectifs de restauration à inclure dans votre plan de reprise après sinistre.
L’objectif de délai de restauration (RTO) est le délai acceptable d’indisponibilité des systèmes de production et des données. Pour calculer le RTO d’une application, on peut estimer le coût pour l’entreprise en cas de panne d’une application pendant une durée donnée. Combien perd-on si le portail d’un client était indisponible une heure ou un jour ? Combien cela coûterait-il si aucun des salariés ne pouvait travailler en raison d’une panne de messagerie ?
Calculer le RTO permet de connaître les fonctionnalités qu’il faut pour les systèmes et produits de sauvegarde. Par exemple, si le RTO est très élevé (disons de plus de quatre heures), on aura probablement le temps d’effectuer une sauvegarde depuis une bande, mais dans le cas inverse (seulement quelques minutes), il faudra mieux utiliser la réplication basée sur l’hôte ou une sauvegarde sur disque avec fonctions de protection continue des données.
Quel est le volume de données que l’entreprise peut se permettre de perdre ? C’est ce qui correspond à votre Objectif de point de restauration (RPO). Si l’entreprise peut supporter de perdre beaucoup de données, il est possible d’avoir un RPO élevé, de quelques heures à plusieurs jours. Dans le cas contraire, un RPO de quelques secondes sera mieux. Le RPO choisi déterminera la fréquence minimum de sauvegarde des données. Si une heure de données ne peut être perdue, sauvegardez au moins toutes les heures. Ainsi, en cas de panne, à 14h30 par exemple, il est toujours possible de récupérer la sauvegarde de 14h et tenir l’objectif RPO.
- Choisir les bons outils et techniques
La bonne nouvelle est qu’il existe actuellement sur le marché de nombreuses solutions de reprise après sinistre. Un excès de protection coûterait plus cher inutilement et introduirait une complexité superflue. Une protection insuffisante expose inévitablement les fonctions de l’entreprise à des risques.
Par exemple, les sauvegardes nocturnes selon les méthodes traditionnelles (à base de fichiers) sont plus que suffisantes pour les données à faible impact, mais cela ne convient pas aux données et applications à fort impact. Une solution de protection continue des données (CDP) convient idéalement aux données et systèmes à fort impact, mais peut venir alourdir les serveurs de production et les coûts de stockage.
Le composant le plus critique d’un plan de reprise après sinistre concerne peut-être la protection hors site, à utiliser quelle que soit la méthode de sauvegarde employée. La protection hors site (que ce soit un service de vaulting sur bande ou la réplication vers le cloud) devrait être proportionnée à vos objectifs de restauration. Il faut s’assurer que les données sont envoyées suffisamment loin dans une zone géographique qui ne sera pas concernée par le risque ; à au moins 40 kilomètres du site principal.
Enfin, le processus de restauration doit être automatisé et rationalisé autant que possible. En cas de sinistre, il est possible que le personnel IT nécessaire s’avère indisponible. L’automatisation réduit aussi le risque d’erreur humaine.
- Obtenir le soutien des personnes concernées
Il faut voir plus loin que le seul datacenter et faire participer les personnes concernées de toutes les divisions et ce dès la phase de planification en obtenant leur adhésion aux priorités de l’entreprise et aux contrats de niveau de service (SLA) proposés.
Il est également nécessaire de consulter les partenaires stratégiques et fournisseurs pour s’assurer de valoriser au maximum la solution de reprise après sinistre ou les services. Une fois que l’ensemble des personnes concernées ont été consulté, un dirigeant qui deviendra sponsor du projet doit intervenir et soutenir le projet. Il ne faut pas sous-estimer l’importance de la collaboration, du consensus et du soutien de la direction pour la réussite d’un plan de reprise après sinistre.
- Documenter et communiquer le plan
Quel que soit le scénario de sinistre, il faut une stratégie documentée pour revenir à l’état de fonctionnement. Ce document doit être rédigé pour ceux qui devront l’utiliser.
Mais il doit aussi être diffusé. Trop souvent, une seule personne dans l’entreprise connaît vraiment le plan d’ensemble, ce qui laisse l’entreprise vulnérable en cas de sinistre, si la personne est absente. De plus, il faut veiller à conserver la stratégie de reprise de façon à ce qu’elle soit accessible en cas de sinistre, et non sur une partition publique des dossiers Exchange. Le mieux est de l’imprimer et de la publier en plusieurs endroits.
- Tester et mettre en pratique le plan
Ne dit-on pas « c’est en pratiquant qu’on progresse » ? Aucune entreprise ne peut se targuer de détenir le plan de reprise parfait, mais avec la pratique les problèmes seront identifiés et rectifiés et le plan pourra être exécuter plus rapidement et précisément. Toutes les personnes concernées doivent assister aux sessions de mise en pratique, y compris si elles ne concernent pas nécessairement le plan de reprise en intégralité. Il peut très bien être subdiviser en plusieurs parties à tester.
- 9. Evaluer et actualiser le plan
Un plan de reprise après sinistre est un document qui évolue. Surtout au vu des conditions sans cesse changeantes de l’environnement. De plus la tolérance aux pannes et aux pertes de données peut décliner et des membres stratégiques du personnel peuvent être en congés ou avoir fini leur contrat. La direction IT peut également décider de migrer vers de nouveaux équipements ou systèmes d’exploitation ou l’entreprise peut acquérir une autre entreprise. Comme l’entreprise est dynamique et qu’elle change perpétuellement, le plan doit refléter l’état actuel de l’entreprise, quel qu’il soit.