Wie kann man feststellen, ob eine Sicherungsprotokollkette unterbrochen ist?

Ich hatte eine Situation, in der die nativen Sicherungen auf einem Server erstellt wurden.
Ich habe zufällig gesehen, msdbdass es ein Backup-Tool eines Drittanbieters ( AppAssure) gab, das auch VSS (Art) verwendete backup to virtual device.

In einem bestimmten Intervall führte die AppAssure (Sicherung wurde durchgeführt VIRTUAL DEVICE) eine COPY_ONLY backupund in einem anderen Intervall eine FULL backupUnterbrechung der Protokollkette durch.

Gibt es eine Möglichkeit ( T-SQL query) zu wissen, wann eine Sicherungsprotokollkette unterbrochen ist?

Hier ist ein Screenshot der Situation vom Februar.

Referenzlesung / Ähnliche Fragen und Antworten

Vielleicht möchten Sie meine Antwort überprüfen, die ich als Antwort auf die Frage gepostet habe: Werden VSS-Backups die Logchain brechen? (dba.stackexchange.com)

Die Erklärung in meiner Antwort verweist auch auf die Frage Wie kann ich eine SQL Server-Datenbank mit Windows Server Backup sichern? (serverfault.com), die auch von mir beantwortet wurde.

Transaktionsprotokollkette

Wenn eine TLOG-Sicherung (Transaction Log) durchgeführt wird, werden die Sicherungsinformationen in verschiedenen Tabellen in der msdb- Datenbank gespeichert . Die gespeicherten Informationen enthalten Informationen wie backup_type, logical_device_name, physical_device_name, is_copy_only, is_snapshot, und verschiedene ..._lsnSpalten (LSN = Protokollfolgenummer).

Mit dem folgenden Skript können Sie die Informationen zur Transaktionsprotokoll-Sicherungskette von Ihrer SQL Server-Instanz über die msdb-Datenbank abrufen:

