Les solutions de récupération après sinistre

soit en effectuant
une restauration du serveur, soit en effectuant
une reconstruction du serveur
ou enfin en utilisant des solutions
de serveur de réserve. Les autres solutions
de type haute disponibilité en
cluster par exemple ne seront pas
abordées dans ce dossier, mais dans le
dossier haute disponibilité. En fonction
de la solution retenue, les options
et les modes de sauvegarde utilisés devront
être adaptés. La première solution
consiste donc à  restaurer le serveur
depuis une sauvegarde totale, ce
qui inclut la sauvegarde du système
avec les informations ‘System State’ et
ensuite la restauration des bases
Exchange. Cette solution est relativement
rapide, ce qui fait partie de ses
principaux avantages. En contrepartie,
les opérations de sauvegarde et la gestion
des données sur bande pour permettre
ce type d’opération demande
plus de ressources et d’attention.
Enfin, il faut savoir que si le système
présentait des anomalies au niveau de
certains fichiers ou au sein de bibliothèques
dll par exemple, ces défauts
seront de nouveau présent après la
restauration du serveur, car c’est l’ensemble
des fichiers et données du système
sauvegardé qui est restauré. De
plus, ce type de restauration ne peut
s’effectuer que sur une plate-forme
matérielle proche, pour ne pas dire
identique à  celle utilisée pour la sauvegarde.
En effet les pilotes et la configuration
des volumes doivent être adaptés
pour permettre le fonctionnement
du système ainsi restauré. Pour utiliser
ce type de sauvegarde en toute
confiance, il convient aussi de s’assurer
de disposer d’un système stable et
fiable. Cela impose une gestion quotidienne
des journaux d’événement
(Event Logs) afin de ne pas laisser s’installer
des composants perturbateurs
ou des applications pas toujours correctement
configurées ou intégrées
dans le système d’information de l’entreprise.
Mais dans le cas de virus, vers
ou autre code malicieux, la restauration
d’un serveur à  partir de sauvegardes
plus anciennes peut s’avérée
délicate car il faut assurer la mise à  jour
et la protection du serveur très rapidement
et si possible l’isoler du réseau de
production tant que toutes les mises à 
jours nécessaires ne sont pas effectuées.
La seconde solution consiste à 
prévoir la reconstruction du serveur.
Cette solution permet d’économiser le
volume des données sauvegardées, car
il n’est alors pas nécessaire de sauvegarder
les fichiers systèmes, mais uniquement
les données. D’autre part, le
système étant reconstruit, les bases
sont propres et saines, car aucune altération
du système n’est reprise. Ces
avantages ont un revers non négligeable
qui est le temps nécessaire à 
l’ensemble de l’installation du système
et des applications, mais cette solution
permet un changement important au
niveau de la plate-forme matérielle.
Elle s’impose même dans certains cas
d’impossibilité de retrouver un serveur
semblable à  celui qui est défectueux, à 
condition de disposer des pilotes à 
jour. Le problème des pilotes peut être
géré en effectuant un démarrage en
mode sans échec. Ensuite, il suffit de
restaurer les informations contenues
dans ‘System State’ et les applications
afin de permettre au serveur de
prendre la place du serveur endommagé.
La restauration des informations
système modifie la base de registre et
le serveur se retrouve ainsi avec le nom
Netbios et dans le domaine en lieu et
place du serveur ainsi remplacé. Pour
gagner du temps lors de la remise en
place du serveur dans cette solution de
reconstruction, il est souhaitable de
disposer d’un serveur de remplacement disponible sur place. On obtient
alors la troisième solution qui est l’utilisation
d’un serveur de remplacement
(stand-by server). Ce serveur est déjà 
formaté, avec le système Windows installé
et configuré, les outils de sécurité
installés (antivirus et mises à  jour de
Windows), il ne reste plus alors, en cas
de besoin, qu’à  changer les connexions
matérielles et à  effectuer les opérations
de restauration depuis les sauvegardes.
Cette dernière solution permet
de parer à  des défaillances matérielles
rapidement, car le serveur peut
alors servir de pièce de remplacement
et en cas de crash important, le temps
de restauration est inférieur aux deux
autres solutions tout en repartant d’un
système sain et qui est à  jour.

Dans les trois cas de figure, il est
préférable de monter une maquette,
avec un serveur de test, afin d’effectuer
cette opération et cela dans plusieurs
buts. Le premier et le plus important
étant de s’assurer du bon fonctionnement
de la restauration des données.
Cela permet de valider, et si besoin est
de revoir les procédures de sauvegarde
si certaines informations sont manquantes
ou erronées. Ensuite cela permet
une validation des différentes procédures
et étapes à  mettre en place, ce
qui permet une plus grande efficacité
lorsque l’incident se produit et que la
pression et le stress ne permettent pas
toujours une concentration optimale.
La mise en place de procédures avec
des copies d’écran minimalise aussi
le risque d’erreurs. Enfin cela permet
de mesurer le temps nécessaire à  la remise
en état d’un serveur, ce qui est
aussi un point important pour
connaître le temps d’indisponibilité du
service auprès des utilisateurs. Ce type
d’opérations doit être répété régulièrement
pour plusieurs raisons : être sûr
que la procédure reste valable en fonction
de l’évolution des besoins et de
l’évolution des plates-formes (version
de logiciels de sauvegarde, patch système
et Exchange….) et aussi pour remettre
à  jour le temps nécessaire à 
cette opération en fonction de l’augmentation
probable du volume des
données stockées au sein des bases
Exchange.