Langfristig aufbewahrte Sicherungen wiederherstellen

Sie können langfristig aufbewahrte Sicherungen direkt aus Ihren Cloud Storage-Buckets mit einem eigenständigen Dienstprogramm wiederherstellen. So ist der Datenzugriff auch ohne aktive Backup and DR-Appliances möglich.

In diesem Dokument wird beschrieben, wie Sie dieses eigenständige Wiederherstellungstool verwenden, um OnVault- und Compute Engine-Sicherungsimages zu erkennen, zu prüfen, einzubinden und wiederherzustellen.

Übersicht

Langfristig aufbewahrte Sicherungen werden in Cloud Storage-Buckets mit OnVault-Richtlinien für Compliance und Archivierung gespeichert. Um den Datenzugriff unabhängig von der Sicherungsinfrastruktur zu gewährleisten, können Sie ein eigenständiges Wiederherstellungstool verwenden, um diese Daten direkt aus dem Speicher-Bucket zu ermitteln, zu prüfen und wiederherzustellen. Dies ist entscheidend für Notfallwiederherstellungs- oder Außerbetriebnahmeszenarien, in denen das ursprüngliche Sicherungs-/Wiederherstellungsgerät möglicherweise nicht verfügbar ist.

Hinweis

Bevor Sie mit der Wiederherstellung von Back-ups mit langfristiger Aufbewahrung beginnen, müssen Sie die folgenden Abschnitte durcharbeiten.

Erforderliche Rollen abrufen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Backup and DR Cloud Storage Operator (roles/backupdr.cloudStorageOperator) für den Ziel-Cloud Storage-Bucket zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Wiederherstellen von langfristig aufbewahrten Sicherungen benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Weitere Voraussetzungen

Bevor Sie Sicherungen wiederherstellen, die langfristig aufbewahrt wurden, müssen die folgenden Voraussetzungen erfüllt sein:

  1. Bevor Sie eine Wiederherstellung starten, prüfen Sie, ob Ihre Daten im OnVault-Speicher verfügbar sind. Prüfen Sie vorhandene Sicherungen im Pool der Sicherungs-/Wiederherstellungs-Appliances und migrieren Sie sie zu OnVault, indem Sie die entsprechende OnVault-Schutzrichtlinie zuweisen.

  2. Prüfen Sie bei Wiederherstellungsszenarien mit Persistent Disk-Snapshots, ob alle Sicherungsmetadaten in den Ziel-Cloud Storage-Bucket repliziert wurden. Das Wiederherstellungstool ist auf diese Metadaten angewiesen, um Snapshot-Bilder zu katalogisieren und zu verarbeiten. Wenden Sie sich an Cloud Customer Care, um die Datenübertragung zu erleichtern und zu bestätigen, dass Metadaten im Cloud Storage-Bucket vorhanden sind.

  3. Das Hostsystem, auf dem Sie dieses Tool ausführen, muss die folgenden Anforderungen erfüllen:

    • gcloud CLI: Muss installiert und in Ihrer Umgebungsvariable PATH (insbesondere gcloud storage) verfügbar sein.
    • Authentifizierung: Konfiguriert mit aktiven Anmeldedaten durch Ausführen von gcloud auth login oder mit Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) oder Dienstkontoschlüsseln.

  4. Erstellen Sie eine Liste der Cloud Storage-Bucket-Namen und der entsprechenden Google Cloud Projekt-IDs, die mit dem Wiederherstellungstool verwendet werden sollen.

Wiederherstellungstool bereitstellen

Konfigurieren Sie eine VM-Instanz als Wiederherstellungs-Proxy oder als Zielanwendungshost und stellen Sie dann das eigenständige Wiederherstellungstool bereit.

Geräte, Hosts und Bilder entdecken

Das eigenständige Wiederherstellungstool akzeptiert ein Paar aus Bucket- und Projektwerten (--bucket und --project) für Befehle. Das Dienstprogramm unterstützt die folgenden Vorgänge:

  • Anwendungen auflisten
  • Sicherungen auflisten
  • Sicherungen ablaufen lassen
  • Reservebild einbinden
  • Sicherungsimage unmounten

Reservebild einbinden

Um eine Wiederherstellungsmount durchzuführen, müssen Sie zuerst den Namen des Sicherungs-Images ermitteln.

Listen Sie die verfügbaren Sicherungen auf, um den Namen des Sicherungs-Image zu ermitteln:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

