Comment savoir si une chaîne de journaux de sauvegarde est rompue?

Question

J'ai eu une situation où les sauvegardes natives étaient effectuées sur un serveur.
J'ai constaté dans msdb qu'il y avait un outil de sauvegarde tiers (AppAssure) qui prenait également VSS (genre de) backup to virtual device.

À un certain intervalle, l'AppAssure (sauvegarde en cours vers VIRTUAL DEVICE) faisait un COPY_ONLY backup et à un autre intervalle, il faisait un FULL backup briser la chaîne de grumes.

Y a-t-il un moyen (T-SQL query) pour savoir quand une chaîne de sauvegarde est interrompue?

Voici une capture d'écran de la situation de février.

John aka hot2use · Accepted Answer

Lecture de référence/Questions et réponses similaires

Vous voudrez peut-être consulter mon réponse que j'ai publié en réponse à la question: Les sauvegardes VSS vont-elles briser la chaîne de connexion? (dba.stackexchange.com)

L'explication dans ma réponse renvoie également à la question Comment puis-je sauvegarder une base de données SQL Server à l'aide de la sauvegarde de Windows Server? (serverfault.com) qui était également répond par moi-même.

Chaîne de journaux de transactions

Lorsqu'une sauvegarde du journal des transactions (TLOG) est effectuée, les informations de sauvegarde sont stockées dans la base de données msdb dans diverses tables. Les informations stockées contiendront des informations telles que backup_type, logical_device_name, physical_device_name, is_copy_only, is_snapshot Et divers ..._lsn colonnes (lsn = numéro de séquence du journal).

Vous pouvez récupérer les informations de la chaîne de sauvegarde du journal des transactions à partir de votre instance SQL Server via la base de données msdb avec le script suivant:

/* ================================================================== Author......: hot2use Date........: 25.04.2018 Version.....: 0.1 Server......: localhost (first created for) Database....: msdb Owner.......: - Table.......: various Type........: Script Name........: ADMIN_Retrieve_Backup_History_Information.sql Description.: Retrieve backup history information from msdb database ............ ............ ............ History.....: 0.1 h2u First created ............ ............ ================================================================== */ SELECT /* Columns for retrieving information */ -- CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS SRVNAME, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_start_date, msdb.dbo.backupset.backup_finish_date, -- msdb.dbo.backupset.expiration_date, CASE msdb.dbo.backupset.type WHEN 'D' THEN 'Full' WHEN 'I' THEN 'Diff' WHEN 'L' THEN 'Log' END AS backup_type, -- msdb.dbo.backupset.backup_size / 1024 / 1024 as [backup_size MB], msdb.dbo.backupmediafamily.logical_device_name, msdb.dbo.backupmediafamily.physical_device_name, -- msdb.dbo.backupset.name AS backupset_name, -- msdb.dbo.backupset.description, msdb.dbo.backupset.is_copy_only, msdb.dbo.backupset.is_snapshot, msdb.dbo.backupset.checkpoint_lsn, msdb.dbo.backupset.database_backup_lsn, msdb.dbo.backupset.differential_base_lsn, msdb.dbo.backupset.first_lsn, msdb.dbo.backupset.fork_point_lsn, msdb.dbo.backupset.last_lsn FROM msdb.dbo.backupmediafamily INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id /* ---------------------------------------------------------------------------- Generic WHERE statement to simplify selection of more WHEREs -------------------------------------------------------------------------------*/ WHERE 1 = 1 /* ---------------------------------------------------------------------------- WHERE statement to find Device Backups with '{' and date n days back ------------------------------------------------------------------------------- */ -- AND physical_device_name LIKE '{%' /* ------------------------------------------------------------------------------- WHERE statement to find Backups saved in standard directories, msdb.dbo.backupfile AS b ---------------------------------------------------------------------------------- */ -- AND physical_device_name LIKE '[fF]:%' -- STANDARD F: Backup Directory -- AND physical_device_name NOT LIKE '[nN]:%' -- STANDARD N: Backup Directory -- AND physical_device_name NOT LIKE '{%' -- Outstanding Analysis -- AND physical_device_name NOT LIKE '%$\Sharepoint$\%' ESCAPE '$' -- Sharepoint Backs up to Share -- AND backupset_name NOT LIKE '%Galaxy%' -- CommVault Sympana Backup /* ------------------------------------------------------------------------------- WHERE Statement to find backup information for a certain period of time, msdb.dbo.backupset AS b ---------------------------------------------------------------------------------- AND (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7) -- 7 days old or younger AND (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) <= GETDATE()) -- n days old or older */ /* ------------------------------------------------------------------------------- WHERE Statement to find backup information for (a) given database(s) ---------------------------------------------------------------------------------- */ AND database_name IN ('AdventureWorks2012') -- database names -- AND database_name IN ('rtc') -- database names /* ------------------------------------------------------------------------------- ORDER Clause for other statements ---------------------------------------------------------------------------------- */ --ORDER BY msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date -- order clause ---WHERE msdb..backupset.type = 'I' OR msdb..backupset.type = 'D' ORDER BY --2, 2 DESC, 3 DESC

