Réplication de base de données contre réplication du stockage

La raison d’être principale de la réplication est la reprise après sinistre. Pour faire face à ce type de situation, il vous faut une copie de votre base de données. En fait, de nombreuses entreprises ont besoin d’une copie de la base de données, avec son application, sur un site distant. En général, l’entreprise propriétaire de l’application possède un contrat de niveau de service (SLA) qui spécifie la rapidité avec laquelle l’application sera de nouveau disponible après un sinistre (objectif de temps de récupération ou RTO) et le degré acceptable de perte de données autorisé pour l’application (objectif de point de récupération ou RPO).

Par exemple, s’il faut trois jours pour reconstruire l’infrastructure matérielle et logicielle, ainsi que le réseau et les données pour que l’application soit disponible, le RTO est de trois jours. Si la base de données et l’application sont entièrement sauvegardées sur des bandes et que celles-ci sont expédiées hors site tous les dimanches, la valeur RPO la plus défavorable pour les données et l’application sera sept jours (à savoir, les données récupérées auront au mieux sept jours d’ancienneté). Pour mettre en ?uvre un RTO et un RPO réalistes concernant une application, il faut comprendre la chronologie d’une reprise après sinistre et la figure 1 présente un scénario de reprise type.

Les étapes de la chronologie constituent une vue d’ensemble du travail à accomplir avant que l’application soit de nouveau disponible. Cette chronologie identifie la période de mesure du RTO. La définition du début et de la fin du RTO dans la chronologie peut être négociée dans les paramètres d’un SLA. L’étape 4 de la figure 1 rappelle qu’une grande partie de l’infrastructure doit être en place avant ou, par conséquent, pendant un sinistre, afin de faciliter la restauration des données. Aux étapes 5 à 8, les données sont annulées (roll back) jusqu’au point de cohérence de ce niveau.

Par exemple, à l’étape 5, la cohérence de niveau stockage requiert l’annulation des données incomplètes sur le système NTFS afin que celui-ci soit cohérent. Une fois le niveau stockage cohérent, SQL Server essaie d’annuler les transactions incohérentes. Ce processus se déroule à chaque niveau jusqu’à rétablir la cohérence.