(Ola Hallengren) Löschen von Protokollsicherungen, die älter als die letzte vollständige Sicherung sind

7

Wenn ich das Sicherungsskript von Ola Hallengren auf meinen Servern bereitstelle, setze ich den @CleanupTimeParameter für Protokollsicherungen immer auf Null. Auf diese Weise wird bei jeder Ausführung des Protokollsicherungsjobs nach Protokollsicherungsdateien gesucht, die älter als die letzte vollständige Sicherung sind, und diese werden gelöscht. Dies gilt jedoch auch für vollständige COPY_ONLYBackups! Der Protokollsicherungsjob sollte nur nach der letzten nicht COPY_ONLYvollständigen Sicherung suchen , um alte Protokollsicherungsdateien zu löschen.

Ich frage mich nur, ob ich der einzige bin, der darauf gestoßen ist, oder ob das, was ich vorschlage, Sinn macht. Wenn ich am mittleren Tag eine vollständige Nur-Kopie-Sicherung durchführen muss, um eine TEST-Datenbank mit IDK zu aktualisieren, sollte diese Nur-Kopie-Sicherung die reguläre tägliche Sicherungssequenz nicht beeinflussen. Lassen Sie mich bitte Ihre Gedanken wissen.

sql-server sql-server-2012 backup maintenance ola-hallengren Guillermo Garcia
quelle
2
Wie lange zwischen vollständigen Sicherungen? Das klingt für mich etwas riskant. Wenn Ihr letzter voller Rücken nicht gut ist, müssen Sie den vorherigen vollen Rücken wiederherstellen und können nicht vorwärts rollen. Ich würde eine fortlaufende Anzahl von Tagen behalten.
Sir Swears-a-lot
1
Diese Sicherungen werden auf einer Netzwerkfreigabe gespeichert, die alle 4 Stunden gesichert wird, sodass jeden Tag auch alle Sicherungsdateien gesichert werden, falls einige Tage, Wochen oder Monate erforderlich sind. Ich habe COPY_ONLY-Backups immer als "unsichtbar" für das reguläre Backup-Schema angesehen, aber da Olas Backup-Skript sie als reguläres FULL-Backup zählt, sind sie nicht mehr so ​​unsichtbar.
Guillermo Garcia
Was ist der Vorteil, wenn Sie alles vor dem letzten vollständigen Löschen löschen, anstatt eine Woche (wenn Sie wöchentlich voll sind) oder 24 Stunden (wenn Sie täglich voll sind) von Protokollsicherungen zu behalten? Sie benötigen immer noch genügend Speicherplatz auf Ihrer Sicherungsfreigabe, um einen vollständigen Sicherungszyklus zu ermöglichen - warum nicht einfach halten?
Dan
1
@Dan - Die alten Protokollsicherungen werden erst gelöscht, nachdem eine neue vollständige Sicherung abgeschlossen wurde. Beachten Sie, dass sie nur aus der Netzwerkfreigabe gelöscht werden, aber bereits durch die auf der Freigabe ausgeführte Sicherung gesichert wurden. Sagen wir einfach, dass ich in der Freigabe nur die Sicherungen des aktuellen Tages behalte (um Mitternacht voll und jede Protokollsicherung bis zur nächsten voll). Ich bin mir nicht sicher, was daran kompliziert ist. Ich will auch kein $$ sein, aber das ist nicht der Punkt meiner Frage, es sei denn, ich habe etwas aus Ihrem Kommentar verpasst ...
Guillermo Garcia
Es ist nicht so sehr, dass Ihr Plan zu kompliziert ist, sondern ich sehe nicht, welchen Nutzen er Ihnen bringt. Ihre Freigabe muss immer über genügend freien Speicherplatz verfügen, um 24-Stunden-Protokollsicherungen zu speichern. Was schadet es also, wenn Sie nur einen @ CleanupTime-Parameter von 24 verwenden?
Dan

Antworten:

5

Teil II von II (musste meine Antwort teilen)

Mach es besser

In Anbetracht Ihres von Ihrem Unternehmen definierten RPO und RTO möchten Sie jetzt möglicherweise den Parameter von @CleanupTimeauf etwas Höheres als ändern 0. Warum? Da der Wert 0funktioniert nur zusammen mit dem eingebauten in Fail-Safe - Mechanismus.

Verwenden wir die folgende Zeitleiste:

  • 08:00 SICHERUNGSPROTOKOLL
  • 09:00 SICHERUNGSPROTOKOLL
  • 10:00 SICHERUNGSPROTOKOLL
  • ...
  • 20:00 SICHERUNGSDATENBANK
  • 21:00 SICHERUNGSPROTOKOLL
  • ...

