Benutzer mit den meisten Antworten
bis wohin sichert Transactionlog

Frage
-
Hallo Allerseits,
mir ist an einer Stelle nicht klar bis wohin das Transactionlog sichert und habe auch im Netz nichts Passendes gefunden - da hoffe ich hier auf euch ;o)
Ich mache um 22.00 eine Vollsicherung der Datenbank und dann alle 15 Minuten das Transactionlog. Die Transactionsicherung sichert alle Log-Daten bis zur letzten Log-Sicherung - soweit klar.
Nach dem Prinzip sicher ich dann um 08:00 das Transactionlog und im Normalfalle würde dann die Sicherung um 8:15 bis 8:00 zurückgehen. Was passiert aber, wenn ich um 8:05 ein Vollsicherung starte? wird dann trotzdem bei der logsicherung bis 08:00 zurückgegangen oder dann nur bis 8:05???
Hintergrund der Frage:
Ich sichere die log-Sicherungen per Tool permanent weg sowie nächtlich die Vollsicherung - sollte ich aber tagsüber ein Backup starten (z. B. vor wichtigen Eingriffen in die DB) wird dies nicht direkt weggesichert. Wenn mir aber just an dem Tag der Server abraucht - kann ich dann noch die Daten wiederherstellen oder schlägt es fehl da laut oigen Beispiel eine Log-Datei nicht vollständig ist?
Hoffe ich konnte mich halbwegs verständlich ausdrücken ;o)Gruß
Bernd
Antworten
-
...
) eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.
2) Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY
...
Das ist leider beides falsch (1) und (2)
1) Transaktionsprotokoll-Backups setzen immer am letzten Transaktionsprotokoll-Backup an. Das kann man an den Log-Sequence-Nummern erkennen.
Vermutlich ist der Umstand, dass man eine Wiederherstellung/ein Restore immer mit einem vollständigen Backup starten muss, der Grund für das Missverständnis.
2) Da ein Full/Vollständiges-Backup keinerlei Auswirkungen auf die Log-Kette hat, hat auch ein mit "COPY_ONLY" erzeugtes Full-Backup keinerlei Effekt in diesem Szenario.
Full-Backups mit Copy_Only benötigt man nur, wenn man mit differentiellen Backups arbeitet, da sie die Differential Bitmaps NICHT zurücksetzen.
LSNs im Transaktionsprotokoll (Log Sequence Numbers) bleiben davon völlig unbeeindruckt. Das Backup selber wird lediglich EBENFALLS protokolliert. Wäre das anders, würde ja jedes Full Backup die Log-Kette unterbrechen und damit alle Log-Backups davor nutzlos machen, sprich bei einem Problem mit dem letzten Backup würde man automatisch Daten verlieren.
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com- Bearbeitet Andreas.WolterMicrosoft employee Mittwoch, 16. Dezember 2015 20:51 Hervorhebungen
- Als Antwort vorgeschlagen Benjamin.Hoch Mittwoch, 16. Dezember 2015 21:15
- Als Antwort markiert Berni210 Montag, 4. Januar 2016 14:05
Alle Antworten
-
Hallo Bernd,
eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.
Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY
Olaf Helper
[ Blog] [ Xing] [ MVP]- Bearbeitet Olaf HelperMVP Mittwoch, 16. Dezember 2015 09:40
- Als Antwort vorgeschlagen Uwe RickenMVP Mittwoch, 16. Dezember 2015 11:19
- Nicht als Antwort vorgeschlagen Christoph MuthmannEditor Donnerstag, 17. Dezember 2015 07:21
-
Hallo Bernd,
ergänzend zu Olafs Antwort, schau Dir mal an:
Anwenden von Transaktionsprotokollsicherungen (SQL Server)
Gruß Elmar
-
Hallo,
Die Transaktionlog Sicherung um 8:15 beinhaltet auch die Logs zwischen 8:00 und 8:05. Wenn es anders wäre würde man keine Point-in-Time Rücksicherung für die Daten dieser 5 Minuten machen können.
Es stimmt aber dass alle Transaktionen ab 8:05 auf der neuen Vollsicherung basieren.
Man kann es ganz leicht prüfen wenn man eine Sicherung vom Stand 8:03 wiederherstellen will, hierfür braucht man auch die LOG Sicherung von 8:15.
Gruß Benjamin
Benjamin Hoch
MCSE: Data Platform,
MCSA: Windows Server 2012,
- Bearbeitet Benjamin.Hoch Mittwoch, 16. Dezember 2015 19:44
-
Hier mal ein kurzes Beispielskript
/* Anlegen einer Testdatenbank und einer Tabelle */ CREATE DATABASE [logdemo] ALTER DATABASE [logdemo] SET RECOVERY FULL GO USE [logdemo] GO create table demo ( id int identity , c1 char(1000) default 'a') BACKUP DATABASE [logdemo] TO DISK = N'C:\Temp\01_logdemo.bak' WITH NOFORMAT, NOINIT, NAME = N'logdemo-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO --Einfügen von Datensätzen um Einträge im Logfile zu erzeugen zum Vergleich -- Log File Sicherung ca. 4,5 MB Groß insert into demo values (default); go 1000 BACKUP LOG [logdemo] TO DISK = N'C:\temp\02_logdemo.trn' WITH NOFORMAT, NOINIT, NAME = N'logdemo-Log Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO -- Log File Sicherung ca. 4,5 MB Groß -- Ende Vorbereitung insert into demo values (default); go 1000 -- Durchführung einer Vollsicherung nach dem Insert BACKUP DATABASE [logdemo] TO DISK = N'C:\Temp\03_logdemo.bak' WITH NOFORMAT, NOINIT, NAME = N'logdemo-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO -- jetzt müsste das Log leer sein da nach der Vollsicherung keine neuen Daten hinzugefügt wurden BACKUP LOG [logdemo] TO DISK = N'C:\temp\04_logdemo.trn' WITH NOFORMAT, NOINIT, NAME = N'logdemo-Log Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO /* Tatsächlich hat die Vollsicherung keine auswirkungen auf den Inhalt des LOGs. Erst durch die LOG Sicherung werden die Insert Daten von vor dem Fullbackup aus dem LOG gesichert.
Benjamin Hoch
MCSE: Data Platform,
MCSA: Windows Server 2012, -
...
) eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.
2) Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY
...
Das ist leider beides falsch (1) und (2)
1) Transaktionsprotokoll-Backups setzen immer am letzten Transaktionsprotokoll-Backup an. Das kann man an den Log-Sequence-Nummern erkennen.
Vermutlich ist der Umstand, dass man eine Wiederherstellung/ein Restore immer mit einem vollständigen Backup starten muss, der Grund für das Missverständnis.
2) Da ein Full/Vollständiges-Backup keinerlei Auswirkungen auf die Log-Kette hat, hat auch ein mit "COPY_ONLY" erzeugtes Full-Backup keinerlei Effekt in diesem Szenario.
Full-Backups mit Copy_Only benötigt man nur, wenn man mit differentiellen Backups arbeitet, da sie die Differential Bitmaps NICHT zurücksetzen.
LSNs im Transaktionsprotokoll (Log Sequence Numbers) bleiben davon völlig unbeeindruckt. Das Backup selber wird lediglich EBENFALLS protokolliert. Wäre das anders, würde ja jedes Full Backup die Log-Kette unterbrechen und damit alle Log-Backups davor nutzlos machen, sprich bei einem Problem mit dem letzten Backup würde man automatisch Daten verlieren.
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com- Bearbeitet Andreas.WolterMicrosoft employee Mittwoch, 16. Dezember 2015 20:51 Hervorhebungen
- Als Antwort vorgeschlagen Benjamin.Hoch Mittwoch, 16. Dezember 2015 21:15
- Als Antwort markiert Berni210 Montag, 4. Januar 2016 14:05
-
Hi,
Danke erstmal für die ganzen Antworten - hatte auch schon selbst bei MSDN gesucht, aber genau den Artikel mit dem Zeitplan (siehe Elmar) nicht gefunden oder übersehen.
Der zeigt ja auch das Andreas Recht hat und hat für mich den Vorteil, daß ich mit solch "Zwischenbackups" nichts kaputt machen kann ;o)
Differntielle Backups sind für mich aussen vor - habe bis heute nicht wirklich den Sinn verstanden diese zu benutzen und ich beschäftige mich nicht mit Dingen die für mich Quatsch sind ;o))
Gruß
Bernd
Bernd Winnemöller
-
Hallo Bernd,
noch ein kurzes Wort zu den differentiellen Backups.
Beispiel:
Datenbank mit 1 TB
Änderung am Tag 10 GBVollsicherung wäre 1 TB
Differentielle Sicherung am Tag 1 10 GB bis hin zu Tag 6 60 GB (Aber nur, wenn andere Pages geändert wurden, als an den Vortagen. Also ist eher ein Volumen < 60 GB am Tag 6 zu erwarten.)
Tag 7 ist wieder Vollsicherung, obwohl es durchaus Sinn machen könnte, bis zum Tag 100 (oder länger) zu warten.Ich denke, der Sinn wird dann schon klar, oder? Sowohl die Dauer/Last, als auch das Volumen (auf Platte) oder die Menge, die durchs Netzwerk geht ist deutlich kleiner.
Einen schönen Tag noch,
Christoph
--
Data Platform MVP - http://www.insidesql.org/blogs/cmu -
Moin Christoph,
nicht wirklich klar ;o))
Bei deinem Beispiel habe ich in der Woche insgesamt 210 GB zu sichern an differentiellen Sicherungen. Wenn ich stattdessen die Transactionlogs sichere habe ich 60GB zu sichern und am Ende das gleiche Ergebnis.
Einzig mir bekannte Argument ist, daß ich halt alle Transactionlogs benötige zur Widerherstellung. Dies zählt für mich aber eigentlich nur bei Bandsicherungen....
Gruß
Bernd
Bernd Winnemöller
-
Hallo Bernd
Die Differenz Sicherungen werden um beim Beispiel von Christoph zu bleiben in den seltensten Fällen so groß werden. Es ist deutlich schneller beim Restore das letzte Vollbackup, dann das letzte Diff Backup und von da an alle Logs wiederherzustellen.
Durch das DIFF Backup spart man sich die Wiederherstellung aller LOG Dateien (und damit aller Operationen im LOG) von dem Zeitpunkt des Voll Backup bis zum letzten Diff Backup.
Theoretisch kann man nach jedem DIFF Backup alle vorhergehenden DIFF Backup Dateien verwerfen da sie für den Restore nicht mehr nötig sind. (Würde ich aber nicht machen)
Das Differenz Backup macht gerade bei sehr großen Datenbank mit vielen Änderungen Sinn.
Gruß Benjamin
Benjamin Hoch
MCSE: Data Platform,
MCSA: Windows Server 2012, -
...
Bei deinem Beispiel habe ich in der Woche insgesamt 210 GB zu sichern an differentiellen Sicherungen. Wenn ich stattdessen die Transactionlogs sichere habe ich 60GB zu sichern und am Ende das gleiche Ergebnis.
Einzig mir bekannte Argument ist, daß ich halt alle Transactionlogs benötige zur Widerherstellung. Dies zählt für mich aber eigentlich nur bei Bandsicherungen....
...Das ist schon nicht ganz falsch.
Aber: Wer wenn man, um eine RPO von max 15 Minuten zu erreichen jeweils 15-minütige Log-backups macht, hat man nach 6 Tagen über 250 Logfiles. Allein die Datei-Validierung dauert ja auch. Insofern ist es dann idR performanter lediglich eine 60GB-Datei + eine Handvoll Logs wiederherzustellen anstelle 288 Log-Files - auch bei 15.000 RPM Backup-Disks.
Damit man also auch seine RTO der SLA erreicht, kann das sinnvoll sein ;-)
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com -
Hallo Bernd,
vielleicht noch eine kleine Bemerkung am Rande. Nicht die reine Größe einer Datenbank ist der entscheidende Punkt bei der Verwendung von Diff Backups. Hier ist der entscheidende Faktor die Anzahl der Transaktionen für die ein Rollforward und dann ein Rollback während der LOG Rücksicherung durchgeführt werden muss.
Zwar kann man durchaus annehmen dass eine Große Datenbank auch mehr Transaktionen hat aber dies trifft nicht grundsätzlich zu. Nehmen wir eine Datenbank (z.B. 20 GB) in der sehr, sehr viele Insert, Update und Delete Operationen laufen plus Index Rebuild und Reorg, ohne an der Menge der Daten viel zu ändern. Hier brauche man im schlechtesten Fall (kurz vor der wöchentlichen Vollsicherung) bestimmt mehrere Stunden für dem Restore. Mit dem Diff schafft man es in unter einer Stunde.
Benjamin Hoch
MCSE: Data Platform,
MCSA: Windows Server 2012, -
Und um noch eines draufzusetzen:
wenn man eine RTO von 15 Minuten garantieren möchte, MUSS man entsprechend viele Log-Backups einplanen.
Und dann dauert es beim Wiederherstellen auch, wenn sie praktisch leer sind.
Da hilft dann auch ein Differentielles Backup. - In dem Fall mag aber auch ein Full Backup alternativ funktionieren, wenn die Datenbank wirklich so klein ist.
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com