NetBackup VM-Backup vs. Datenbank-Backup

NetBackup-VM-Backup und Datenbank-Backup lösen unterschiedliche Wiederherstellungsprobleme — die Wahl sollte deshalb davon ausgehen, was wiederhergestellt werden muss. Ein VM-Image ist nützlich, wenn der gesamte Server zurückkommen muss, während anwendungsbewusster Datenbankschutz wichtig ist, wenn die Datenbank konsistent, granular oder bis zu einem bestimmten Transaktionspunkt wiederhergestellt werden muss.

Eine aktuelle Administratorfrage formulierte es als Entweder-oder-Entscheidung: eine VM sichern, die eine Datenbank enthält, oder nur die Datenbank sichern — und wann muss ein NetBackup-Client innerhalb der VM installiert werden? Ein zweiter Fall machte dasselbe Thema konkreter. SUSE-Linux-VMs wurden bereits als ganze Maschinen gesichert, aber das Team wurde gebeten, GitHub-bezogene Dienste und Nexus zusätzlich getrennt für Konsistenz zu schützen.

Die richtige Antwort besteht darin, Wiederherstellungsebenen zu gestalten, statt ein einzelnes Backup-Objekt zu wählen und zu hoffen, dass es jeden Fehlerfall abdeckt.

Was schützt ein VM-Backup gut?

Ein VM-Backup schützt die virtuelle Maschine als Infrastrukturobjekt. Das umfasst in der Regel ihre virtuellen Disks und den Zustand, den NetBackup über den VMware-Backup-Workflow erfassen kann, und gibt Administratoren einen praktischen Weg, eine ausgefallene oder gelöschte Maschine wiederherzustellen, ohne das Betriebssystem von Grund auf neu aufzubauen.

Das ist wertvoll bei Hypervisor-Ausfall, VM-Löschung, Betriebssystem-Beschädigung oder einer umfassenden Infrastruktur-Wiederherstellung. Die Maschine kommt mit ihrer installierten Software, Konfiguration und ihrem Disk-Layout aus dem gewählten Recovery Point zurück.

Aber die eigentlich relevante Frage ist nicht, ob die VM-Disk Datenbankdateien enthält. Natürlich enthält sie das. Die Frage ist, ob diese Dateien einen Datenbankzustand darstellen, den die Anwendung unter dem geforderten RPO und RTO sauber wiederherstellen kann.

Ein crash-konsistentes Image ähnelt womöglich dem, was die Maschine bei plötzlichem Stromausfall sehen würde. Manche Datenbanken können sich davon mithilfe ihrer eigenen Journale oder Transaktionslogs erholen. Andere benötigen anwendungsbewusstes Quiescing, Log-Handling oder eine datenbanknative Backup-Sequenz, um das vom Unternehmen erwartete Wiederherstellungsziel zu erreichen.

Dieser Unterschied ist der Grund, warum sich ein grüner VM-Job nicht automatisch in „die Datenbank ist korrekt geschützt" übersetzen lässt.

Wann ist anwendungsbewusster Datenbankschutz notwendig?

Anwendungsbewusster Schutz wird notwendig, wenn die Wiederherstellungsanforderung in Datenbankbegriffen formuliert ist. Beispiele sind das Wiederherstellen einer Datenbank ohne die gesamte VM, die Wiederherstellung auf einen bestimmten Zeitpunkt, der korrekte Umgang mit Transaktionslogs, die Wiederherstellung auf einen anderen Datenbank-Host oder der Nachweis, dass das Backup aus einem konsistenten Anwendungszustand stammt.

NetBackup kann einige dieser Ziele mit VMware-Image-Schutz für unterstützte Anwendungen kombinieren. Veritas dokumentiert SQL-Server-Schutz, bei dem eine VMware-Policy und der Veritas-VSS-Provider ein konsistentes vollständiges Datenbank-Backup innerhalb einer VM erstellen können. Dasselbe VMware-Backup kann Volume-, Datei- und Datenbank-Recovery unterstützen, und unterstützte Konfigurationen können die Log-Kürzung steuern.

Das ist eine wichtige Korrektur an der vereinfachten Debatte „VM versus Datenbank". Bei manchen Workloads kann NetBackup das VM-Backup anwendungsbewusst machen. Bei anderen ist eine dedizierte Anwendungs-Policy oder ein Plug-in die bessere Wahl.

Verallgemeinern Sie den SQL-Server-Workflow nicht auf jede Datenbank. MongoDB, Oracle, PostgreSQL, SQL Server und Anwendungsplattformen haben jeweils unterschiedliche Integrations- und Restore-Anforderungen. Verwenden Sie die workload-spezifische NetBackup-Anleitung für das installierte Release.

Sollten sowohl die VM als auch die Datenbank gesichert werden?