Zu einem bestimmten Zeitpunkt werden Ihre Transaktionsprotokollsicherungen (und vollständigen Sicherungen?) Auf ein Netzwerklaufwerk kopiert und von dort mithilfe einer Sicherungslösung gesichert, möglicherweise kombiniert mit einer Art Band- und / oder Festplattenspeicher. Sobald die erste BACKUP LOG ...nach der letzten auftritt, sind BACKUP DATABASE ...Ihre vorherigen BACKUP LOG ...Dateien verschwunden ...

Fragen, die Sie sich stellen sollten

  • Was passiert, wenn Ihre Netzwerksicherung fehlschlägt?
  • Wann erfolgt diese (Band-) Sicherung? Garantiert?
  • Wann erfolgt die vollständige Datenbanksicherung?
  • Was möchten Sie wiederherstellen können?
  • Welche RTO hast du?
  • Welches RPO benötigt Ihr Unternehmen?

Wenn Sie sich die obigen Fragen ansehen, sollten Sie eine andere Bereinigungszeit verwenden (z. B. @CleanupTime=48), um Transaktionsprotokollsicherungen im Wert von zusätzlichen Stunden auf den Festplatten Ihres Datenbankservers zu speichern.

Leistungen

  • Sie verlassen sich nicht mehr auf den ausfallsicheren Mechanismus von Ola
  • Ihre Daten befinden sich immer noch auf der Festplatte, auch wenn Sie ein COPY_ONLYBackup erstellen
  • Ihre Daten befinden sich immer noch auf der Festplatte, auch wenn das Netzwerk ausfällt und ...
    • ... Sie erstellen eine BACKUP DATABASE ...
    • ... ein COPY_ONLYBackup

Aufbau eines soliden Fundaments

Zu jedem Zeitpunkt wird etwas fehlschlagen. Sie müssen sicherstellen, dass Sie eventuelle Fehler auf der ganzen Linie berücksichtigen können, und den Stakeholdern dennoch garantieren, dass Ihre Lösung 99, .....% narrensicher ist.

Wie ich es mache

Arbeiten mit Ola-Lösung ist eine absolute Brise, WENN Sie einen oder zwei Gedanken zu machen , wie Sie wollen eine Datenbank erholen und auf der Grundlage Ihrer Unternehmen RPO und RTO.

Meine persönliche Implementierung besteht darin, die folgenden Zeitpläne / Aufbewahrungsrichtlinien zu haben:

Produktionssysteme

  • TLog sichern
    • Hourly @ xx: 05 (Nicht-SAP-Systeme)
    • Viertelstündlich @ xx: 10, xx: 25, xx: 40, xx: 55 (SAP-Systeme)
    • Aufbewahrung: 48 Stunden
  • Tägliche differenzielle Sicherung
    • Montag - Samstag um 20:00 Uhr (Nicht-SAP-Systeme)
    • Montag - Samstag um 22:00 Uhr (SAP-Systeme)
    • Aufbewahrung: 168 Stunden
  • Wöchentliche vollständige Sicherung
    • Sonntag um 20:00 Uhr (Nicht-SAP-Systeme)
    • Sonntag um 22:00 Uhr (SAP-Systeme)
    • Aufbewahrung: 336 Stunden

Testsysteme

Das Testsystem wird während der Produktionsstunden gesichert. Dies kann 10:00 Uhr morgens oder 14:00 Uhr nachmittags für vollständige und xx: 15 für die Transaktionsprotokollsicherungen sein.

Warum mache ich das so?

... oder meine Gedanken hinter diesen Entscheidungen ...

Durch die Verteilung der Sicherungszeiten auf verschiedene Steckplätze verteile ich die Festplatten-E / A gleichmäßig auf den Speichersystemen. Keine Zusammenfassung massiver E / A auf der Festplatte während der vollen Stunden (FULL) oder vierteljährlichen Stunden (TLOG).

Ich unterscheide aufgrund der Größe der Datenbanken zwischen SAP und Nicht-SAP.

Testsysteme dürfen den Speicher tagsüber überladen. Keine Auswirkungen auf die Hochleistung.

Die DIFF- und FULL-Sicherungen werden vor dem Start der Bandsicherungen durchgeführt und normalerweise vor dem Start der Bandsicherungen beendet.

