Reprise Exchange 2003 en utilisant VSS

sont perdues ou corrompues, mais
que les fichiers log actuels restent intacts
sur disque ; quand les fichiers log
courants sur disque sont perdus ou
corrompus, mais que les bases de données
restent intactes ; ou quand les
bases de données et les fichiers log
courants dans un SG sont perdus ou
corrompus.
Dans le contexte d’Exchange 2003
et de VSS, seule l’application de sauvegarde
est chargée de restaurer les données
sur disque. C’est le moteur base
de données d’Exchange 2003, et pas le
Requestor, qui est chargé de récupérer
les données dans un état à  jour et homogène,
par relecture du fichier log.
Pour cela, le moteur base de données
active les procédures de reprise soft ou
hard existantes. Une fois que l’application
de sauvegarde consciente de VSS a
restauré les fichiers log de transactions
et les bases de données, Exchange
2003 remonte et redémarre le SG, puis
le moteur base de données amorce la
reprise. Le moteur base de données
détermine que l’état des bases de données
n’est pas en concordance avec la
fin du fichier log sur disque et commence
la procédure de reprise.
Il existe trois scénarios de restauration
de données Exchange 2003, mais
seulement deux procédures correspondantes.
Les procédures de reprise
Roll-Forward et de reprise Point-in-
Time pour restaurer les données sont
les mêmes dans les deux cas : que l’on
n’ait perdu que les fichiers log de SG
ou que l’on ait perdu les fichiers log et
les bases de données de SG. On utilise
la même procédure parce que la perte
des fichiers log est catastrophique dans
Exchange et qu’elle oblige à  restaurer
la totalité du SG. Dans l’un ou l’autre
cas, ces options de reprise suivent un
déroulement pas à  pas bien précis :

1. Le Requestor de l’application de sauvegarde
   par l’intermédiaire de
   l’Exchange Writer et des API, met le
   SG offline.

2. L’application de sauvegarde effectue une reprise basée sur VSS des volumes
   requis à  partir de l’ensemble
   SG Shadow Copy.
   • Si un LUN par SG est configuré,
     Exchange reprend toutes les bases
     de données à  l’exception de celles
     qui sont intactes.

   • Si de multiples LUN par SG sont
     configurés, Exchange ne récupère
     que les LUN avec les bases de données
     ayant besoin d’une reprise à 
     partir de l’ensemble Shadow Copy.
3. Exchange effectue une reprise hard
   ESE (Extensible Storage Engine) et
   rejoue (replay) les fichiers log applicables
   pour les bases de données en
   cours de reprise, selon qu’une reprise
   Roll-Forward ou qu’une reprise
   Point-in-Time est en cours.

4. Le Requestor de l’application de sauvegarde
   par l’intermédiaire de
   l’Exchange Writer et des API met le
   SG online.

Reprise Roll-Forward. Dans une reprise
Roll-Forward, une ou plusieurs
bases de données dans le SG sont perdues,
mais les fichiers log sont intacts
sur le serveur au moment de la reprise.
Dans ce cas, on peut sélectivement restaurer
chacune des bases de données
affectées à  partir d’une sauvegarde Full
du SG. Dans le contexte du cadre VSS,
on ne sélectionne dans la sauvegarde
SG que les composants de la base de
données qui correspondent aux bases
de données que l’on veut restaurer.
L’application de sauvegarde consciente
de VSS restaure les bases de
données, et Exchange récupère les
bases de données et les met à  jour à 
partir de leur état au moment de l’instantané,
en faisant un « rolling forward
» au travers des journaux de transaction
(c’est-à -dire, reprise hard
d’Exchange). L’option de reprise Roll-
Forward permet de récupérer des données
sauvegardées ainsi que des
données qui se sont accumulées (par
exemple dans les journaux de transactions)
depuis la dernière sauvegarde.

Reprise Point-in-Time. Quand le volume
de fichiers log du SG a été endommagé
ou perdu ou que les fichiers
log ont été perdus ou endommagés en
même temps que tout ou partie des
bases de données du SG, il faut restaurer
les fichiers log à  partir d’une sauvegarde
précédente, en même temps
que toutes les bases de données sauvegardées
au moment de la dernière
sauvegarde complète du SG. Comme
on ne peut pas récupérer jusqu’au
point de l’incident parce que les fichiers
log et les bases de données depuis
la dernière sauvegarde ont été
perdus ou endommagés, on ne peut
récupérer que jusqu’au point de la dernière
sauvegarde complète. C’est ce
que l’on appelle la reprise Point-in-
Time. Comme cette option n’offre pas
de possibilité Roll-Forward, certaines
données seront perdues. Pour offrir la
reprise Point-in-Time, il faut restaurer
les bases de données que l’on a sauvegardées
au moment de la sauvegarde
Full ainsi que les fichiers log provenant
de la sauvegarde Full. En outre, il faut
récupérer toutes les bases de données
associées au SG. On ne peut pas supposer
que certaines des bases de données
sont restées dans un état homogène
de transactions au moment où les
fichiers log ont été perdus et sont passés
offline, parce que la perte du journal
de transactions est une erreur fatale
qui entraîne la fermeture
immédiate du Store sans garantie d’homogénéité.
Par conséquent, pour être
certain que les bases de données sont
dans un état homogène quand on redémarre
le SG, il faut remettre tout le
SG à  l’état qui était le sien au moment
de la dernière sauvegarde Full.