it-swarm.com.de

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

Wenn ich das Sicherungsskript von Ola Hallengren auf meinen Servern bereitstelle, setze ich den Parameter @CleanupTime 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_ONLY Backups! Der Protokollsicherungsjob sollte nur nach der letzten nicht - COPY_ONLY Vollstä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.

7

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 @CleanupTime In einen höheren Wert als 0 Ändern. Warum? Weil der Wert 0 Nur zusammen mit dem eingebauten Fail-Safe-Mechanismus funktioniert.

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 das erste BACKUP LOG ... Nach dem letzten BACKUP DATABASE ... Tritt, sind 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 (z. B. @CleanupTime=48) Verwenden, 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 eine COPY_ONLY - Sicherung erstellen
  • Ihre Daten befinden sich immer noch auf der Festplatte, auch wenn Netzwerk fällt aus und ...
    • ... Sie erstellen einen BACKUP DATABASE ...
    • ... ein COPY_ONLY Backup

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

Die Arbeit mit Olas Lösung ist ein Kinderspiel. WENN Sie machen sich ein oder zwei Gedanken darüber, wie Sie eine Datenbank wiederherstellen möchten, und basieren auf dem RPO und RTO Ihres Unternehmens.

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

Produktionssysteme

  • Backup TLog
    • 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 Einstellung @CleanupTime Basierte wahrscheinlich auf einem falschen Verständnis von Olas Skript.

5

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 werfen hier , die in Bezug auf die Frage veröffentlicht wurde Benötigen Sie einen Vorschlag zur Sicherungsstrategie [geschlossen] , um Ihnen einige Ideen zu geben RTO und RPO.

Warum? Weil das Setzen von @CleanupTime=0 Eine schlechte Idee sein könnte ...

Beantworten Sie zuerst Ihre Frage.

Ist es ein Fehler in Olas Skript? - Nein. Ola hat seins entworfen Skript zum Suchen nach dem letzten BACKUP DATABASE... (vollständige Sicherung) und zum Löschen der Transaktionsprotokollsicherungen (BACKUP LOG ...), die vor dieser Sicherung und nur wenn @CleanupTime niedriger ist als bei der vollständigen Sicherung.

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

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

Sicherheit zuerst

Wenn Sie eine Sicherung mit der Option BACKUP DATABASE ... COPY_ONLY... Erstellen und dann BACKUP LOG... Erstellen, können Sie die Datenbank weiterhin mit der vollständigen Sicherung COPY_ONLY Und den verfügbaren Transaktionsprotokollsicherungen in einem konsistenten Zustand wiederherstellen.

Ich habe dies mit meiner StackExchange-Datenbank getestet:

  • Manuelles Erstellen eines COPY_ONLY - Backups
  • Einige Daten ändern
  • Durchführen eines BACKUP LOG ... Mit Olas Skripten
  • Datenbank wiederherstellen

Manuelle Sicherung mit COPY_ONLY

 ----------------------------------------- ---- 
 SICHERUNGSDATENBANK [StackExchange] TO DISK = 'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
 MIT COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINITSt = -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' verarbeitet, Datei 'StackExchange' in Datei 1. 
 100 Prozent verarbeitet. 
 2 Seiten für die Datenbank 'StackExchange verarbeitet ', Datei' StackExchange_log 'in Datei 1. 
 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 
 Operator per E-Mail 
 Operator-Netz gesendet 
 Operator ausgelagert 
 Wiederholte Versuche 0 
 
 Nachricht 
 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 = 'N', @CL = NULL, @MirrorDirectory = NULL, @MirrorCleanupTime = NULL, @MirrorCleanupMode = 'AFTER_BACKUP', @AvailabilityGroups = NULL, @Updateability = 'ALL', @LogToTable = 'Y', @Execute = 'Y' Quelle: https: // ola.hallengren.com Datum und Uhrzeit: 2017-12-21 08: 29:06 Datenbank: [AdminDB2] Status: ONLINE Standby: Nein Aktualisierbarkeit: READ_WRITE Benutzerzugriff: MULTI_USER Zugriff: Ja Wiederherstellungsmodell: VOLL verschlüsselt: Nein Differenzielle Basis LSN: 36000001056400037 Letzte Protokollsicherung LSN: 36000001061600001 Datum und Uhrzeit: 2017-12 -21 08:29:06 Befehl: DECLARE @ReturnCode int EXECUTE @ReturnCode = [master] .dbo.xp_create_subdir N'C:\SQL\Backup\MYNOTEBOOK\AdminDB2\LOG 'IF @ReturnCode 0 RAISERROR (' Fehler beim Erstellen des Verzeichnisses. ', 16, 1) Ergebnis: Erfolgreich Dauer: 00:00:00 Datum und Uhrzeit: 2017-12-21 08:29:06 Datum und Uhrzeit: 2017-12-21 08:29:06 Befehl: 
 
 [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' verarbeitet, Datei 'StackExchange' in Datei 1. 
 Verarbeitet 2 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange_log' in Datei 1. 
 RESTORE DATABASE hat 378 Seiten in 0,021 Sekunden (140,276 MB/s) erfolgreich verarbeitet. 
 100 Prozent verarbeitet. 
 Verarbeitet 0 Seiten für die Datenbank 'StackExchange', Datei 'StackExchange' in Datei 1. 
 Verarbeitet 2 Seiten für d atabase 'StackExchange', Datei 'StackExchange_log' in Datei 1. 
 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 ein BACKUP DATABASE ... WITH COPY_ONLY... Und ein zusätzlicher 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)

3

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_only - oder sogar differenzielle Sicherung ausführen, werden alle Ihre vorherigen Protokollsicherungen gelöscht, nachdem Sie eine weitere Protokollsicherung ausgeführt haben (Olas Protokollsicherungsskript mit dem Parameter @CleanupTime = 0).

Getestet mit Olas Skriptversion: 7. Oktober 2016 .

Basierend auf Olas Website :

CleanupTime

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.

Es wurden keine COPY_ONLY - Backups erwähnt.

In der Zwischenzeit können Sie den Protokollsicherungsparameter als Problemumgehung in @CleanupTime = NULL Ändern. Oder ziehen Sie in Betracht, zu anderen Sicherungswerkzeugen zu wechseln (z. B. Minion Backup oder dbatools ) oder Ihren eigenen benutzerdefinierten Code zu erstellen, da die letzte Aktualisierung des Wartungsplans von Ola am 7. Oktober 2016 erfolgte. Es gibt ein Github , wenn Sie ein Problem/eine Verbesserung ansprechen möchten.

1
user37701