Bei einem kritischen Datenbankserver ist der Schutz beider Wiederherstellungsebenen oft das praktikabelste Design, aber das bedeutet nicht immer, zwei völlig unabhängige Vollbackups zu fahren. Das Ziel ist, sowohl Maschinen- als auch Anwendungswiederherstellung zu erhalten, ohne unnötige Duplizierung.

Wenn ein unterstützter anwendungsbewusster VMware-Workflow sowohl vollständige VM-Wiederherstellung als auch datenbankkonsistente Restore-Optionen bietet, kann er beide Ebenen effizient abdecken. Erfüllt er das Datenbank-RPO, die Log-Recovery-Anforderung oder das Anwendungs-Support-Modell nicht, ergänzen Sie die datenbankspezifische Schutzmethode.

Denken Sie in Fehlerszenarien. Wenn die gesamte VM gelöscht wird, wie schnell lässt sie sich wiederaufbauen? Wenn eine Datenbank beschädigt ist, können Sie nur diese Datenbank wiederherstellen? Wenn um 14:05 Uhr fehlerhafte Daten committet werden, können Sie auf 14:04 Uhr zurück? Wenn die ursprüngliche VM nicht bootet, kann die Datenbank woanders wiederhergestellt werden?

Eine Backup-Architektur, die diese Fragen nicht beantworten kann, ist immer noch werkzeugzentriert.

Der Proxmox-Backup-Vergleich von Mr.PlanB behandelt eine andere Virtualisierungsplattform, aber dieselbe Idee der Wiederherstellungsebenen gilt auch dort. Schutz auf Hypervisor-Ebene ist hervorragend für die Maschinenwiederherstellung. Anwendungen können trotzdem ihre eigene Konsistenz- und Wiederherstellungssemantik verlangen.

Wann muss der NetBackup-Client innerhalb der VM installiert werden?

Die Client-Anforderung hängt von der NetBackup-Schutzmethode und dem Workload ab. VMware-Image-Level-Backup kann VMs über den Virtualisierungs-Stack schützen, ohne jeden Gast wie einen klassischen Dateisystem-Client zu behandeln, während Anwendungs-Plug-ins und Datenbank-Workflows Software, Anmeldedaten oder einen dedizierten Backup-Host innerhalb oder in der Nähe der Anwendungsumgebung erfordern können.

Das bedeutet, dass „den Client auf jeder Datenbank-VM installieren" zu pauschal ist, und „VMware-Backup braucht nie irgendetwas im Gast" ebenfalls zu pauschal wird, sobald Anwendungskonsistenz Teil des Designs wird.

Für SQL Server dokumentiert Veritas anwendungsbewusstes VMware-Verhalten über die VSS-Integration. Für MongoDB verwendet NetBackup sein MongoDB-Plug-in und eine Backup-Host-Architektur mit eigenen Anforderungen an Anmeldedaten und zugelassene Hosts. Andere Workloads haben ihre eigenen Regeln.

Bilden Sie die Komponenten für den genauen Policy-Typ ab. Welche Maschine spricht mit vCenter? Welcher Host führt das Anwendungs-Plug-in aus? Welches System braucht NetBackup-Client-Software? Welche Identität erreicht die Datenbank? Welche Komponente kürzt oder erhält Logs? Welcher Host führt den Restore durch?

Diese Zuordnung beantwortet die Installationsfrage zuverlässiger als die bloße Tatsache, dass die Anwendung zufällig in einer VM läuft.

Was bedeutet „konsistentes Backup" für Linux-Anwendungen wie Nexus?

„Konsistent" muss für die jeweilige Anwendung definiert werden, denn ein Snapshot einer gesamten SUSE-Linux-VM erklärt nicht automatisch, ob jede Anwendungskomponente gemeinsam wiederherstellbar ist. Ein Dienst wie Nexus kann von Anwendungsdateien, Metadaten, Konfiguration und einer Datenbank oder einem eingebetteten Datenspeicher abhängen, deren Konsistenzregeln beim Backup eine Rolle spielen.

Der gemeldete SUSE-Fall hatte bereits Whole-VM-Backups. Die neue Anforderung war, GitHub-bezogene Dienste und Nexus zusätzlich getrennt für Konsistenz zu sichern. Bevor Sie eine weitere Policy hinzufügen, ermitteln Sie, was jeder Anwendungshersteller für ein unterstütztes Backup verlangt. Das kann bedeuten, Schreibvorgänge zu stoppen, einen Anwendungs-Export zu nutzen, einen Datenbank-Snapshot zu koordinieren, Blob-Storage zu schützen oder Konfiguration und Secrets zusammen mit den Daten zu erfassen.

