Ursachen für Sicherungen mit wenigen Splash-Bildern auf Sicherungs‑/Wiederherstellungs-Appliances

Was ist eine Sicherung mit wenig Splash-Effekt?

Unter normalen Umständen führt Backup and DR auf einer Backup- und Wiederherstellungs-Appliance von Backup and DR eine zeitaufwendige erste Vollsicherung einer Datenbank durch. Alle nachfolgenden Sicherungen sind dann viel schnellere inkrementelle Sicherungen. Bei einer inkrementellen Sicherung werden Bitmaps des aktuellen und des vorherigen Snapshots verglichen und nur die inkrementellen Änderungen angewendet.

Eine Sicherung mit geringem Splash ist ein spezieller Sicherungsjob, der ausgeführt wird, wenn ein Systemfehler im vorherigen Sicherungsjob zu einem unzuverlässigen Bitmapbild oder dazu führt, dass das Bitmap nicht gelesen werden kann. Der Dienst, der die Bitmap liest, ist „cbt_server“ in einer Linux-Umgebung und „AAMService“ in einer Windows-Umgebung.

Sicherungen mit geringer Spritzwasserbelastung sind zeitaufwendiger als Sicherungen unter normalen Bedingungen, da sie eine vollständige Aufnahme erfordern, um eine zuverlässige Bitmap zu erstellen. Anschließend können die inkrementellen Änderungen angewendet werden, ohne dass die vollständige Sicherung ersetzt werden muss.

Faktoren, die keine Backups mit geringem Spritzwasser verursachen

  • Connector-Upgrades
  • Ordnungsgemäße Neustarts des Systems
  • Sanfte Neustarts von cbt_server oder AAMService, sofern der Dienst zum Zeitpunkt der Sicherung noch ausgeführt wird
  • Failover, bei denen die Fehler, die zu unzuverlässigen Bitmaps führen, nicht aufgetreten sind.

Ursachen für unzuverlässige Bitmaps

Eine unzuverlässige Bitmap tritt auf, wenn der Sicherungsjob unterbrochen wird, z. B. durch Folgendes:

  • Ein nicht ordnungsgemäßes Herunterfahren des Hosts:
    • Ein nicht ordnungsgemäßes Herunterfahren führt aufgrund der Unzuverlässigkeit von Bitmaps zu einem geringen Splash. Dazu gehört das Ziehen des Netzsteckers eines physischen Computers oder jede andere Methode zum Herunterfahren von Windows ohne ordnungsgemäßes Herunterfahren 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 die Bitmap des ausgefallenen Computers nicht zuverlä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 ausgeführt wird. Wir rufen Bitmaps von jedem Clusterhost ab, auf dem die Datenbank seit der vorherigen Sicherung gehostet wurde, um Änderungen zu finden. Ohne alle Bitmaps müssen wir „low-splash“ ausführen, um die Datenintegrität aufrechtzuerhalten. Wenn auf einem Clusterhost, auf dem eine Datenbank gehostet wurde, ein BSOD auftritt, ist die Bitmap möglicherweise im Backup verfügbar, aber dennoch unzuverlässig. Daher ist eine Low-Splash-Wiederherstellung erforderlich.
  • Ein fehlgeschlagenes Kernelmodul-Update
  • Absturz oder Neustart des Daemon im Nutzermodus
  • Beim Ausführen einer Sicherung ist ein Fingerabdruckfehler aufgetreten. (Backup and DR führt für jeden Sicherungsjob eine „Fingerabdruckprüfung“ durch, um nach Fehlern zu suchen.)
  • Fehler beim Vaulting, wenn das Speicherlaufwerk 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.
  • Die Sicherung wird im eingeschränkten Modus ausgeführt, da das Kernelmodul nicht geladen werden konnte. Das passiert in der Regel, wenn das Betriebssystem eine nicht unterstützte Version ist.
  • Wenn „cbt_server“ oder „AAMService“ während des Back-ups beendet wird, können keine Bitmaps abgerufen werden und der Back-up-Job wird im Low-Splash-Modus ausgeführt. Wenn AAMService nicht sehr lange ausgefallen ist, sind nach dem Starten von AAMService Bitmaps für eine normale Sicherung verfügbar.
    • Wenn „cbt_server“ oder „AAMService“ so lange angehalten wird, dass einige Gigabyte an Ereignissen vom Treiber in die Warteschlange gestellt werden, können die Bitmaps nicht neu erstellt werden und das Backup befindet sich im Low-Splash-Modus. Wie lange das dauert, hängt davon ab, wie viele Laufwerk-E/A in der Datenbank stattfinden. Dazu ist in der Regel eine mehrtägige Ausfallzeit des AAMService erforderlich.
  • Wenn der cbt_server oder AAMService nicht ordnungsgemäß heruntergefahren wird, können 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 genutzten Datenbank führt dies in der Regel zu einem geringen Splash.
  • Wenn ein Volume mit einer verfolgten Datei (z. B. einer SQL Server-MDF-Datei) auf dem Host unmountet und dann wieder gemountet wird, sind die Bitmaps unzuverlässig, da nicht bekannt ist, was in die Datei geschrieben wurde, während sie unmountet war.