Restauration à un instant précis : vérifier la cible
Construisez une chaîne complète, choisissez une cible STOPAT justifiable et vérifiez les données métier avant de rouvrir la base restaurée.
Restaurer à un instant précis revient à décider quelles transactions doivent appartenir à la base récupérée. « Juste avant la suppression » ne constitue pas encore une procédure. Il faut un horodatage fiable, une chaîne de sauvegardes continue et une vérification métier capable de distinguer le bon état d'une base simplement accessible. Ce guide suppose le modèle de récupération complète et des sauvegardes du journal déjà opérationnelles.
Définir la frontière métier
Imaginons qu'un déploiement supprime les mauvaises factures à 14:30. Un journal applicatif peut indiquer la réception de la requête alors que sa transaction se termine plus tard. L'ordinateur du client peut utiliser un autre fuseau. Recoupez traces SQL, identifiants de requêtes et changements métier audités avant de choisir la limite. Conservez les preuves originales au lieu d'écraser immédiatement la base endommagée.
Privilégiez une restauration parallèle, avec un autre nom de base et des fichiers physiques distincts. Vous préservez ainsi les éléments d'analyse et permettez une validation métier. Prévoyez l'espace nécessaire et empêchez les tâches planifiées ou intégrations de considérer cette copie comme la production. Restaurer SQL Server n'annule pas un paiement ou un courriel déjà envoyé par un système externe.
Consignez la convention horaire utilisée. La valeur de l'exemple représente un instant sur la chronologie vérifiée du serveur, sans prétendre être en UTC. Une heure ambiguë lors du changement saisonnier nécessite un essai explicite. Choisir arbitrairement la seconde précédente peut aussi exclure des transactions légitimes à rapprocher ensuite.
Construire puis appliquer la chaîne
Commencez par une sauvegarde complète dont l'état final précède la cible. Ajoutez éventuellement une différentielle compatible, sans dépasser cette cible, puis tous les journaux nécessaires jusqu'à celui qui contient l'instant recherché. La frontière concerne les transactions validées. Une transaction commencée avant mais validée après ne doit pas apparaître comme travail confirmé.
Examinez les en-têtes réels et la liste des fichiers. Les noms et heures de fin ne prouvent pas la continuité. Identifiez la position des jeux, toutes les bandes d'une sauvegarde répartie, les clés de chiffrement et les noms logiques nécessaires à MOVE. Une sauvegarde complète postérieure à l'erreur ne peut pas être ramenée en arrière par un STOPAT ajouté au journal suivant.
Le modèle ci-dessous suppose une base isolée ayant déjà reçu la bonne sauvegarde complète et éventuellement différentielle avec NORECOVERY. Remplacez les chemins et répétez l'opération pour chaque journal requis, dans l'ordre. Gardez exactement la même cible.
RESTORE LOG [RecoveryPractice]
FROM DISK=N'D:\Restore\required_log_001.trn'
WITH NORECOVERY, STOPAT='2025-05-12T14:29:59';
-- Repeat for every required log, with the same STOPAT.
-- Only after confirming that the target was reached:
-- RESTORE DATABASE [RecoveryPractice] WITH RECOVERY;
La base non récupérée peut encore recevoir des journaux supplémentaires. Avant l'étape finale de récupération, vérifiez que la chaîne atteint réellement l'instant demandé. Une cible située après le dernier journal disponible exige de rechercher les médias manquants. L'absence d'ouverture ne prouve ni réussite ni perte définitive. Avec le modèle de récupération journalisé en bloc, des opérations minimalement journalisées limitent les choix à l'intérieur de la sauvegarde concernée.
Valider avant de reconnecter
Si la base d'origine reste accessible, évaluez la sauvegarde de fin de journal pour préserver les transactions non encore sauvegardées avant toute restauration destructive. La bonne méthode dépend de son état et de la cible. N'improvisez pas un écrasement avec WITH REPLACE pendant l'incident.
Après récupération, vérifiez l'intégrité puis les invariants métier : factures présentes, opération erronée absente, validations antérieures connues conservées et totaux cohérents. Inventoriez les transactions ultérieures volontairement exclues pour une reprise contrôlée. Une base en ligne ne démontre aucune de ces propriétés.
Mesurez séparément recherche, récupération des fichiers, restauration, validation et reconnexion applicative. Des identifiants manquants peuvent dépasser l'objectif de reprise malgré une restauration rapide. Conservez la séquence exacte des médias et les requêtes de contrôle du test pour qu'un autre opérateur puisse reproduire le résultat.
Références techniques: Microsoft Learn: Point-in-time restore · Microsoft Learn: Tail-log backups.