Verwenden Sie dann einen Befehl, der dem folgenden Beispiel ähnelt, um eine nicht interaktive Wiederherstellungsbereitstellung durchzuführen und das ausgewählte Sicherungs-Image direkt auf dem angegebenen Wiederherstellungs-Proxy oder dem Zieldatenbankserver bereitzustellen:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

Ersetzen Sie Folgendes:

  • BUCKET_NAME durch den Namen des Cloud Storage-Buckets.
  • PROJECT_ID: Projekt-ID in Google Cloud .
  • APPLIANCE_NAME: Der Name oder die ID der Sicherungs‑/Wiederherstellungs-Appliance.
  • HOST_NAME: der Hostname oder die ID des Quellhosts.
  • APPLICATION_NAME: Der Name oder die ID der geschützten Anwendung.
  • IMAGE_NAME: Der Name des aktiven Sicherungs-Images, das bereitgestellt werden soll.
  • MOUNT_POINT: (Optional) Der lokale Verzeichnispfad, in dem die Sicherung bereitgestellt wird. Der Standardwert ist /tmp/recovery_folder.

Nach Abschluss der Extraktion können Sie die gesicherten Daten im Verzeichnis des Bereitstellungspunkts ansehen.

Apps wiederherstellen

Wenn Sie auf Rohdatenbankdateien zugreifen möchten, rufen Sie MOUNT_POINT/restored_data/ auf. Wählen Sie den Wiederherstellungspfad für Ihren Arbeitslasttyp und Ihre Bereitstellungskonfiguration aus:

Microsoft SQL

  1. Dateien suchen: Suchen Sie im Verzeichnis db_volume/ nach den primären Datenbankdateien .mdf und .ldf.
  2. Direktes Anhängen (derselbe Host): Stoppen Sie die Zieldatenbankinstanz. Öffnen Sie SQL Server Management Studio, wählen Sie Attach Database (Datenbank anhängen) aus und geben Sie die Dateipfade zu den Daten- und Logdateien im Bereitstellungspunkt-Verzeichnis für die Wiederherstellung an.
  3. Kopieren und anhängen (anderer Host): Stoppen Sie die Zieldatenbankinstanz. Übertragen Sie die Dateien .mdf und .ldf auf die lokalen Speicherlaufwerke des Zielservers und hängen Sie sie dann mit SQL Server Management Studio an.

Oracle

  1. Dateien suchen: Das Dienstprogramm erkennt automatisch init.ora- oder spfile-Dateien und .dbf-Datendateien, während das RMAN-Datenbanksicherungs- und Archive log-Volumegruppen online geschaltet werden.
  2. Datenbank wiederherstellen: Fahren Sie die Oracle-Zielinstanz herunter oder starten Sie sie im NOMOUNT-Modus. Aktualisieren Sie entweder die Initialisierungsparameter (z. B. Kontrolldateien), sodass sie auf die bereitgestellten .dbf-Dateien für die direkte Validierung verweisen, oder kopieren Sie die .dbf-Dateien in den lokalen Speicher oder den ASM-Speicher (Automatic Storage Management) für die dauerhafte Wiederherstellung.
  3. Datenbank öffnen: Versetzen Sie die Instanz in den Status MOUNT, wenden Sie die erforderlichen Wiederherstellungsprotokolle aus der bereitgestellten TransactionLog-Lautstärkegruppe an und öffnen Sie dann die Datenbank.

VMware Engine-VM

Neben der Wiederherstellung von Datenbankanwendungen umfasst der Schutz virtueller Maschinen in Google Cloud VMware Engine (VMware Engine) die gesamte Hardwarekonfiguration sowie die virtuellen Festplatten.

  1. Dateien einbinden und suchen: Binden Sie das Sicherungs-Image ein, wie unter Sicherungs-Image einbinden beschrieben. Das Dienstprogramm generiert das Sparse-Laufwerk (vol00.raw) im primären Bereitstellungspfad. Anschließend wird das Laufwerk angehängt, um das Dateisystem des Gastbetriebssystems im Verzeichnis db_volume/ verfügbar zu machen. VMware-Konfigurationsmetadaten (einschließlich .ovf, .vmx und Catalog.xml) werden im Ordner log_files/ organisiert.
  2. VM direkt wiederherstellen: Deaktivieren Sie die Ziel-VM, um das Basis-Laufwerk für die Manifestanalyse zu sichern. Ein Worker-Prozess liest Datenblöcke aus dem lokalen Speicher, schreibt sie mit den VDDK-Bibliotheken (VMware Virtual Disk Development Kit) in die VMDK und startet die VM dann automatisch neu.