Die Ausgangsdiskussion lieferte nicht genug Belege, um eine einzelne NetBackup-Policy für GitHub oder Nexus vorzuschreiben. Die sichere Entscheidung ist deshalb, dem unterstützten Backup-Verfahren der Anwendung zu folgen und NetBackup anschließend um diese Anforderung herum anzupassen.

Ein vollständiger Restore-Test sollte den Dienst wiederaufbauen, nicht nur seine Dateien wiederherstellen.

Wie sollten RPO und RTO das Backup-Design bestimmen?

RPO legt fest, wie viel Datenverlust akzeptabel ist, während RTO festlegt, wie lange die Wiederherstellung dauern darf. Diese beiden Kennzahlen zeigen oft, warum eine einzelne Schutzebene nicht ausreicht.

Ein nächtliches VM-Backup mag für einen Hilfsserver ausreichen, ist aber inakzeptabel für eine stark ausgelastete transaktionale Datenbank, die nur Minuten an Arbeit verlieren darf. Ein Datenbank-Log-Backup kann ein engeres RPO liefern, aber der komplette Wiederaufbau von Betriebssystem und Anwendungs-Stack allein aus Datenbankdateien kann zu lange dauern, nachdem eine VM zerstört wurde.

Kombinieren Sie die Ebenen entsprechend diesen Zielen. Ein regelmäßiges VM-Image kann schnelle Maschinenwiederherstellung liefern. Häufigerer Datenbank- oder Transaktionslog-Schutz kann einen engeren Datenwiederherstellungspunkt liefern. Das Restore-Runbook erklärt dann, wann welches davon genutzt wird.

Der Proxmox-Backup-Server-Leitfaden ist hilfreich, um über Retention und Restore auf Image-Ebene in einem anderen Ökosystem nachzudenken. Die grundsätzliche Lehre ist plattformneutral: Häufigkeit, Aufbewahrung und Wiederherstellungsgranularität müssen zum Workload passen, nicht zum Standardzeitplan des Backup-Produkts.

Wie sollte das Design getestet werden?

Testen Sie mindestens drei Wiederherstellungen: vollständigen VM-Restore, reinen Datenbank-Restore und Wiederherstellung nach einem Fehler bei der Anwendungskonsistenz. Die erste beweist die Infrastruktur-Wiederherstellung. Die zweite beweist die granulare Anwendungswiederherstellung. Die dritte beweist, dass das Team erkennt, wann einem technisch abgeschlossenen Backup für den vorgesehenen Datenbankzweck nicht vertraut werden sollte.

Beziehen Sie bei transaktionssensiblen Datenbanken punktgenaue Wiederherstellung ein, wenn das Design sie verspricht. Messen Sie die tatsächliche Restore-Zeit. Prüfen Sie nach der Wiederherstellung den Anwendungsstart, Integritätsprüfungen, Benutzerzugriff und nachgelagerte Integrationen.

Testen Sie auch, wo der Restore landet. Ein Datenbank-Backup, das nur auf die ursprüngliche VM wiederherstellen kann, ist bei einem größeren Vorfall womöglich weniger nützlich als eines, das auf einen alternativen Host wiederherstellen kann. Ein VM-Backup, das schnell wiederherstellt, aber von nicht verfügbarem Shared Storage abhängt, verfehlt womöglich das eigentliche Katastrophenszenario.

Dokumentieren Sie, welches Backup für welchen Fehlertyp maßgeblich ist. Während eines Ausfalls sollte das Team nicht zum ersten Mal darüber diskutieren, ob die VM oder die Datenbank wiederhergestellt werden soll.

Was würde ich für eine Datenbank-VM wählen?

Ich würde die VM für die Wiederherstellung auf Maschinenebene schützen und dann sicherstellen, dass die Datenbank einen anwendungskonsistenten Wiederherstellungspfad hat, der ihr RPO erfüllt. Wenn die unterstützte VMware-Integration von NetBackup beides für diese Datenbank und Version bieten kann, würde ich diese Integration nutzen, statt Daten ohne Grund zu duplizieren.

Wenn der Workload Transaktionslog-Wiederherstellung, reinen Datenbank-Restore, anwendungsspezifische Konsistenz oder einen engeren Zeitplan braucht, als die VM-Policy bieten kann, würde ich die datenbankbewusste Policy oder das Plug-in ergänzen. Komponenten auf Gastseite würde ich nur dort installieren, wo der dokumentierte Workflow es verlangt.

Die Entscheidung lautet also nicht „VM oder Datenbank". Sie lautet „welche Wiederherstellungsvorgänge müssen funktionieren, und welche NetBackup-Schutzmethoden belegen diese Vorgänge?" Sobald das schriftlich festgehalten ist, lassen sich Client-Platzierung, Zeitpläne und Policy-Typen deutlich leichter begründen.