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 ..._lsn
Spalten (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_ONLY
Option 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 FULL
Sicherung zu analysieren, bevor diese durch (a) Sicherungsverfahren gelöscht wurde.
Deine Situation
In dem von Ihnen bereitgestellten Screenshot haben Sie eine FULL
Sicherung der Datenbank, die sich befindet, is_copy_only
und kurz nach einer FULL
Sicherung, die es nicht ist is_copy_only
. Was Sie jetzt nicht wissen:
Ist das zweite FULL
Nicht- is_copy_only
Backup ein Schnappschuss oder nicht?
Wenn Sie mein Skript von oben verwenden und die WHERE
Klausel so ändern , dass sie mit Ihrem Datenbanknamen übereinstimmt, stellen Sie möglicherweise fest, dass es sich bei dieser FULL
Sicherung is_copy_only
möglicherweise nicht nur um eine Sicherung handelt is_snapshot
.
Und das könnte eine neue Frage aufwerfen:
Wird der FULL
, is_snapshot
Datenbank - Backup meiner Datenbank die Protokollsicherungskette brechen?
Aber...
.... egal in welche Richtung dies geht, solange Sie über eine ununterbrochene Kette von FULL
und TLOG
Sicherungen verfügen , auf die Sie zugreifen können, können Sie Ihre Datenbank zu jedem Zeitpunkt wiederherstellen, selbst wenn Sie eine andere FULL
Sicherung dazwischen haben.
Sie können dies anhand der Ausgabe meines Skripts für Ihre Datenbank überprüfen, indem Sie sich die first_lsn
und last_lsn
-Nummern ansehen. Sie sollten übereinstimmen, auch wenn ein FULL
Backup umgangen wird .
Sei lieber sicher als traurig
Ich habe eine AdminDB2
Datenbank für eine meiner Instanzen. Ich habe ein TLOG
Backup erstellt, Daten geändert, ein FULL
Backup durchgeführt, Daten geändert, ein TLOG
Backup 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 TLOG
Sicherung oben, die vorherige FULL
(Zwischen-) Sicherung um 2018-04-25 17:28:48.000
, die vorherige TLOG
Sicherung um 2018-04-25 17:28:23.000
usw. sehen.
Um die AdminDB2
Datenbank auf den aktuellen Zeitpunkt zurückzusetzen, müsste ich die erste FULL
Sicherung von 2018-04-25 17:27:32.000
(da ich die Zwischensicherung gelöscht habe FULL
) zusammen mit allen TLOG
Sicherungen verwenden.
Probieren wir es aus.
- Löschen Sie die
FULL
Sicherungsdatei AdminDB2_FULL_20180425_172848.bak
auf meiner Festplatte (oder benennen Sie sie um), nur weil es die dazwischen liegende ist.
- Öffnen Sie die Wiederherstellungs-GUI in SSMS und fügen Sie hinzu.
- das
FULL
BackupAdminDB2_FULL_20180425_172732.bak
- alle
TLOG
Sicherungsdateien
- AdminDB2_TLOG_20180425_172807.trn
- AdminDB2_TLOG_20180425_172823.trn
- AdminDB2_TLOG_20180425_172908.trn
- Stellen Sie sicher, dass ich die Option eingestellt habe
Overwrite the existing database (WITH REPLACE)
- 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 FULL
Sicherung vor langer Zeit wiederherstellen und einfach alle TLOG
Sicherungen hinzufügen .
Jedoch...
... es ist schneller ein neueres zu haben FULL
, DIFF
und TLOG
Sicherungen 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 NUL
und 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_snapshot
gesetzt ist, 1
wissen 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 = 1
und 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.