Compute Engine-Snapshots des nichtflüchtigen Speichers

Im Gegensatz zu OnVault-Sicherungen, die als lokale Dateisysteme bereitgestellt werden, werden Snapshots des nichtflüchtigen Speichers der Compute Engine wiederhergestellt, indem neue nichtflüchtige Speicher initialisiert und direkt an eine Compute Engine-Zielinstanz angehängt werden.

  1. Ziel-Backup und ‑Metadaten identifizieren: Prüfen Sie, ob die Metadatenkatalogdatei für Persistent Disk-Snapshots (pdsnapshot_catalog.json) in Ihrem Cloud Storage-Bucket vorhanden ist. Verwenden Sie das Dienstprogramm für die Verwaltung nichtflüchtiger Speicher, um die im Katalog aufgeführten verfügbaren Sicherungen zu prüfen und die spezifische IMAGE ID auszuwählen, die für die Wiederherstellung vorgesehen ist.
  2. Volumes wiederherstellen und anhängen: Verwenden Sie den Befehl attach, um die Erstellung von nichtflüchtigen Speichern aus Backup-Snapshots zu automatisieren. Mit dieser einzelnen Aktion werden alle relevanten Volumes erstellt und mit der Ziel-VM verbunden.
  3. Geräte auf Betriebssystemebene einbinden: Stellen Sie nach Abschluss des Anfügens eine Verbindung zur Compute Engine-Zielinstanz her, um die neu zugeordneten Blockgeräte mit Tools wie lsblk zu identifizieren. Stellen Sie die Dateisysteme manuell bereit, um auf die wiederhergestellten Daten zuzugreifen oder den Prozess zur Wiederherstellung der Anwendung zu starten.

SAP HANA PD

Im Gegensatz zu OnVault-Sicherungen, die direkt als lokale Dateisysteme bereitgestellt werden, müssen beim Wiederherstellen von SAP HANA-Snapshots des nichtflüchtigen Speichers neue nichtflüchtige Speicher bereitgestellt und an die Ziel-Compute Engine-Instanz angehängt werden.

  1. Metadaten prüfen und Sicherungsimage suchen: Prüfen Sie, ob die Metadatenkatalogdatei für Persistent Disk-Snapshots im Cloud Storage-Bucket verfügbar ist. Mit dem Tool für die Verwaltung nichtflüchtiger Speicher können Sie katalogisierte Sicherungen prüfen und die erforderliche IMAGE ID für die Wiederherstellung auswählen.
  2. Laufwerke bereitstellen und Volumes anhängen: Führen Sie den Befehl attach aus, um die Erstellung nichtflüchtiger Speicher aus dem ausgewählten Backup-Snapshot zu automatisieren. Bei diesem Schritt werden alle erforderlichen Volumes erstellt und in einem einzigen Vorgang an die Ziel-VM angehängt.
  3. Geräte auf Betriebssystemebene einhängen: Nachdem die Laufwerke angehängt wurden, stellen Sie eine Verbindung zur Ziel-VM für SAP HANA her und suchen Sie mit Tools wie lsblk nach neu zugewiesenen Blockgeräten. Stellen Sie die Dateisysteme manuell bereit, um auf wiederhergestellte Daten zuzugreifen oder die Wiederherstellung auf Anwendungsebene zu starten.
  4. SAP HANA wiederherstellen: Nachdem Sie die SAP HANA-Daten-, ‑Log- und ‑Archivlog-Volumes bereitgestellt haben, starten Sie die Systemdatenbank (einschließlich der Point-in-Time-Wiederherstellung, falls erforderlich), gefolgt von der Wiederherstellung und Initialisierung der Mandantendatenbanken.

IBM Db2 PD