^{Attention: La clause where sélectionne actuellement la base de données AdventureWorks2012}

Chaîne de journal des transactions cassée

La chaîne de journaux (de transaction) n'est jamais interrompue, sauf si l'une des conditions suivantes est remplie:

un fichier de sauvegarde du journal des transactions a été supprimé
un fichier de sauvegarde du journal des transactions n'est pas accessible (quelque part dans un périphérique de sauvegarde; solution de sauvegarde tierce)
la base de données est en modèle de récupération SIMPLE
une sauvegarde du journal des transactions a été effectuée avec l'option TRUNCATE_ONLY
une sauvegarde COMPLÈTE de la base de données a été effectuée sans l'option COPY_ONLY, puis supprimée du disque car les développeurs n'avaient besoin que d'une sauvegarde rapide pour analyser une situation dans la base de données et votre sauvegarde FULL avant celle-ci a été supprimée par (a) procédure de sauvegarde.

Ta situation

Dans la capture d'écran que vous avez fournie, vous avez une sauvegarde FULL de la base de données qui est is_copy_only Et peu de temps après une sauvegarde FULL qui n'est pas is_copy_only. Maintenant ce que vous ne savez pas:

La deuxième sauvegarde FULL, non - is_copy_only Est-elle un instantané ou non?

Si vous utilisez mon script ci-dessus et modifiez la clause WHERE pour qu'elle corresponde au nom de votre base de données, vous découvrirez peut-être que cette sauvegarde FULL qui n'est pas is_copy_only Pourrait simplement être un is_snapshot.

Et cela pourrait simplement ouvrir une nouvelle question:

La sauvegarde de la base de données FULL, is_snapshot De ma base de données interrompra-t-elle la chaîne de sauvegarde du journal?

Mais...

.... quelle que soit la manière dont cela se passe, tant que vous disposez d'une chaîne ininterrompue de sauvegardes FULL et TLOG auxquelles vous pouvez accéder, vous pouvez toujours restaurer votre base de données à tout moment, même si vous avez une autre sauvegarde FULL entre les deux.

Vous pouvez le vérifier avec la sortie de mon script pour votre base de données, en regardant les chiffres first_lsn Et last_lsn. Ils doivent correspondre, même en contournant une sauvegarde FULL.

Mieux vaut prévenir que guérir

J'ai une base de données AdminDB2 Sur l'une de mes instances. J'ai créé une sauvegarde TLOG, modifié des données, effectué une sauvegarde FULL, modifié des données, effectué une sauvegarde TLOG, ....

Jetons un œil à mon historique de sauvegarde de mon AdminDB2:

