Chaque fois que vous apportez des modifications à votre MAS système, vous avez besoin d'un plan d'urgence solide. Si quelque chose ne va pas, comment allez-vous vous en remettre ?

L'objectif est de réduire les risques autant que possible et d'éviter de laisser votre environnement en mauvais état.

Deux approches des sauvegardes MAS

IBM propose deux approches principales :
‍

‍

Le premier concerne les scripts GitHub, qui existent depuis quelques années.

La deuxième option est plus récente : deux rôles Ansible qui viennent d'être publiés en mars 2026.

Examinons les deux et voyons comment ils se comparent.

Méthode 1 : scripts Github

Des scripts de sauvegarde dédiés sont disponibles pour Core (mascore-backup-restore.sh) et Manage (manage-backup-restore.sh). Ces scripts sont disponibles dans GitHub et sont également intégrés directement dans la CLI MAS, ce qui facilite leur accès et leur exécution.
‍

Localisez les scripts de sauvegarde MAS Core et Manage dans la CLI MAS à l'adresse mascli/backup-restore.
‍

‍

Accès au cluster requis

Les scripts interagissent directement avec les espaces de noms et les ressources MAS, ce qui nécessite un accès administrateur au cluster OpenShift.

Rassemblez les paramètres

L'espace de noms contient la plupart des paramètres dont vous aurez besoin pour exécuter ces scripts.
‍

‍

Exécutez la sauvegarde MAS Core

Pour exécuter mascore-backup-restore.sh, indiquez l'emplacement du script, l'ID d'instance, l'emplacement vers lequel vous souhaitez que les fichiers soient sauvegardés et le mode.
‍

‍
Inspectez tous les fichiers de sauvegarde pour vérifier que toutes les ressources ont été correctement sauvegardées.

Exécutez la gestion de la sauvegarde

Utilisez les mêmes paramètres pour exécuter manage-backup-restore.sh, y compris l'ID de l'espace de travail.
‍

‍

Méthode 2 : rôles Ansible

Nouvelles commandes de sauvegarde et de restauration de la CLI MAS

À compter de la version 36.0.0 de MAS, l'interface de ligne de commande MAS inclut des commandes de sauvegarde et de restauration améliorées qui s'intègrent à OpenShift Pipelines.
‍

‍

Avant de nous lancer dans l'exécution du sauvegarde du mas commande, il est important de comprendre les options disponibles.
‍

Il en existe 32 différents paramètres, mais ils peuvent vraiment être regroupés en six domaines clés :

• Quelle instance sauvegardons-nous ?

• Comment voulons-nous configurer la sauvegarde ?

• Où sera stockée la sauvegarde ?

• Quelles sont les applications incluses ?

• Quels composants sont sauvegardés ?

• La sauvegarde implique-t-elle des dépendances sous-jacentes ou des options avancées ?
  ‍

‍

Exécution de la sauvegarde MAS dans la CLI MAS

La commande de sauvegarde MAS ci-dessous inclut l'application Manage, qui nécessite toujours la spécification de l'ID de l'espace de travail. Il comprend également SLS et spécifie l'espace de noms dans lequel il est installé.
‍

Les premières fois que j'ai exécuté cette commande, elle a échoué presque immédiatement lors de la tâche de vérification préalable à la sauvegarde.
‍

La vérification préalable à la sauvegarde valide l'état de santé de chaque composant du cluster OpenShift, ce qui n'est pas idéal lorsque vous essayez simplement d'exécuter une sauvegarde ciblée. Utilisez le paramètre --ski-pre-check pour le contourner.
‍

‍

Une fois la sauvegarde lancée, certaines choses se passent en coulisse.
‍

L'opérateur OpenShift Pipelines est installé dans l'espace de noms Core, puis dans l'espace de noms Manage puisqu'il a été inclus dans la sauvegarde, et il crée également un espace dédié Canalisations espace de noms où l'opérateur est également installé.
‍

Il ne s'agit donc pas simplement d'une sauvegarde, mais d'une modification de votre cluster.
‍

‍

Au fur et à mesure que la sauvegarde progresse et installe ses dépendances, un lien vers Pipeline Run est fourni dans la fenêtre de la CLI MAS.
‍

À partir de ce moment, vous devrez continuer à surveiller la sauvegarde directement depuis le cluster OpenShift.
‍

Le Pipeline Run vous permet de visualiser étape par étape l'ensemble du processus de sauvegarde, de la validation au téléchargement final, afin que vous puissiez suivre la progression en temps réel.
‍

‍
Limites de la sauvegarde MAS

• Certaines classes de stockage et certains modes d'accès ne sont pas pris en charge dans certains environnements (par exemple, SNO, AWS, Azure).

• Seule l'édition communautaire de MongoDB est prise en charge.

• Les vérifications préalables à la sauvegarde analysent l'ensemble du cluster, mais elles peuvent être ignorées.

‍