Im Gegensatz zu OnVault-Sicherungen, die direkt als lokale Dateisysteme bereitgestellt werden, erfordert die Wiederherstellung von IBM Db2-Snapshots von nichtflüchtigem Speicher die Bereitstellung neuer nichtflüchtiger Speicher und das Anhängen an die Ziel-Compute Engine-Instanz.

  1. Sicherungsimage suchen und Metadaten validieren: Prüfen Sie, ob die Metadatenkatalogdatei für Persistent Disk-Snapshots im angegebenen Cloud Storage-Bucket vorhanden ist. Verwenden Sie das Tool „Persistent Disk Manager“, um die katalogisierten Sicherungen zu prüfen und das für die Wiederherstellung erforderliche Ziel-IMAGE ID zu identifizieren und auszuwählen.
  2. Volumes anhängen und Speicher bereitstellen: Führen Sie den Befehl attach aus, um automatisch nichtflüchtige Speicher aus dem angegebenen Sicherungssnapshot zu erstellen. In diesem einzelnen Schritt werden alle erforderlichen Volumes bereitgestellt und direkt an die Ziel-VM angehängt.
  3. Betriebssystemdateisysteme bereitstellen: Nachdem Sie die Laufwerke angehängt haben, stellen Sie eine Verbindung zur Ziel-VM für IBM Db2 her, um neu zugeordnete Blockgeräte mit Tools wie lsblk zu identifizieren. Stellen Sie die Dateisysteme manuell bereit, um auf wiederhergestellte Daten zuzugreifen oder mit der Anwendungs-Wiederherstellung fortzufahren.
  4. Anwendungsdatenbank wiederherstellen: Nachdem Sie die Db2-Datenträger für Daten, Transaktionslogs und Archivlogs bereitgestellt haben, katalogisieren Sie jede Db2-Datenbankinstanz, führen Sie bei Bedarf eine Datenbankwiederherstellung durch und stellen Sie die Datenbank online.

MySQL/MariaDB

  1. Dateien suchen: Suchen Sie das Hauptdatenverzeichnis in db_volume/, das Nutzerdatenbanken, das Systemschema und InnoDB-Tabellenbereiche enthält.

  2. Datenbank wiederherstellen: Stoppen Sie den aktiven MySQL- oder MariaDB-Dienst. Wenn Sie direkt testen möchten, passen Sie den datadir-Eintrag in my.cnf an, damit er auf den Mount-Ordner für die Wiederherstellung verweist. Für eine dauerhafte Wiederherstellung kopieren Sie die Datenbankdateien in den lokalen Speicher (z. B. /var/lib/mysql/) und sorgen Sie für die richtigen Dateisystemberechtigungen und den richtigen Inhaber.

  3. Online schalten und wiederherstellen: Starten Sie den Datenbankdienst neu. Wenn binäre Transaktionslogs vorhanden sind, führen Sie die Wiederherstellung zu einem bestimmten Zeitpunkt mit dem Dienstprogramm mysqlbinlog durch.

PostgreSQL

  1. Dateien suchen: Suchen Sie im Verzeichnis db_volume/ nach den PGDATA-Assets, einschließlich der Hauptdatenbanken (base/, global/ und pg_wal/) und der Konfigurationsdatei postgresql.conf.

  2. Datenbank wiederherstellen: Fahren Sie die PostgreSQL-Zielinstanz herunter. Wenn Sie die Validierung direkt über die Bereitstellung durchführen möchten, verweisen Sie die Umgebungsvariable data_directory oder PGDATA auf den Wiederherstellungspfad. Wenn Sie die Dateien dauerhaft wiederherstellen möchten, übertragen Sie die vollständige Verzeichnisstruktur in den lokalen Speicher des Zielhosts.

  3. Datenbank öffnen: Starten Sie den Dienst neu, um die Instanz online zu schalten. Wenn eine Wiederherstellung zu einem bestimmten Zeitpunkt erforderlich ist, wenden Sie archivierte WAL-Logs aus dem Ordner log_files/ an. Dazu definieren Sie eine recovery.conf-Datei oder konfigurieren restore_command in postgresql.conf (für PostgreSQL 12 und höher) und stellen dann die Datenbank online.

SAP ASE

  1. Dateien suchen: Identifizieren Sie das primäre Mastergerät sowie die spezifische Nutzerdatenbank und die Loggeräte, die sich im eingebundenen Ordner db_volume/ befinden.

  2. Datenbank wiederherstellen: Fahren Sie die Ziel-SAP ASE-Instanz herunter. Aktualisieren Sie für die direkte Einbindung die RUN_server-Konfiguration, um den Parameter des Mastergeräts (z. B. -d) zum Wiederherstellungspfad umzuleiten. Alternativ können Sie alle Geräte-Assets an ihre permanenten Speicherorte übertragen.

  3. Datenbank öffnen: Startet den SAP ASE-Datenserverprozess. Wenn Transaktionsprotokolle vorhanden sind, führen Sie den Vorgang LOAD TRAN aus, um eine Wiederherstellung zu einem bestimmten Zeitpunkt durchzuführen, bevor Sie die Datenbank online schalten.