dbname backup_start_date backup_finish_date type Log physical_device_name C S checkpoint_lsn dbase_backup_lsn dlsn first_lsn flsn last_lsn AdminDB2 2018-04-25 17:29:08.000 2018-04-25 17:29:08.000 TLOG NULL C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172908.trn 0 0 36000002022400042 36000002022400042 NULL 36000002021900001 NULL 36000002025100001 AdminDB2 2018-04-25 17:28:48.000 2018-04-25 17:28:48.000 Full NULL C:\SQL\Backup\AdminDB2\FULL\AdminDB2_FULL_20180425_172848.bak 0 0 36000002022400042 36000002018900037 NULL 36000002022400042 NULL 36000002024200001 AdminDB2 2018-04-25 17:28:23.000 2018-04-25 17:28:23.000 TLOG NULL C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172823.trn 0 0 36000002018900037 36000002018900037 NULL 36000002021500001 NULL 36000002021900001 AdminDB2 2018-04-25 17:28:07.000 2018-04-25 17:28:07.000 TLOG NULL C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172807.trn 0 0 36000002018900037 36000002018900037 NULL 36000002018400001 NULL 36000002021500001 AdminDB2 2018-04-25 17:27:32.000 2018-04-25 17:27:32.000 Full NULL C:\SQL\Backup\AdminDB2\FULL\AdminDB2_FULL_20180425_172732.bak 0 0 36000002018900037 36000001990800037 NULL 36000002018900037 NULL 36000002020600001 AdminDB2 2018-04-25 17:15:00.000 2018-04-25 17:15:00.000 TLOG NULL C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_171500.trn 0 0 36000002016000003 36000001990800037 NULL 36000002018100001 NULL 36000002018400001

