Jedes Mal, wenn Sie Änderungen an Ihrem vornehmen MAS System, Sie benötigen einen soliden Notfallplan. Wie werden Sie sich erholen, wenn etwas schief geht?

Das Ziel dabei ist es, das Risiko so weit wie möglich zu reduzieren und zu vermeiden, dass Ihre Umgebung in einem defekten Zustand bleibt.

Zwei Ansätze für MAS-Backups

IBM bietet zwei Hauptansätze:
‍

‍

Das erste sind GitHub-Skripte, die es schon seit ein paar Jahren gibt.

Die zweite Option ist neuer: zwei Ansible-Rollen, die gerade im März 2026 veröffentlicht wurden.

Schauen wir uns beide an und sehen, wie sie sich vergleichen.

Methode 1: Github-Skripte

Dedizierte Backup-Skripte sind sowohl für Core (mascore-backup-restore.sh) als auch für Manage (manage-backup-restore.sh) verfügbar. Diese Skripte sind verfügbar in GitHub und sind auch direkt in der MAS-CLI gebündelt, sodass sie leicht zugänglich und ausgeführt werden können.
‍

Suchen Sie die MAS Core- und Manage-Backup-Skripte in der MAS-CLI unter mascli/backup-restore.
‍

‍

Cluster-Zugriff erforderlich

Die Skripte interagieren direkt mit MAS-Namespaces und Ressourcen und erfordern Administratorzugriff auf den OpenShift-Cluster.

Parameter erfassen

Der Namespace enthält die meisten Parameter, die Sie zur Ausführung dieser Skripts benötigen.
‍

‍

Führen Sie das MAS Core Backup aus

Um mascore-backup-restore.sh auszuführen, geben Sie den Speicherort des Skripts, die Instanz-ID, den Speicherort, an dem die Dateien gesichert werden sollen, und den Modus an.
‍

‍
Überprüfen Sie alle Sicherungsdateien, um sicherzustellen, dass alle Ressourcen erfolgreich gesichert wurden.

Führen Sie das Manage-Backup aus

Verwenden Sie dieselben Parameter, um manage-backup-restore.sh auszuführen, einschließlich der Workspace-ID.
‍

‍

Methode 2: Ansible-Rollen

Neue MAS-CLI-Befehle zum Sichern und Wiederherstellen

Ab MAS-Version 36.0.0 enthält die MAS-CLI erweiterte Sicherungs- und Wiederherstellungsbefehle, die in OpenShift Pipelines integriert werden können.
‍

‍

Bevor wir uns mit der Ausführung der befassen Mas-Backup Befehl, es ist wichtig, die verfügbaren Optionen zu verstehen.
‍

Es gibt 32 verschiedene Parameter, aber sie lassen sich wirklich in sechs Schlüsselbereiche einteilen:

• Für welche Instanz sichern wir?

• Wie wollen wir das Backup konfigurieren?

• Wo wird das Backup gespeichert?

• Welche Anwendungen sind enthalten?

• Welche Komponenten werden gesichert?

• Gibt es irgendwelche zugrunde liegenden Abhängigkeiten oder erweiterte Optionen, die mit dem Backup verbunden sind?
  ‍

‍

Mas-Backup innerhalb der MAS-CLI ausführen

Der folgende MAS-Backup-Befehl beinhaltet die Anwendung Manage, für die immer noch die Angabe der Workspace-ID erforderlich ist. Er beinhaltet auch SLS und gibt den Namespace an, in dem es installiert ist.
‍

Die ersten Male, als ich diesen Befehl ausgeführt habe, ist er während der Pre-Backup-Check-Aufgabe fast sofort fehlgeschlagen.
‍

Der Pre-Backup-Check überprüft den Zustand aller Komponenten im OpenShift-Cluster, was nicht ideal ist, wenn Sie nur versuchen, ein gezieltes Backup durchzuführen. Verwenden Sie den Parameter --ski-pre-check, um ihn zu umgehen.
‍

‍

Sobald das Backup gestartet ist, passieren einige Dinge hinter den Kulissen.
‍

Der OpenShift Pipelines Operator wird im Core-Namespace und dann im Manage-Namespace installiert, da er im Backup enthalten war, und er erstellt auch einen dedizierten Rohrleitungen Namespace, in dem der Operator ebenfalls installiert ist.
‍

Das ist also nicht nur ein Backup — es nimmt Änderungen an Ihrem Cluster vor.
‍

‍

Während das Backup fortschreitet und seine Abhängigkeiten installiert, wird ein Link zu Pipeline-Lauf wird im MAS-CLI-Fenster bereitgestellt.
‍

Ab diesem Zeitpunkt müssen Sie das Backup weiterhin direkt vom OpenShift-Cluster aus überwachen.
‍

Der Pipeline-Lauf zeigt Ihnen Schritt für Schritt den gesamten Backup-Prozess — von der Validierung bis zum endgültigen Upload —, sodass Sie den Fortschritt in Echtzeit verfolgen können.
‍

‍
Einschränkungen von MAS Backup

• Einige Speicherklassen und Zugriffsmodi werden in bestimmten Umgebungen nicht unterstützt (z. B. SNO, AWS, Azure).

• Nur die MongoDB Community Edition wird unterstützt.

• Prüfungen vor dem Backup scannen den gesamten Cluster, können aber übersprungen werden.

‍