Sauvegardes copy-only et restauration différentielle

Une sauvegarde complète supplémentaire est créée pour un environnement de test. Plus tard, la restauration différentielle échoue parce que le plan attend toujours une ancienne sauvegarde complète. Le problème n'est pas une rupture de chaîne du journal : le full ordinaire supplémentaire a changé la base différentielle.

Suivre une chronologie précise

Supposons un full planifié dimanche, un full ordinaire ponctuel mardi et un différentiel mercredi. Celui de mercredi dépend de mardi, pas de dimanche. Si le fichier de mardi disparaît d'un partage temporaire, le plan dimanche plus mercredi ne suffit plus.

Avec COPY_ONLY mardi, la base serait restée celle de dimanche. Un full copy-only se restaure comme un full, mais ne devient pas la base des différentiels suivants. Cette option convient donc à de nombreuses copies ponctuelles hors planning, pas à tous les fulls planifiés : une stratégie différentielle doit établir volontairement ses bases ordinaires.

SELECT TOP(50) database_name,type,is_copy_only,
 backup_start_date,backup_finish_date,first_lsn,last_lsn,
 database_backup_lsn,differential_base_lsn
FROM msdb.dbo.backupset
WHERE database_name=N'YourPracticeDatabase'
ORDER BY backup_finish_date DESC;

La requête expose types, indicateur copy-only et métadonnées LSN. D, I et L désignent full de base, différentiel et journal. Ces informations aident l'enquête, sans prouver que tous les fichiers existent réellement ni construire automatiquement un plan correct.

Distinguer la chaîne du journal

Un full ordinaire ne casse pas une chaîne de sauvegardes du journal existante. Les logs restent nécessaires après la sauvegarde de données choisie pour atteindre l'objectif. Changement de modèle de récupération et fichier journal manquant sont d'autres problèmes.

Un log copy-only conserve le point d'archivage normal et ne tronque pas le journal. Il ne remplace pas les sauvegardes régulières du processus établi. En produire continuellement ne corrige pas un besoin de réutilisation qui exige des sauvegardes normales.

Coordonnez les outils : agent fournisseur, maintenance et opérateur peuvent produire des fichiers valides sans que personne maîtrise le jeu global. Centralisez inventaire et rétention autour de la restauration, pas seulement des statuts de jobs indépendants.

Vérifier les véritables dépendances

L'historique peut survivre aux fichiers supprimés. Le serveur cible peut aussi manquer de l'historique msdb source. Lisez les en-têtes réels et retrouvez toutes les bandes d'une sauvegarde répartie. Le mot full ou diff dans un nom n'est pas une preuve. Vérifiez identité, base, séquence et matériel de chiffrement.

Pour une copie ponctuelle, utilisez un nouveau nom et les options prévues. Le modèle suivant suppose une base d'exercice existante et un chemin accessible au serveur. Remplacez-les explicitement. Il omet INIT pour ne pas demander l'écrasement de médias existants.

BACKUP DATABASE [YourPracticeDatabase]
TO DISK=N'D:\Backups\YourPracticeDatabase_adhoc_unique_name.bak'
WITH COPY_ONLY,CHECKSUM,COMPRESSION,STATS=10;

Après la copie ad hoc, restaurez un full planifié et son différentiel sur une destination isolée, puis les logs requis jusqu'au point visé. Une sauvegarde réussie ou VERIFYONLY ne démontre pas à elle seule le fonctionnement de toute la récupération métier.

Conservez les bases tant que leurs différentiels appartiennent à la fenêtre promise. Enregistrez fichiers et clés utilisés dans un exercice réussi. Vérifiez que les règles de rétention des différents outils ne suppriment pas une dépendance encore nécessaire. La fiabilité vient d'une chaîne explicite et testée, qui reste intacte lorsque quelqu'un demande une copie supplémentaire.

Notez aussi la position du jeu de sauvegarde lorsque plusieurs jeux partagent un fichier. Un chemin correct ne suffit pas à identifier la sauvegarde nécessaire.

Références techniques: Microsoft Learn: Copy-only backups · Microsoft Learn: Backup history.