Was ist eine Low-Splash-Sicherung?
Unter normalen Umständen erstellt Backup and DR auf einer Backup and DR Service-Sicherungs-/Wiederherstellungs-Appliance eine zeitaufwendige erste Vollsicherung einer Datenbank. Alle nachfolgenden Sicherungen sind dann viel schnellere inkrementelle Sicherungen. Bei einer inkrementellen Sicherung werden Bitmaps des aktuellen Snapshots mit dem vorherigen Snapshot verglichen und nur die inkrementellen Änderungen angewendet.
Eine Low-Splash-Sicherung ist ein spezieller Sicherungsjob, der auftritt, wenn ein Systemfehler im vorherigen Sicherungsjob zu einem unzuverlässigen Bitmap-Image führt oder das Bitmap nicht gelesen werden kann. Der Dienst, der das Bitmap liest, ist in einer Linux-Umgebung „cbt_server“ und in einer Windows-Umgebung „AAMService“.
Low-Splash-Sicherungen sind zeitaufwendiger als Sicherungen unter normalen Bedingungen, da sie eine vollständige Aufnahme erfordern, um ein zuverlässiges Bitmap neu zu erstellen. Anschließend können die inkrementellen Änderungen angewendet werden, ohne dass die vollständige Sicherung ersetzt werden muss.
Ursachen für Low-Splash-Sicherungen
- Connector-Upgrades
- Ordnungsgemäße Systemneustarts
- Ordnungsgemäße Neustarts von „cbt_server“ oder „AAMService“, vorausgesetzt, der Dienst wird zum Zeitpunkt der Sicherung noch ausgeführt
Failover, bei denen die Fehler, die zu unzuverlässigen Bitmaps führen, nicht aufgetreten sind.
Ursachen für unzuverlässige Bitmaps
Ein unzuverlässiges Bitmap tritt auf, wenn etwas den Sicherungsjob unterbricht. Dazu gehören:
- Ein nicht ordnungsgemäßes Herunterfahren des Hosts:
- Ein nicht ordnungsgemäßes Herunterfahren führt aufgrund der Unzuverlässigkeit von Bitmaps zu Low-Splash-Sicherungen. Dazu gehört das Ziehen des Netzsteckers bei einem physischen Computer oder jede andere Methode, Windows ohne ordnungsgemäßes Herunterfahren auszuschalten, oder ein Bluescreen-Fehler. Das gilt auch dann, wenn auf einem Computer in einem Cluster ein Bluescreen-Fehler auftritt, der ein Failover auslöst, da das Bitmap des ausgefallenen Computers unzuverlässig ist.
- Wenn alle Windows-Server in einem Cluster, auf denen die Datenbank seit der letzten Sicherung gehostet wurde, nicht verfügbar sind und der Backup and DR-Agent nicht ausgeführt wird. Wir rufen Bitmaps von jedem Clusterhost ab, auf dem die Datenbank seit der letzten Sicherung gehostet wurde, um Änderungen zu finden. Ohne alle Bitmaps müssen wir eine Low-Splash-Sicherung ausführen, um die Datenintegrität zu gewährleisten. Wenn auf einem Clusterhost, auf dem eine Datenbank gehostet wurde, ein Bluescreen-Fehler auftritt, ist das Bitmap möglicherweise bei der Sicherung verfügbar, aber dennoch unzuverlässig. Daher ist eine Low-Splash-Wiederherstellung erforderlich.
- Ein fehlgeschlagenes Kernelmodul-Update
- Ein Absturz oder Neustart des Daemon im Nutzermodus
- Ein Fingerabdruckfehler beim Ausführen einer Sicherung. Backup and DR Service führt für jeden Sicherungsjob eine Fingerabdruckprüfung durch, um nach Fehlern zu suchen.
- Fehler beim Vaulting, wenn die Speicherfestplatte während des Herunterfahrens des Betriebssystems voll ist und das System nicht alle Daten in den Vault schreiben kann.
- SAP HANA-Knoten-Failover, wodurch die Sicherung zu einem anderen Knoten umgeleitet wird.
- Sicherung im eingeschränkten Modus, da das Kernelmodul nicht geladen werden kann. Dies tritt in der Regel auf, wenn das Betriebssystem eine nicht unterstützte Version ist.
- Wenn „cbt_server“ oder „AAMService“ während der Sicherung beendet wird, können keine Bitmaps abgerufen werden und der Sicherungsjob wird im Low-Splash-Modus ausgeführt.
Wenn „AAMService“ nicht sehr lange ausfällt, sind nach dem Starten von „AAMService“ Bitmaps für eine normale Sicherung verfügbar.
- Wenn „cbt_server“ oder „AAMService“ so lange beendet wird, dass einige Gigabyte an Ereignissen vom Treiber in die Warteschlange gestellt werden, können die Bitmaps nicht neu erstellt werden und die Sicherung erfolgt im Low-Splash-Modus. Wie lange das dauert, hängt davon ab, wie viele Laufwerk-E/A-Vorgänge in der Datenbank ausgeführt werden. Dies erfordert in der Regel einen Ausfall von „AAMService“ von mehreren Tagen.
- Ein nicht ordnungsgemäßes Herunterfahren von „cbt_server“ oder „AAMService“ kann dazu führen, dass Bitmaps für alle derzeit geladenen Bitmaps unzuverlässig werden. Bitmaps werden geladen, wenn in den letzten 15 Minuten in die verfolgte Datei geschrieben wurde. Bei einer stark ausgelasteten Datenbank führt dies in der Regel zu Low-Splash-Sicherungen.
- Wenn ein Volume mit einer verfolgten Datei (z. B. eine SQL Server-MDF-Datei) auf dem Host unmounted und dann wieder gemountet wird, sind die Bitmaps unzuverlässig, da nicht bekannt ist, was in die Datei geschrieben wurde, während sie unmounted war.