/* ==================================================================
 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 

^{Achtung: Die where-Klausel wählt derzeit die AdventureWorks2012-Datenbank aus}

Unterbrochene Transaktionsprotokollkette

Die (Transaktions-) Protokollkette wird niemals unterbrochen, es sei denn, eine der folgenden Bedingungen ist erfüllt:

• Eine Transaktionsprotokoll-Sicherungsdatei wurde gelöscht
• Auf eine Transaktionsprotokoll-Sicherungsdatei kann nicht zugegriffen werden (irgendwo auf einem Sicherungsgerät; Sicherungslösung eines Drittanbieters)
• Die Datenbank befindet sich im SIMPLE-Wiederherstellungsmodell
• Mit dieser Option wurde eine Transaktionsprotokollsicherung durchgeführt TRUNCATE_ONLY
• Eine vollständige Datenbanksicherung wurde ohne die COPY_ONLYOption erstellt und dann von der Festplatte gelöscht, da die Entwickler nur eine schnelle Sicherung benötigten, um eine Situation in der Datenbank und Ihrer FULLSicherung zu analysieren, bevor diese durch (a) Sicherungsverfahren gelöscht wurde.

Deine Situation

In dem von Ihnen bereitgestellten Screenshot haben Sie eine FULLSicherung der Datenbank, die sich befindet, is_copy_onlyund kurz nach einer FULLSicherung, die es nicht ist is_copy_only . Was Sie jetzt nicht wissen:

Ist das zweite FULLNicht- is_copy_onlyBackup ein Schnappschuss oder nicht?

Wenn Sie mein Skript von oben verwenden und die WHEREKlausel so ändern , dass sie mit Ihrem Datenbanknamen übereinstimmt, stellen Sie möglicherweise fest, dass es sich bei dieser FULLSicherung is_copy_onlymöglicherweise nicht nur um eine Sicherung handelt is_snapshot.

Und das könnte eine neue Frage aufwerfen:

Wird der FULL, is_snapshotDatenbank - Backup meiner Datenbank die Protokollsicherungskette brechen?

Aber...

.... egal in welche Richtung dies geht, solange Sie über eine ununterbrochene Kette von FULLund TLOGSicherungen verfügen , auf die Sie zugreifen können, können Sie Ihre Datenbank zu jedem Zeitpunkt wiederherstellen, selbst wenn Sie eine andere FULLSicherung dazwischen haben.

Sie können dies anhand der Ausgabe meines Skripts für Ihre Datenbank überprüfen, indem Sie sich die first_lsnund last_lsn-Nummern ansehen. Sie sollten übereinstimmen, auch wenn ein FULLBackup umgangen wird .

Sei lieber sicher als traurig

Ich habe eine AdminDB2Datenbank für eine meiner Instanzen. Ich habe ein TLOGBackup erstellt, Daten geändert, ein FULLBackup durchgeführt, Daten geändert, ein TLOGBackup durchgeführt, ....

Werfen wir einen Blick auf meine Sicherungshistorie von 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

_{Die Reihenfolge ist absteigend}

Sie können die letzte TLOGSicherung oben, die vorherige FULL(Zwischen-) Sicherung um 2018-04-25 17:28:48.000, die vorherige TLOGSicherung um 2018-04-25 17:28:23.000usw. sehen.

Um die AdminDB2Datenbank auf den aktuellen Zeitpunkt zurückzusetzen, müsste ich die erste FULLSicherung von 2018-04-25 17:27:32.000(da ich die Zwischensicherung gelöscht habe FULL) zusammen mit allen TLOGSicherungen verwenden.

Probieren wir es aus.

1. Löschen Sie die FULLSicherungsdatei AdminDB2_FULL_20180425_172848.bakauf meiner Festplatte (oder benennen Sie sie um), nur weil es die dazwischen liegende ist.
2. Öffnen Sie die Wiederherstellungs-GUI in SSMS und fügen Sie hinzu.
   • das FULLBackupAdminDB2_FULL_20180425_172732.bak
   • alle TLOGSicherungsdateien
     • AdminDB2_TLOG_20180425_172807.trn
     • AdminDB2_TLOG_20180425_172823.trn
     • AdminDB2_TLOG_20180425_172908.trn
3. Stellen Sie sicher, dass ich die Option eingestellt habe Overwrite the existing database (WITH REPLACE)
4. Führen Sie die Wiederherstellung durch (oder schreiben Sie die Anweisung in ein Abfragefenster).

Skript

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

Ausgabe

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).

... und die Datenbank ist wieder ONLINE.

Zusammenfassung

Die Sicherungskette wird nur unterbrochen, wenn Sie die TLOG-Sicherungen dazwischen verlieren. Ansonsten können Sie eine Datenbank aus einer FULLSicherung vor langer Zeit wiederherstellen und einfach alle TLOGSicherungen hinzufügen .

Jedoch...

... es ist schneller ein neueres zu haben FULL, DIFFund TLOGSicherungen praktisch.

_{Zusätzliche Informationen als Antwort auf einen Kommentar: Die Transaktionsprotokollsicherung wurde mit der Option TRUNCATE_ONLY durchgeführt. Wenn dies geschieht, gibt es eine Möglichkeit, dies durch eine T-SQL-Abfrage zu erkennen}

Sichern des Transaktionsprotokolls nur mit Truncate_only

In früheren Versionen von SQL Server vor SQL Server 2008 konnten Sie die folgende Anweisung verwenden:

 BACKUP LOG [AdminDB2] WITH TRUNCATE_ONLY

Dies ist veraltet und wird nicht mehr unterstützt. Sie erhalten eine Fehlermeldung wie die folgende:

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

Die neue Methode ist das Sichern auf der Festplatte NULund wird mit dem folgenden Befehl ausgeführt:

BACKUP LOG [AdminDB2] TO DISK='NUL'

Dies gibt die folgenden Informationen zurück:

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).

Advisory
Do NICHT verwenden , um dies in der Produktion. Während dieser TLOG-Sicherung können Sie nicht mehr zu einem bestimmten Zeitpunkt wiederherstellen.

Referenz: BACKUP (Transact-SQL) (Microsoft Docs)

In Ihrem Sicherungsverlauf wird Folgendes angezeigt:

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

Die Informationen für logical_device_name( ldev) und physical_device_name( pdev) enthalten beide den Wert NULL. Dies ist ein Zeichen dafür, dass a BACKUP LOG ...mit a TRUNCATE_ONLY(new :) ausgeführt wurde TO DISK='NUL'. Sie haben die Möglichkeit verloren, über diesen Punkt hinaus mithilfe von Transaktionsprotokollsicherungen wiederherzustellen.

_{Zusätzliche Informationen als Antwort auf den Kommentar: Ja - dies war ein is_snapshot = 1 [Backup]}

is_snapshot

Bitte lesen Sie den Abschnitt is_snapshot in meiner Antwort auf die Frage Verwendung der VSS-Sicherung eines Drittanbieters plus native SQL-Sicherung

Aus meiner ursprünglichen Antwort:

Wenn für das Datenbanksicherungsprotokoll das Flag is_snapshotgesetzt ist, 1wissen Sie, dass diese Sicherung mit einer Software eines Drittanbieters durchgeführt wurde, die den SQL Server Writer (VSS-Dienst für SQL Server) ausgelöst hat, mit dem die Software des Drittanbieters die Datenbank fast sofort sichern konnte .

Aus der offiziellen Dokumentation zu Snapshot-Backups:

Die Sicherung von SQL Server-Snapshots wird in Zusammenarbeit mit Hardware- oder Softwareanbietern von Drittanbietern oder beiden durchgeführt. Diese Anbieter verwenden SQL Server-Funktionen, die für diesen Zweck entwickelt wurden. Die zugrunde liegende Sicherungstechnologie erstellt eine sofortige Kopie der Daten, die gesichert werden. Das sofortige Kopieren wird normalerweise durch Aufteilen eines gespiegelten Satzes von Platten oder durch Erstellen einer Kopie eines Plattenblocks beim Schreiben erreicht. Dadurch bleibt das Original erhalten. Zur Wiederherstellungszeit wird das Original sofort verfügbar gemacht und die Synchronisierung der zugrunde liegenden Festplatten erfolgt im Hintergrund. Dies führt zu fast sofortigen Wiederherstellungsvorgängen.

Referenz: Snapshot-Backups (Microsoft Technet)

Ein mit dieser Funktion erstelltes Backup kann auch fast sofort wiederhergestellt werden.

Zusammenfassung

Die Sicherungen von Drittanbietern sollten als is_snapshot = 1und gekennzeichnet sein is_copy_only = 1. Diese Sicherungen werden nicht in Konflikt mit zusätzlichen Sicherungsschritte / Verfahren unter Verwendung von nativen SQL Server BACKUP DATABASE..., BACKUP DATABASE ... WITH DIFFERENTIAL....und BACKUP LOG...Anweisungen. Die Datenbanksicherungen von Drittanbietern sind nicht Teil eines vorhandenen Sicherungssatzes.

Ich hoffe diese Information ist ausreichend.

Gemäß MSDN-Dokumentation TRANSACTION LOG BACKUP und RESTORE SEQUENCE: Myths & Truths Eine fortlaufende Folge von T-LogBackups ist durch a verbunden Log Chain, das mit einer vollständigen Sicherung beginnt. Sofern wir nicht explizit etwas ausführen, das die Protokollkette unterbricht (z. B. das BACKUP-Protokoll TRUNCATE_ONLY * ausführen oder zum SIMPLE-Wiederherstellungsmodell wechseln), bleibt die vorhandene Kette intakt. Wenn die Protokollkette intakt ist, können Sie Ihre Datenbank aus jeder vollständigen Datenbanksicherung im Mediensatz wiederherstellen, gefolgt von allen nachfolgenden T-LogSicherungen bis zum Fehlerpunkt.

Und als MSSQLTIPSDokumente hier Beim Wiederherstellen einer Datenbank muss die anfängliche Datenbank- RESTORE- Sequenz von einer vollständigen Datenbanksicherung ausgehen. Eine Datenbank-RESTORE-Sequenz kann nicht mit einer differenziellen Dateisicherung oder einer Transaktionsprotokollsicherung beginnen. Bei der Wiederherstellung von Datenbanken gibt es vier wichtige LSNs: FirstLSN, LastLSN, CheckpointLSNund DatabaseBackupLSN. Diese Werte können mit dem Befehl RESTORE HEADERONLY aus einer SQL Server-Sicherungsdatei abgerufen werden .

Zum Beispiel

Im obigen Screenshot möchte ich Ihnen den Header "Full Backup" und den Header "Transaction Log Backup" anzeigen. Wenn der Sicherungstyp 1 ist , bedeutet dies, dass es sich um einen Header-Teil der vollständigen Sicherung handelt. Und wenn es 2 gibt , bedeutet das, dass es sich um einen Transaktionsprotokoll-Sicherungsheader handelt.

In diesem Screenshot möchte ich Ihnen zuerst zeigen Restore Headeronly.. für die vollständige Sicherung, dann für die Transaktionsprotokollsicherung und erneut für die vollständige Sicherung derselben Datenbank.

Hinweis: Hier habe ich aus Sicherheitsgründen einen Teil des Screenshots hervorgehoben.

Für Ihren weiteren Hinweis hier und hier

Nachdem ich Ihre Frage gelesen habe, bin ich nicht davon überzeugt, dass Ihre "Protokollkette" aufgrund dieser AppsureSicherung unterbrochen ist . Angenommen , können Sie die Wiederherstellung FULLSicherung durch genommen APPSUREan der Linie 5 WITH NORECOVERY, sollten Sie in der Lage sein , Ihre wiederherstellen DIFFERENTIALBackup in Zeile 6 ohne Probleme genommen.

Ich glaube, Ihre eigentliche Frage lautet:

Wie kann ich feststellen , ob ‚ Rogue ‘ FULLnicht-copyonly Backups ohne mein Wissen getroffen werden.

Es könnte sein , anspruchsvollere Möglichkeiten , dies zu bestimmen, aber vielleicht eine einfache Abfrage für nicht-copyonly Backups zu überprüfen auf einem Ort gespeichert werden Sie nicht erwartet haben würde genügen.

Aus Ihrem Screenshot geht hervor, dass Ihre normalen Backups unter gespeichert werden E:\SQLBackups. Es kann ausreichend sein, eine einfache Abfrage auszuführen, um zu überprüfen, ob FULLnicht kopierfähige Sicherungen an einem anderen Ort gespeichert sind.

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