_{L'ordre est la date décroissante}

Vous pouvez voir la dernière sauvegarde TLOG en haut, la sauvegarde précédente FULL (entre les deux) dans 2018-04-25 17:28:48.000, La sauvegarde précédente TLOG dans 2018-04-25 17:28:23.000, Etc.

Pour restaurer la base de données AdminDB2 Au point dans le temps actuel, je devrais utiliser la première sauvegarde FULL de 2018-04-25 17:27:32.000 (Car j'ai supprimé l'intervalle FULL (sauvegarde) avec toutes les sauvegardes TLOG.

Essayons.

Supprimez le fichier de sauvegarde FULL AdminDB2_FULL_20180425_172848.bak Sur mon disque (ou renommez-le), simplement parce que c'est celui entre les deux.
Ouvrez l'interface graphique de restauration dans SSMS et ajoutez ..
- la sauvegarde FULL AdminDB2_FULL_20180425_172732.bak
- tous les fichiers de sauvegarde TLOG
  - AdminDB2_TLOG_20180425_172807.trn
  - AdminDB2_TLOG_20180425_172823.trn
  - AdminDB2_TLOG_20180425_172908.trn
Assurez-vous d'avoir défini l'option Overwrite the existing database (WITH REPLACE)
Effectuez la restauration (ou scriptez l'instruction dans une fenêtre de requête)

Scénario

USE [master] RESTORE DATABASE [AdminDB2] FROM DISK = N'C:\SQL\BACKUP\AdminDB2\FULL\AdminDB2_FULL_20180425_172732.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5, REPLACE RESTORE LOG [AdminDB2] FROM DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172807.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5 RESTORE LOG [AdminDB2] FROM DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172823.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5 RESTORE LOG [AdminDB2] FROM DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172908.trn' WITH FILE = 1, NOUNLOAD, STATS = 5 GO

Production

15 percent processed. 30 percent processed. 45 percent processed. 60 percent processed. 75 percent processed. 90 percent processed. 100 percent processed. Processed 848 pages for database 'AdminDB2', file 'AdminDB' on file 1. Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1. RESTORE DATABASE successfully processed 850 pages in 0.134 seconds (49.502 MB/sec). 100 percent processed. Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1. Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1. RESTORE LOG successfully processed 2 pages in 0.005 seconds (3.027 MB/sec). 100 percent processed. Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1. Processed 1 pages for database 'AdminDB2', file 'AdminDB_log' on file 1. RESTORE LOG successfully processed 1 pages in 0.005 seconds (0.390 MB/sec). 100 percent processed. Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1. Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1. RESTORE LOG successfully processed 2 pages in 0.005 seconds (3.125 MB/sec).

... et la base de données est de retour EN LIGNE.

Sommaire

La chaîne de sauvegarde ne se brise que lorsque vous perdez les sauvegardes TLOG entre les deux, à part cela, vous pouvez restaurer une base de données à partir d'une sauvegarde FULL il y a longtemps et simplement ajouter toutes les sauvegardes TLOG.

Toutefois...

... il est plus rapide d'avoir à portée de main des sauvegardes FULL, DIFF et TLOG plus récentes.

_{Informations supplémentaires en réponse au commentaire: La sauvegarde du journal des transactions a été effectuée avec l'option TRUNCATE_ONLY - lorsque cela se produit, existe-t-il un moyen de le savoir par requête T-SQL}

Sauvegarde du journal des transactions avec Truncate_only

Dans les versions précédentes de SQL Server antérieures à SQL Server 2008, vous pouviez utiliser l'instruction suivante:

 BACKUP LOG [AdminDB2] WITH TRUNCATE_ONLY

Cela est obsolète et n'est plus pris en charge. Vous recevrez un message d'erreur semblable au suivant:

Msg 155, Level 15, State 1, Line 10 'TRUNCATE_ONLY' is not a recognized BACKUP option.

La nouvelle méthode consiste à sauvegarder sur le disque NUL et est exécutée avec la commande suivante:

BACKUP LOG [AdminDB2] TO DISK='NUL'

Cela renverra les informations suivantes:

Processed 1 pages for database 'AdminDB2', file 'AdminDB_log' on file 1. BACKUP LOG successfully processed 1 pages in 0.001 seconds (1.464 MB/sec).

Avis
Utilisez [~ # ~] pas [~ # ~] utilisez-le dans la production. Vous perdrez la possibilité de restaurer à un moment précis au cours de cette sauvegarde TLOG.

Référence: BACKUP (Transact-SQL) (Microsoft Docs)

Votre historique de sauvegarde affichera ceci comme:

dbname backup_start_date backup_finish_date type ldev pdev C S checkpoint_lsn dbase_backup_lsn dlsn first_lsn flsn last_lsn AdminDB2 2018-04-26 09:35:05.000 2018-04-26 09:35:05.000 Log NULL NUL 0 0 36000002030100002 36000002022400042 NULL 36000002033400001 NULL 36000002033700001

Les informations pour logical_device_name (ldev) et physical_device_name (pdev) contiendront toutes les deux la valeur NULL. Ceci indique qu'un BACKUP LOG ... A été exécuté avec un TRUNCATE_ONLY (Nouveau: TO DISK='NUL'). Vous aurez perdu la possibilité de restaurer au-delà de ce point à l'aide des sauvegardes du journal des transactions.

_{Informations supplémentaires en réponse au commentaire: Oui - c'était un is_snapshot = 1 [sauvegarde]}

is_snapshot

Veuillez lire la section is_snapshot dans mon réponse à la question tilisation d'une sauvegarde VSS tierce plus SQL natif sauvegarde

De ma réponse originale:

Si l'historique de sauvegarde de la base de données a l'indicateur is_snapshot Défini sur 1, Vous savez que cette sauvegarde a été effectuée à l'aide d'un logiciel tiers qui a déclenché le SQL Server Writer ( VSS Service for SQL Server) qui a permis au logiciel tiers de sauvegarder la base de données presque instantanément.

À partir de la documentation officielle sur ce que sont les sauvegardes de clichés:

La sauvegarde d'instantanés SQL Server est effectuée en coopération avec des fournisseurs de matériel ou de logiciels tiers, ou les deux. Ces fournisseurs utilisent des fonctionnalités SQL Server conçues à cet effet. La technologie de sauvegarde sous-jacente crée une copie instantanée des données en cours de sauvegarde. La copie instantanée est généralement réalisée en fractionnant un ensemble de disques en miroir ou en créant une copie d'un bloc de disques lors de son écriture. Cela préserve l'original. Au moment de la restauration, l'original est rendu disponible immédiatement et la synchronisation des disques sous-jacents se produit en arrière-plan. Il en résulte des opérations de restauration presque instantanées.

Référence: Sauvegardes de clichés (Microsoft Technet)

Une sauvegarde créée à l'aide de cette fonction peut également être restaurée presque instantanément.

Sommaire

Les sauvegardes tierces doivent être marquées comme is_snapshot = 1 Et is_copy_only = 1. Ces sauvegardes n'entreront pas en conflit avec les étapes/procédures de sauvegarde supplémentaires effectuées à l'aide des instructions natives SQL Server BACKUP DATABASE..., BACKUP DATABASE ... WITH DIFFERENTIAL.... Et BACKUP LOG.... Les sauvegardes de bases de données tierces ne font pas partie d'un jeu de sauvegarde existant.

J'espère que cette information est suffisante.

Md Haidar Ali Khan · Answer

Selon la documentation MSDN SAUVEGARDE DU JOURNAL DES TRANSACTIONS et SÉQUENCE DE RESTAURATION: Mythes et vérités Une séquence continue de T-Log les sauvegardes sont liées par un Log Chain, qui commence par une sauvegarde COMPLÈTE. Maintenant, sauf si nous exécutons quelque chose de manière explicite qui rompt la chaîne de journalisation (par exemple, en exécutant le journal BACKUP TRUNCATE_ONLY * ou en passant au modèle de récupération SIMPLE), la chaîne existante reste intacte. Avec la chaîne de journaux intacte, vous pouvez restaurer votre base de données à partir de n'importe quelle sauvegarde complète de la base de données dans le jeu de supports, suivie de toutes les T-Log sauvegardes jusqu'au point d'échec.

Et comme MSSQLTIPS documents ici Lors de la restauration d'une base de données, la séquence initiale de la base de données RESTAURER doit commencer à partir d'une base de données FULL sauvegarde. Une séquence de restauration de base de données ne peut pas commencer par une sauvegarde différentielle de fichiers ou une sauvegarde du journal des transactions. Lors de la restauration de bases de données, il existe quatre LSN importants: FirstLSN , LastLSN , CheckpointLSN et DatabaseBackupLSN . Ces valeurs peuvent être récupérées à partir d'un fichier de sauvegarde SQL Server à l'aide de la commande RESTORE HEADERONLY .

Par exemple

Dans la capture d'écran ci-dessus, je veux vous montrer l'en-tête "Sauvegarde complète" et également l'en-tête "Sauvegarde du journal des transactions". Si le type de sauvegarde est 1 , cela signifie qu'il s'agit d'une partie d'en-tête de la sauvegarde complète. Et s'il y a 2 cela signifie, qui est l'en-tête de sauvegarde du journal des transactions.

Dans cette capture d'écran, je veux d'abord vous montrer Restore Headeronly .. pour la sauvegarde complète, puis la sauvegarde du journal des transactions et à nouveau la sauvegarde complète de la même base de données.

Remarque: ici, j'ai mis en évidence une partie de la capture d'écran pour des raisons de sécurité.

Pour votre autre référence ici et ici

Scott Hodgin · Answer

Après avoir lu votre question, je ne suis pas convaincu que votre "chaîne de journaux" soit interrompue à cause de cette sauvegarde Appsure. En supposant que vous pouvez restaurer la sauvegarde FULL prise par APPSURE à la ligne 5 WITH NORECOVERY, vous devriez pouvoir restaurer votre DIFFERENTIAL sauvegarde prise à la ligne 6 sans aucun problème.

I croyez votre vraie question est:

Comment puis-je déterminer si "escroc" FULL des sauvegardes sans copie sont effectuées à mon insu.

Il peut y avoir des moyens plus sophistiqués de le déterminer, mais peut-être une simple requête pour vérifier que les sauvegardes non copiées sont stockées sur un emplacement auquel vous ne vous attendiez pas suffirait.

À partir de votre capture d'écran, il semble que vos sauvegardes normales soient stockées dans E:\SQLBackups. Il peut être suffisant pour vous d'exécuter une requête simple pour vérifier que les sauvegardes FULL non copiées sont stockées ailleurs.

SELECT s.database_name ,m.physical_device_name ,s.backup_start_date FROM msdb.dbo.backupset s INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id WHERE s.database_name = DB_NAME() -- Remove this line for all the database AND s.is_copy_only = 0 and physical_device_name not like 'E:\SQLBackup%' ORDER BY backup_start_date DESC