Log shipping : mesurer la reprise, pas seulement les tâches
Distinguez les retards de sauvegarde, copie et restauration, puis testez un basculement avec une estimation justifiable des données perdues.
Le log shipping peut fournir une copie de secours avec des composants relativement simples. Son piège opérationnel consiste à confondre une tâche réussie avec le respect d'un objectif de reprise. Une copie peut réussir alors que le serveur principal ne produit plus de sauvegardes. Une restauration peut réussir alors que le fichier le plus récent reste ailleurs. Il faut mesurer le retard du contenu récupérable par rapport au travail métier.
Suivre un fichier de bout en bout
Suivez une sauvegarde précise du journal : création sur le principal, arrivée sur le secondaire, puis application à la base. Consignez son identité et les horaires de chaque étape. Si les sauvegardes sont récentes mais les fichiers copiés anciens, examinez partage, stockage et copie. Si les fichiers arrivent sans être appliqués, recherchez erreurs, prédécesseurs manquants, lecteurs bloquants ou débit insuffisant.
Sur une instance configurée comme moniteur, la procédure suivante affiche une synthèse en lecture seule. Utilisez les permissions administratives nécessaires. Comparez les résultats du principal et du secondaire et vérifiez que le moniteur reçoit encore des informations récentes.
USE master;
EXEC sys.sp_help_log_shipping_monitor;
Un enregistrement ancien peut indiquer une panne de télémétrie. Vérifiez donc historique local et fichiers réels avant toute intervention. Inversement, cette possibilité ne justifie pas de rejeter chaque alerte. Définissez un âge maximal acceptable et testez la réception de la notification, pas seulement son existence dans la configuration.
Avec une sauvegarde toutes les cinq minutes et des copies puis restaurations toutes les deux minutes, une transaction validée juste après une sauvegarde attend le cycle suivant. Elle peut ensuite attendre les deux étapes aval. Ces horaires ne promettent pas une perte maximale de cinq minutes. Les exécutions réelles, incidents, files d'attente et fichiers encore accessibles déterminent le résultat.
Expliciter délai et conservation
Un délai volontaire de restauration peut maintenir la copie avant une suppression accidentelle assez longtemps pour intervenir. Cette protection dépend d'une détection avant application du mauvais changement. Elle ne remplace pas des sauvegardes conservées indépendamment : la découverte peut être tardive, et une compromission commune peut toucher plusieurs copies.
Séparez l'âge du dernier fichier copié de celui du dernier fichier restauré. L'alerte de restauration doit intégrer le délai prévu et une tolérance justifiée. La copie doit néanmoins continuer. Une exemption générale pour les systèmes retardés risquerait de masquer une chaîne réellement arrêtée.
La conservation doit couvrir le délai, les interruptions plausibles et le temps de diagnostic puis rattrapage. Si le nettoyage supprime un journal encore nécessaire, un fichier ultérieur valide ne comble pas le trou. Coordonnez également les autres logiciels de sauvegarde : une sauvegarde ordinaire du journal réalisée ailleurs peut créer un fichier indispensable que le processus ne transfère jamais. Attribuez la responsabilité de la séquence complète.
Répéter le changement de rôle
Le basculement est manuel et contrôlé. Empêchez d'abord l'ancien principal d'accepter des écritures concurrentes. S'il reste accessible, évaluez une sauvegarde finale du journal, puis transférez et appliquez tous les fichiers nécessaires disponibles. Sinon, documentez le dernier état récupérable et l'incertitude concernant les transactions suivantes.
Ne lancez pas la récupération finale uniquement pour voir si la base s'ouvre. Après cette étape, la séquence existante ne peut pas simplement reprendre. Le rétablissement de la protection nécessite un plan. Décidez qui accepte la perte éventuelle, quand cesser d'attendre les fichiers et comment rediriger les clients.
Le mode STANDBY peut autoriser des lectures entre restaurations, mais les lecteurs peuvent perturber le calendrier si leur déconnexion est mal gérée. Testez le mode et la combinaison de versions retenus. Vérifiez ensuite connexions, comptes, tâches et dépendances externes. Mesurez jusqu'à la première opération métier correcte et conservez la séquence des médias avec la durée observée.
Références techniques: Microsoft Learn: Log shipping overview · Microsoft Learn: Monitor summary · Microsoft Learn: Manual failover.