SAP MaxDB

  1. Volumes suchen: Rufen Sie den db_volume/-Bereitstellungspfad auf, um die primären SAP MaxDB-Daten- und ‑Logdateien zu finden.

  2. Konfiguration wiederherstellen oder umleiten: Beenden Sie den Ziel-SAP MaxDB-Prozess. Verwenden Sie den Datenbankmanager (dbmcli), um Parameter wie DataVolumeName zu aktualisieren, damit sie auf den Wiederherstellungs-Mount verweisen, oder kopieren Sie die Dateien direkt in den lokalen Speicher, um eine vollständige Wiederherstellung durchzuführen.

  3. Starten und online schalten: Starten Sie die Datenbankinstanz und legen Sie ihren Betriebsstatus mit dem Database Manager auf ONLINE fest.

SAP IQ

  1. Dateien suchen: Rufen Sie das Verzeichnis db_volume/ auf, um den primären SAP IQ-Hauptspeicher, den Katalogspeicher (.db) und alle zugehörigen temporären Speicher-Assets zu identifizieren.

  2. Datenbank wiederherstellen: Fahren Sie die SAP IQ-Zielinstanz herunter. Wenn Sie die direkte Validierung über den Wiederherstellungs-Mount durchführen möchten, ändern Sie die Startparameter so, dass auf die gemountete Katalogdatei verwiesen wird. Für die dauerhafte Wiederherstellung übertragen Sie alle Speichervolumes in den lokalen Speicher und prüfen Sie, ob die entsprechenden Dateisystemberechtigungen beibehalten werden.

  3. Datenbank öffnen: Führen Sie das start_iq-Dienstprogramm aus, um die Instanz online zu schalten und die Datenintegrität zu überprüfen.

IBM Db2 LVM/Dump

  1. Dateien suchen: Rufen Sie die Mount-Pfade db_volume/ und log_files/ auf. Identifizieren Sie je nach Schutzmethode entweder die LVM-Daten- und ‑Log-Volumes oder die spezifischen Backup-Image-Assets für die dumpbasierte Wiederherstellung.
  2. Datenbank wiederherstellen (LVM): Fahren Sie die Db2-Zielinstanz herunter. Übertragen Sie die Datenbankdaten und aktiven Transaktionsprotokollvolumes vom Wiederherstellungs-Mount in den lokalen Zielspeicher und achten Sie dabei auf die korrekte Dateisystemberechtigung für den Db2-Nutzer und die Db2-Gruppe.
  3. Datenbank wiederherstellen (dumpbasiert, vollständig und inkrementell): Aktive Verbindungen werden beendet und die Zieldatenbank wird gelöscht, sofern sie vorhanden ist. Verwenden Sie das db2ckrst-Tool mit dem spezifischen Sicherungszeitstempel, um die erforderliche inkrementelle Sequenz zu katalogisieren. Führen Sie den Vorgang RESTORE für jedes Bild in der vorgeschriebenen Reihenfolge aus.
  4. Datenbank öffnen: Starten Sie die Db2-Instanz. Wenn die Datenbank im Status „Ausstehend“ verbleibt oder eine Wiederherstellung zu einem bestimmten Zeitpunkt erforderlich ist, wenden Sie die Transaktionsprotokolle mit dem Dienstprogramm db2 rollforward an, um die Wiederherstellung abzuschließen und die Instanz online zu schalten.

Ressourcen bereinigen

Nachdem Sie alle erforderlichen Datenbankdateien aus der Datenbank-Engine kopiert oder getrennt haben, hängen Sie die aktiven Volumes sicher aus, trennen Sie alle zugehörigen Loop-Geräte und entfernen Sie lokale Staging-Verzeichnisse, um verbleibende Sperren oder verwaiste Referenzen zu vermeiden.

Führen Sie die folgenden Befehle aus, um Volumes zu trennen und das Wiederherstellungsverzeichnis zu bereinigen:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

Ersetzen Sie Folgendes:

  • MOUNT_POINT: Der lokale Verzeichnispfad, in dem die Sicherung bereitgestellt wurde, z. B. /tmp/recovery_folder.

Nächste Schritte