Die Aufbewahrungsrichtlinien ermöglichen es mir, die vom Unternehmen festgelegten RTO und RPO zu erreichen, selbst wenn die (Band-) Sicherungslösung einen Tag lang nicht verfügbar ist.

Backups funktionieren weiterhin und sind mit RTO und RPO kompatibel, selbst wenn das Netzwerk (als Ganzes oder nur teilweise) einen Tag lang nicht verfügbar ist.

Dein Denkprozess

Ihre @CleanupTimeEinstellung beruhte wahrscheinlich auf einem falschen Verständnis von Olas Skript.

John aka hot2use
quelle
1
Ich habe das Gefühl, Sie sollten mir diese Antwort in Rechnung stellen. Vielen Dank für die detaillierte Aufschlüsselung. Sie haben alle Punkte angesprochen, die langsam in meinem Kopf auftauchten, nachdem ich auf dieses Problem gestoßen war. Insbesondere die Tatsache, dass die alle vier Stunden auf der Sicherungsnetzwerkfreigabe ausgeführte Sicherung möglicherweise nicht den letzten Stapel von TLOG-Sicherungen abfängt, bevor das nächste FULL + 1TLOG abgeschlossen ist. Ich wusste auch nicht, dass Sie eine vollständige COPY_ONLY-Sicherung mit nachfolgenden TLOG-Sicherungen verwenden können, um eine Wiederherstellung zu einem bestimmten Zeitpunkt durchzuführen. Überdenken Sie hier auf jeden Fall meine Backup-Strategie. Großartige Antwort Kumpel. Prost.
Guillermo Garcia
Nein, ich helfe nur jemandem in einer ähnlichen Situation wie ich selbst. Es braucht Zeit, um die Notwendigkeit vernünftiger RPO- und RTO-Anforderungen zu verstehen, die vom Management genehmigt wurden. Wenn Sie erkennen, dass eine Datenbank ein Zahnrad in einem großen Motor (Server- / Anwendungsumgebung) ist, können Sie außerdem definieren, was Sie als DBA tun können, um die RTO- und RPO-Anforderungen zu erfüllen. Geben Sie Ihr Bestes, damit niemand etwas gegen Sie unternehmen kann, und teilen Sie dem Management mit, was Sie entworfen haben (Dokumentation).
John aka hot2use
Diese Antwort sollte ein Blog-Beitrag sein :) Die nützlichste Informationsquelle zu dem Thema, das ich bisher gefunden habe.
Wouter
Ich freue mich über Ihr positives Feedback. Nun, es ist in der Tat ein Blog-Beitrag, nur dass ich beschlossen habe, ihn hier für die Community zu veröffentlichen. Genießen.
John aka hot2use
3

Teil I von II (musste meine Antwort teilen)

Hier gibt es ein oder zwei Dinge, über die man nachdenken muss. Meiner Meinung nach haben Sie möglicherweise eine Abkürzung im Denkprozess gewählt. Ich werde es erklären, während ich diese Annahme mache ...

Vielleicht möchten Sie einen kurzen Blick auf meine akzeptierte Antwort hier werfen , die in Bezug auf die Frage " Bedarfsvorschlag zur Sicherungsstrategie [geschlossen]" veröffentlicht wurde , um Ihnen einige Ideen zu RTO und RPO zu geben.

Warum? Weil das Einstellen @CleanupTime=0eine schlechte Idee sein könnte ...

Beantworten Sie zuerst Ihre Frage.

Ist es ein Fehler in Olas Skript? - Nein. Ola hat sein Skript so konzipiert, dass es nach der letzten BACKUP DATABASE...(vollständigen Sicherung) sucht und dann die Transaktionsprotokollsicherungen ( BACKUP LOG ...) löscht, die vor dieser Sicherung durchgeführt wurden, und nur dann, wenn die @CleanupTimeniedrigere als bei der vollständigen Sicherung ist.

Dies ist ein ausfallsicherer Mechanismus, der nicht als allgemeine Funktion verwendet werden soll.

Funktioniert wie geplant, da a BACKUP DATABASE ... WITH COPY_ONLY...immer noch eine vollständige Sicherung ist .

Sicherheit zuerst

Wenn Sie eine Sicherung mit der BACKUP DATABASE ... COPY_ONLY...Option erstellen und anschließend erstellen BACKUP LOG..., können Sie die Datenbank mithilfe der vollständigen COPY_ONLYSicherung und der verfügbaren Transaktionsprotokollsicherungen weiterhin in einem konsistenten Zustand wiederherstellen .

Ich habe dies mit meiner StackExchange-Datenbank getestet:

  • Manuelles Erstellen eines COPY_ONLYBackups
  • Einige Daten ändern
  • Durchführen einer BACKUP LOG ...Verwendung von Ola-Skripten
  • Datenbank wiederherstellen

Manuelle Sicherung mit COPY_ONLY

---------------------------------------------
BACKUP DATABASE [StackExchange] TO DISK = 'C: \ adhoc \ StackExchange_Full_CopyOnly_20171221_082242.bak' 
                MIT COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'StackExchange-Full Backup Sichern ', SKIP, NOREWIND, 
                     NOUNLOAD, STATS = 10, CHECKSUM
---------------------------------------------
10 Prozent verarbeitet.
21 Prozent verarbeitet.
31 Prozent verarbeitet.
40 Prozent verarbeitet.
50 Prozent verarbeitet.
61 Prozent verarbeitet.
70 Prozent verarbeitet.
80 Prozent verarbeitet.
91 Prozent verarbeitet.
376 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange' in Datei 1 verarbeitet.
100 Prozent verarbeitet.
2 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange_log' in Datei 1 verarbeitet.
BACKUP DATABASE hat 378 Seiten in 0,027 Sekunden (109,103 MB / s) erfolgreich verarbeitet.
---------------------------------------------
Fertig

Sicherung des Transaktionsprotokolls mit Olas Skripten

Datum 21.12.2017 08:29:06
Protokollauftragsverlauf (OLA DatabaseBackup - USER_DATABASES - LOG)

Schritt ID 1
Server MYNOTEBOOK
Jobname OLA DatabaseBackup - USER_DATABASES - LOG
Schrittname OLA DatabaseBackup - USER_DATABASES - LOG
Dauer 00:00:01
SQL-Schweregrad 0
SQL-Nachrichten-ID 0
Betreiber per E-Mail    
Operator Net gesendet   
Betreiber ausgelagert  
Wiederholungsversuche 0

Botschaft
Als Benutzer ausgeführt: NT Service \ SQLSERVERAGENT. ... 557.0 Edition: Developer Edition (64-Bit) Vorgehensweise: [msdb]. [Dbo]. [DatabaseBackup] Parameter: @Databases = 'USER_DATABASES', @Directory = 'C: \ SQL \ Backup', @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = 48, @CleanupMode = 'AFTER_BACKUP', @Compress = NULL, @CopyOnly = 'N', @ChangeBackupType = 'N', @BackupSoftware = NULL, @CheckSum = 'Y', @BlockSize = NULL, @BufferCount = NULL, @MaxTransferSize = NULL, @NumberOfFiles = NULL, @CompressionLevel = NULL, @Description = NULL, @Threads = NULL, @Throttle = NULL, @Encrypt = 'N' , @EncryptionAlgorithm = NULL, @ServerCertificate = NULL, @ServerAsymmetricKey = NULL, @EncryptionKey = NULL, @ReadWriteFileGroups = 'N', @OverrideBackupPreference = 'N', @NoRecovery = '

[verkürzt]

  ... Prozess-Exit-Code 0. Der Schritt war erfolgreich.

Wiederherstellen

USE [master]
-- Restore the COPY_ONLY Backup 
RESTORE DATABASE [StackExchange] FROM  DISK = N'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
WITH  REPLACE, FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
-- Restore an OLA Transaction Log backup
RESTORE LOG [StackExchange] FROM  DISK = N'C:\SQL\Backup\MYNOTEBOOK\StackExchange\LOG\NB31710_StackExchange_LOG_20171221_082906.trn' 
WITH  FILE = 1,  NOUNLOAD,  STATS = 5

Möglicherweise beträgt der Unterschied in den Zeitstempeln nicht ca. 7 Minuten.

Ergebnisse

6 Prozent verarbeitet.
10 Prozent verarbeitet.
16 Prozent verarbeitet.
21 Prozent verarbeitet.
25 Prozent verarbeitet.
31 Prozent verarbeitet.
36 Prozent verarbeitet.
40 Prozent verarbeitet.
46 Prozent verarbeitet.
50 Prozent verarbeitet.
55 Prozent verarbeitet.
61 Prozent verarbeitet.
65 Prozent verarbeitet.
70 Prozent verarbeitet.
76 Prozent verarbeitet.
80 Prozent verarbeitet.
86 Prozent verarbeitet.
91 Prozent verarbeitet.
95 Prozent verarbeitet.
100 Prozent verarbeitet.
376 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange' in Datei 1 verarbeitet.
2 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange_log' in Datei 1 verarbeitet.
RESTORE DATABASE hat 378 Seiten in 0,021 Sekunden (140,276 MB / s) erfolgreich verarbeitet.
100 Prozent verarbeitet.
Verarbeitete 0 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange' in Datei 1.
2 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange_log' in Datei 1 verarbeitet.
RESTORE LOG hat 2 Seiten in 0,005 Sekunden (2,441 MB / s) erfolgreich verarbeitet.

Zusammenfassung

Olas Skript funktioniert wie geplant. Wir haben überprüft, dass a BACKUP DATABASE ... WITH COPY_ONLY...und a zusätzlich BACKUP LOG ...zusammenarbeiten. Die ausfallsichere Funktion stellt sicher, dass Sie Ihre Datenbank mit der letzten vollständigen Sicherung (COPY_ONLY oder nicht) und den verfügbaren Transaktionsprotokollsicherungen wiederherstellen können.

(Bitte lesen Sie Teil II von II für weitere Antworten)

John aka hot2use
quelle
Für die Sicherheit zuerst. + 1
Md Haidar Ali Khan
1

Sie haben Recht! Ich denke, das ist ein Fehler oder eine Absicht. Ich konnte das Szenario wiederholen.

Wenn Sie also Olas Skript folgendermaßen ausführen:

EXECUTE [master].[dbo].[DatabaseBackup] 
@Databases = 'UserShrinkSizeTest', 
@Directory = N'C:\Backup', 
@BackupType = 'FULL', 
@Verify = 'Y', 
@CleanupTime = NULL, 
@CheckSum = 'Y', 
@LogToTable = 'Y',
@CopyOnly = 'Y' --copy_only param

Oder einheimisch:

-- native copy_only
BACKUP DATABASE [UserShrinkSizeTest] 
TO  DISK = N'C:\Backup\machine$SQLSERVER16\UserShrinkSizeTest\COPY_ONLY\UserShrinkSizeTest_21122017_COPYONLY.bak'
 WITH  COPY_ONLY, INIT, STATS = 1
GO

Wenn Sie eine neue vollständige Sicherung oder vollständige copy_onlySicherung oder sogar eine differenzielle Sicherung ausführen , werden alle Ihre vorherigen Protokollsicherungen gelöscht, nachdem Sie eine weitere Protokollsicherung ausgeführt haben ( @CleanupTime = 0Olas Protokollsicherungsskript mit param).

Getestet mit Olas Skriptversion: 7. Oktober 2016 .

Basierend auf Olas Website :

Putzzeit

Geben Sie die Zeit in Stunden an, nach der die Sicherungsdateien gelöscht werden. Wenn keine Zeit angegeben ist, werden keine Sicherungsdateien gelöscht.

DatabaseBackup überprüft, ob Transaktionsprotokollsicherungen, die neuer als die letzte vollständige oder differenzielle Sicherung sind, nicht gelöscht werden.

COPY_ONLYBackups wurden nicht erwähnt .

In der Zwischenzeit können Sie den Protokollsicherungsparameter als Problemumgehung ändern @CleanupTime = NULL. Oder wechseln Sie zu einem anderen Backup- Tool (z. B. Minion Backup oder dbatools ) oder rollen Sie Ihren eigenen benutzerdefinierten Code, da das letzte Update von Olas Wartungsplan am 7. Oktober 2016 erfolgte. Es gibt einen Github, wenn Sie ein Problem / eine Verbesserung ansprechen möchten .


quelle
1
Vielen Dank für Ihre Meinung. Die Verwendung von CleanupTime = 0 ist definitiv keine gute Idee. Ich denke auch, dass COPY_ONLY-Backups einen Unterschied zu Nicht-COPY_ONLY-Backups haben sollten (zumindest unter Verwendung von Olas Skripten), andernfalls warum sollten sie vorhanden sein. Ich konnte das in Olas Skripten enthaltene dbo.DatabaseBackup SP so ändern, dass COPY_ONLY-Sicherungen ignoriert werden, wenn ermittelt wird, welche TLOG-Sicherungsdateien gelöscht werden sollen.
Guillermo Garcia
@ GuillermoGarcia hat noch nie daran gedacht, CleanupTime = 0param zu verwenden, also habe ich daran gedacht, es zu testen. Wir lernen jeden Tag etwas Neues. und ja copy_onlysollte in Ola-Schrift verschieden sein.