Sauvegarde et restauration


Red Hat OpenShift Service on AWS 4

Sauvegarde et restauration de votre Red Hat OpenShift Service sur AWS cluster

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des instructions pour sauvegarder les données de votre cluster et pour récupérer à partir de divers scénarios de catastrophe.

Chapitre 1. La sauvegarde et la restauration de l’application OADP

1.1. Introduction à {oadp-full}

Le produit OpenShift API for Data Protection (OADP) protège les applications client sur Red Hat OpenShift Service sur AWS. Il offre une protection complète contre la reprise après sinistre, couvrant le service Red Hat OpenShift sur les applications AWS, les ressources de cluster liées aux applications, les volumes persistants et les images internes. L’OADP est également capable de sauvegarder les applications conteneurisées et les machines virtuelles (VM).

Le support OADP est fourni aux espaces de noms de la charge de travail des clients et aux ressources de portée de cluster.

La sauvegarde et la restauration du cluster complet ne sont pas prises en charge.

1.1.1. API OpenShift pour les API de protection des données

L’API OpenShift pour la protection des données (OADP) fournit des API qui permettent de multiples approches pour personnaliser les sauvegardes et empêcher l’inclusion de ressources inutiles ou inappropriées.

L’OADP fournit les API suivantes:

1.1.1.1. Assistance pour OpenShift API pour la protection des données
Tableau 1.1. Les versions supportées de OADP

La version

La version OCP

Disponibilité générale

Fin du support complet

Fin de l’entretien

Appui à la mise à jour étendue (EUS)

Extension du support de mise à jour Term 2 (EUS Term 2)

1.4

  • 4.14
  • 4.15
  • 4.16

10 juil 2024

Libération de 1,5

Libération de 1.6

27 juin 2026

L’EUS doit être sur OCP 4.16

27 juin 2027

La clause 2 de l’EUS doit être sur OCP 4.16

1.3

  • 4.12
  • 4.13
  • 4.14
  • 4.15

29 nov 2023

10 juil 2024

Libération de 1,5

31 oct 2025

L’EUS doit être sur OCP 4.14

31 oct 2026

La clause 2 de l’EUS doit être sur OCP 4.14

1.1.1.1.1. Les versions non prises en charge de l’opérateur OADP
Tableau 1.2. Les versions précédentes de l’opérateur OADP qui ne sont plus pris en charge

La version

Disponibilité générale

Le soutien complet a pris fin

Fin de la maintenance

1.2

14 juin 2023

29 nov 2023

10 juil 2024

1.1

01 septembre 2022

14 juin 2023

29 nov 2023

1.0

09 fév 2022

01 septembre 2022

14 juin 2023

En savoir plus sur EUS, consultez le support de mise à jour étendue.

En savoir plus sur la clause 2 de l’EUS, voir Extended Update Support Term 2.

1.2. Les notes de sortie de l’OADP

1.2.1. Les notes de sortie de OADP 1.4

Les notes de publication de l’API OpenShift pour la protection des données (OADP) décrivent de nouvelles fonctionnalités et améliorations, des fonctionnalités dépréciées, des recommandations de produits, des problèmes connus et des problèmes résolus.

Note

En savoir plus sur OADP, consultez la FAQ OpenShift API for Data Protection (OADP)

1.2.1.1. 1.4.3 notes de publication OADP

L’API OpenShift pour la protection des données (OADP) 1.4.3 répertorie la nouvelle fonctionnalité suivante.

1.2.1.1.1. De nouvelles fonctionnalités

Changements notables dans le plugin kubevirt velero dans la version 0.7.1

Avec cette version, le plugin kubevirt velero a été mis à jour à la version 0.7.1. Les améliorations notables incluent les corrections de bogues suivantes et les nouvelles fonctionnalités:

  • Les instances de machine virtuelle (IMV) ne sont plus ignorées de la sauvegarde lorsque le VM propriétaire est exclu.
  • Les graphiques d’objets incluent désormais tous les objets supplémentaires lors des opérations de sauvegarde et de restauration.
  • Les étiquettes générées en option sont désormais ajoutées aux nouveaux identifiants universellement uniques (UUID) lors des opérations de restauration.
  • Changer de stratégie d’exécution de VM lors des opérations de restauration est maintenant possible.
  • Effacer une adresse MAC par étiquette est maintenant pris en charge.
  • Les vérifications spécifiques à la restauration au cours de l’opération de sauvegarde sont maintenant ignorées.
  • Les définitions de ressources personnalisées VirtualMachineClusterInstancetype et VirtualMachineClusterPreference (CRD) sont maintenant prises en charge.
1.2.1.2. 1.4.2 notes de publication

L’API OpenShift pour la protection des données (OADP) 1.4.2 répertorie les nouvelles fonctionnalités, les problèmes et les bogues résolus et les problèmes connus.

1.2.1.2.1. De nouvelles fonctionnalités

La sauvegarde de différents volumes dans le même espace de noms en utilisant la fonction VolumePolicy est maintenant possible

Avec cette version, Velero fournit des stratégies de ressources pour sauvegarder différents volumes dans le même espace de noms en utilisant la fonctionnalité VolumePolicy. La fonction VolumePolicy prise en charge pour sauvegarder différents volumes comprend des actions de skip, snapshot et fs-backup. À PROPOS DE OADP-1071

La sauvegarde du système de fichiers et le déplacement de données peuvent maintenant utiliser des informations d’identification à court terme

La sauvegarde du système de fichiers et le déplacement de données peuvent désormais utiliser des informations d’identification à court terme telles que AWS Security Token Service (STS) et GCP WIF. Avec ce support, la sauvegarde est terminée avec succès sans aucun statut PartiallyFailed. À PROPOS DE OADP-5095

1.2.1.2.2. Des problèmes résolus

DPA signale maintenant des erreurs si VSL contient une valeur de fournisseur incorrecte

Auparavant, si le fournisseur d’une spécification d’emplacement des prises de vue de volume (VSL) était incorrect, l’application de protection des données (DPA) s’est réconciliée avec succès. Avec cette mise à jour, DPA signale les erreurs et les demandes d’une valeur fournisseur valide. À PROPOS DE OADP-5044

La restauration de data Mover réussit indépendamment de l’utilisation de différents espaces de noms OADP pour la sauvegarde et la restauration

Auparavant, lorsque l’opération de sauvegarde a été exécutée en utilisant OADP installé dans un espace de noms, mais a été restauré en utilisant OADP installé dans un espace de noms différent, la restauration de Data Mover a échoué. Avec cette mise à jour, la restauration de Data Mover est maintenant réussie. À PROPOS DE OADP-5460

La sauvegarde SSE-C fonctionne avec le MD5 calculé de la clé secrète

Auparavant, la sauvegarde a échoué avec l’erreur suivante:

Requests specifying Server Side Encryption with Customer provided keys must provide the client calculated MD5 of the secret key.
Copy to Clipboard

Avec cette mise à jour, le chiffrement de chiffrement de serveur manquant avec les clés fournies par le client (SSE-C) base64 et MD5 hachage sont maintenant corrigés. En conséquence, la sauvegarde SSE-C fonctionne avec le MD5 calculé de la clé secrète. En outre, une mauvaise gestion des erreurs pour la taille de la clé client est également corrigée. À PROPOS DE OADP-5388

En ce qui concerne la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.

1.2.1.2.3. Problèmes connus

La spécification nodeSelector n’est pas prise en charge pour l’action de restauration de Data Mover

Lorsqu’une application de protection des données (DPA) est créée avec le champ nodeSelector défini dans le paramètre nodeAgent, la restauration de Data Mover échoue partiellement au lieu de terminer l’opération de restauration. À PROPOS DE OADP-5260

Le stockage S3 n’utilise pas d’environnement proxy lorsque la vérification TLS est spécifiée

Dans la sauvegarde du registre d’images, le stockage S3 n’utilise pas l’environnement proxy lorsque le paramètre insecureSkipTLSVerify est défini sur true. À PROPOS DE OADP-3143

Kopia ne supprime pas les artefacts après l’expiration de la sauvegarde

Dès que vous avez supprimé une sauvegarde, Kopia ne supprime pas les artefacts de volume du ${bucket_name}/kopia/$openshift-adp sur l’emplacement S3 après l’expiration de la sauvegarde. En savoir plus, voir « À propos de la maintenance du référentiel Kopia ». À PROPOS DE OADP-5131

1.2.1.3. 1.4.1 notes de publication OADP 1.4.1

L’API OpenShift pour la protection des données (OADP) 1.4.1 répertorie les nouvelles fonctionnalités, les problèmes et les bogues résolus et les problèmes connus.

1.2.1.3.1. De nouvelles fonctionnalités

De nouveaux champs DPA pour mettre à jour les qps et l’éclatement du client

Désormais, vous pouvez modifier les requêtes API Velero Server Kubernetes par seconde et les valeurs d’éclatement à l’aide des nouveaux champs d’application de protection des données (DPA). Les nouveaux champs DPA sont spec.configuration.velero.client-qps et spec.configuration.velero.client-burst, qui par défaut à 100. À PROPOS DE OADP-4076

Activer les algorithmes non par défaut avec Kopia

Avec cette mise à jour, vous pouvez maintenant configurer les algorithmes de hachage, de chiffrement et de fractionneur dans Kopia pour sélectionner des options non par défaut afin d’optimiser les performances pour différentes charges de travail de sauvegarde.

Afin de configurer ces algorithmes, définissez la variable env d’un pod velero dans la section podConfig de la configuration DataProtectionApplication (DPA). Lorsque cette variable n’est pas définie ou qu’un algorithme non pris en charge est choisi, Kopia par défaut à ses algorithmes standard. À PROPOS DE OADP-4640

1.2.1.3.2. Des problèmes résolus

La restauration d’une sauvegarde sans pods est maintenant réussie

Auparavant, restaurer une sauvegarde sans pods et avoir StorageClass VolumeBindingMode défini comme WaitForFirstConsumer, a abouti à l’état PartiallyFailed avec une erreur: ne pas corriger PV dynamique, erreur: la date limite de contexte dépassée. Avec cette mise à jour, le patching dynamique PV est ignoré et la restauration d’une sauvegarde est réussie sans aucun statut PartiallyFailed. À PROPOS DE OADP-4231

Le PodVolumeBackup CR affiche maintenant le message correct

Auparavant, la ressource personnalisée PodVolumeBackup (CR) a généré un message incorrect, qui était: obtenir un podvolumebackup avec le statut "InProgress" pendant le démarrage du serveur, le marquer comme "Failed". Avec cette mise à jour, le message produit est maintenant:

found a podvolumebackup with status "InProgress" during the server starting,
mark it as "Failed".
Copy to Clipboard

À PROPOS DE OADP-4224

Image dominantePullPolicy est maintenant possible avec DPA

Auparavant, OADP a défini le paramètre imagePullPolicy sur Toujours pour toutes les images. Avec cette mise à jour, OADP vérifie si chaque image contient sha256 ou sha512 digest, puis il définit imagePullPolicy sur IfNotPresent; sinon imagePullPolicy est définie sur Always. Désormais, vous pouvez remplacer cette politique en utilisant le nouveau champ DPA spec.containerImagePullPolicy. À PROPOS DE OADP-4172

L’OADP Velero peut maintenant réessayer la mise à jour de l’état de restauration si la mise à jour initiale échoue

Auparavant, OADP Velero n’a pas réussi à mettre à jour l’état CR restauré. Cela a laissé le statut à InProgress indéfiniment. Les composants qui se sont appuyés sur la sauvegarde et restaurer l’état CR pour déterminer l’achèvement échoueraient. Avec cette mise à jour, l’état de restauration CR pour une restauration procède correctement à l’état terminé ou échoué. À PROPOS DE OADP-3227

La restauration de BuildConfig Build à partir d’un cluster différent est réussie sans aucune erreur

Auparavant, lors de la restauration de la ressource BuildConfig Build à partir d’un cluster différent, l’application a généré une erreur sur la vérification TLS dans le registre d’images interne. L’erreur résultante n’a pas permis de vérifier le certificat: x509: certificat signé par une erreur d’autorité inconnue. Avec cette mise à jour, la restauration des ressources de construction BuildConfig vers un cluster différent peut se dérouler avec succès sans générer l’erreur de vérification du certificat manquée. À PROPOS DE OADP-4692

La restauration d’un PVC vide est un succès

Auparavant, le téléchargement des données a échoué lors de la restauration d’une revendication de volume persistant vide (PVC). Il a échoué avec l’erreur suivante:

data path restore failed: Failed to run kopia restore: Unable to load
    snapshot : snapshot not found
Copy to Clipboard

Avec cette mise à jour, le téléchargement des données permet de corriger la conclusion lors de la restauration d’un PVC vide et le message d’erreur n’est pas généré. À PROPOS DE OADP-3106

Il n’y a pas de fuite de mémoire Velero dans les plugins CSI et DataMover

Auparavant, une fuite de mémoire Velero était causée par l’utilisation des plugins CSI et DataMover. Lorsque la sauvegarde a pris fin, l’instance du plugin Velero n’a pas été supprimée et la fuite de mémoire consommée de la mémoire jusqu’à ce qu’une condition de sortie de mémoire (OOM) soit générée dans le pod Velero. Avec cette mise à jour, il n’y a pas de fuite de mémoire Velero résultante lors de l’utilisation des plugins CSI et DataMover. À PROPOS DE OADP-4448

L’opération post-hook ne commence pas avant que les PV associés ne soient libérés

Auparavant, en raison de la nature asynchrone de l’opération Data Mover, un post-hook pourrait être tenté avant que la revendication de volume persistant (PVC) de Data Mover ne libère les volumes persistants (PVs) des gousses associées. Ce problème entraînerait l’échec de la sauvegarde avec un statut PartiallyFailed. Avec cette mise à jour, l’opération post-hook n’est pas commencée avant que les PV associés soient libérés par le Data Mover PVC, éliminant ainsi l’état de sauvegarde PartiallyFailed. L’OADP-3140

Déployer un DPA fonctionne comme prévu dans les espaces de noms avec plus de 37 caractères

Lorsque vous installez l’opérateur OADP dans un espace de noms avec plus de 37 caractères pour créer un nouveau DPA, l’étiquetage « Cloud-credentials » Secret échoue et le DPA signale l’erreur suivante:

The generated label name is too long.
Copy to Clipboard

Avec cette mise à jour, la création d’un DPA ne échoue pas dans les espaces de noms avec plus de 37 caractères dans le nom. À PROPOS DE OADP-3960

La restauration est terminée avec succès en surmontant l’erreur de délai d’expiration

Auparavant, dans un environnement à grande échelle, l’opération de restauration se traduirait par un statut partiellement échoué avec l’erreur: ne pas corriger le PV dynamique, erreur: délai de contexte dépassé. Avec cette mise à jour, l’argument du serveur ResourceTimeout Velero est utilisé pour remplacer cette erreur de temps d’attente résultant d’une restauration réussie. À PROPOS DE OADP-4344

En ce qui concerne la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.

1.2.1.3.3. Problèmes connus

Les pods d’application Cassandra entrent dans le statut CrashLoopBackoff après avoir restauré OADP

Après les restaurations OADP, les pods d’application Cassandra peuvent entrer dans le statut CrashLoopBackoff. Afin de contourner ce problème, supprimez les pods StatefulSet qui renvoient l’état d’erreur CrashLoopBackoff après avoir restauré OADP. Le contrôleur StatefulSet recrée ensuite ces pods et il fonctionne normalement. À PROPOS DE OADP-4407

Le référencement de déploiement ImageStream n’est pas restauré correctement conduisant à des contenus de pod et de volume corrompus

Lors d’une opération de restauration de système de fichiers (FSB), une ressource de déploiement faisant référence à un ImageStream n’est pas restaurée correctement. La gousse restaurée qui exécute le FSB, et le postHook est interrompu prématurément.

Lors de l’opération de restauration, le contrôleur OpenShift Container Platform met à jour le champ spec.template.spec.containers dans la ressource Déploiement avec un hachage ImageStreamTag mis à jour. La mise à jour déclenche le déploiement d’un nouveau pod, mettant fin à la gousse sur laquelle velero exécute le FSB avec le post-hook. En savoir plus sur le déclencheur du flux d’images, consultez les mises à jour sur les changements de flux d’image.

La solution de contournement de ce comportement est un processus de restauration en deux étapes:

  1. Effectuez une restauration à l’exclusion des ressources de déploiement, par exemple:

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --exclude-resources=deployment.apps
    Copy to Clipboard
  2. Lorsque la première restauration est couronnée de succès, effectuez une deuxième restauration en incluant ces ressources, par exemple:

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --include-resources=deployment.apps
    Copy to Clipboard

    À PROPOS DE OADP-3954

1.2.1.4. Les notes de sortie de OADP 1.4.0

L’API OpenShift pour la protection des données (OADP) 1.4.0 liste les problèmes résolus et les problèmes connus.

1.2.1.4.1. Des problèmes résolus

La restauration fonctionne correctement dans Red Hat OpenShift Service sur AWS 4.16

Auparavant, lors de la restauration de l’espace de noms de l’application supprimée, l’opération de restauration a partiellement échoué avec le nom de ressource peut ne pas être une erreur vide dans Red Hat OpenShift Service sur AWS 4.16. Avec cette mise à jour, la restauration fonctionne comme prévu dans Red Hat OpenShift Service sur AWS 4.16. À PROPOS DE OADP-4075

Les sauvegardes de Mover de données fonctionnent correctement dans le Red Hat OpenShift Service sur AWS 4.16 cluster

Auparavant, Velero utilisait la version antérieure du SDK où le champ Spec.SourceVolumeMode n’existait pas. En conséquence, les sauvegardes de Data Mover ont échoué dans le Red Hat OpenShift Service sur le cluster AWS 4.16 sur le snapshotter externe avec la version 4.2. Avec cette mise à jour, snapshotter externe est mis à niveau vers la version 7.0 et ultérieure. En conséquence, les sauvegardes ne échouent pas dans le Red Hat OpenShift Service sur AWS 4.16 cluster. À PROPOS DE OADP-3922

Consultez la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.

1.2.1.4.2. Problèmes connus

La sauvegarde échoue lorsque checkumAlgorithm n’est pas défini pour MCG

Lors de l’exécution d’une sauvegarde de n’importe quelle application avec Noobaa comme emplacement de sauvegarde, si le paramètre de configuration checksumAlgorithm n’est pas défini, la sauvegarde échoue. Afin de résoudre ce problème, si vous ne fournissez pas de valeur pour checkumAlgorithm dans la configuration de l’emplacement de stockage de sauvegarde (BSL), une valeur vide est ajoutée. La valeur vide n’est ajoutée que pour les BSL créés à l’aide d’une ressource personnalisée (CR) de l’application de protection des données (DPA), et cette valeur n’est pas ajoutée si les BSL sont créés en utilisant une autre méthode. À PROPOS DE OADP-4274

Consultez la liste complète de tous les problèmes connus dans cette version, consultez la liste des problèmes connus OADP 1.4.0 dans Jira.

1.2.1.4.3. Améliorer les notes
Note

Effectuez toujours une mise à niveau vers la prochaine version mineure. Il ne faut pas sauter les versions. Afin de mettre à jour une version ultérieure, mettre à niveau un seul canal à la fois. À titre d’exemple, pour passer de l’API OpenShift pour la protection des données (OADP) 1.1 à 1.3, mettre à niveau d’abord vers 1.2, puis vers 1.3.

1.2.1.4.3.1. Changements de OADP 1.3 à 1.4

Le serveur Velero a été mis à jour de la version 1.12 à 1.14. A noter qu’il n’y a pas de changements dans l’application de protection des données (DPA).

Cela change ce qui suit:

  • Le code velero-plugin-for-csi est maintenant disponible dans le code Velero, ce qui signifie qu’un conteneur d’init n’est plus nécessaire pour le plugin.
  • Le client Burst et le QPS sont passés de 30 et 20 à 100 et 100 respectivement.
  • Le plugin velero-plugin-for-aws a mis à jour la valeur par défaut du champ spec.config.checksumAlgorithm dans les objets BackupStorageLocation (BSL) de "" (pas de calcul de somme de contrôle) à l’algorithme CRC32. Les types d’algorithmes de somme de contrôle sont connus pour fonctionner uniquement avec AWS. De nombreux fournisseurs S3 exigent que le md5sum soit désactivé en définissant l’algorithme de somme de contrôle sur "". Confirmez la prise en charge et la configuration de l’algorithme md5sum avec votre fournisseur de stockage.

    Dans OADP 1.4, la valeur par défaut pour les BSL créés dans DPA pour cette configuration est "". Cette valeur par défaut signifie que le md5sum n’est pas vérifié, ce qui est compatible avec OADP 1.3. Dans le cas des BSL créés dans DPA, mettez-le à jour en utilisant le champ spec.backupLocations[].velero.config.checksumAlgorithm dans le DPA. Lorsque vos BSL sont créés en dehors du DPA, vous pouvez mettre à jour cette configuration en utilisant spec.config.checksumAlgorithm dans les BSL.

1.2.1.4.3.2. Sauvegarde de la configuration DPA

Il faut sauvegarder la configuration actuelle de DataProtectionApplication (DPA).

Procédure

  • Enregistrez votre configuration DPA actuelle en exécutant la commande suivante:

    Commande d’exemple

    $ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
    Copy to Clipboard

1.2.1.4.3.3. Améliorer l’opérateur OADP

Utilisez la procédure suivante lors de la mise à niveau de l’opérateur OpenShift API for Data Protection (OADP).

Procédure

  1. Changez votre canal d’abonnement pour l’opérateur OADP de stable-1.3 à stable-1.4.
  2. Attendez que l’opérateur et les conteneurs mettent à jour et redémarrent.
1.2.1.4.4. Conversion du DPA à la nouvelle version

Afin de passer de OADP 1.3 à 1.4, aucune modification d’application de protection des données (DPA) n’est requise.

1.2.1.4.5. La vérification de la mise à niveau

La procédure suivante permet de vérifier la mise à niveau.

Procédure

  1. Contrôlez l’installation en consultant les ressources OpenShift API for Data Protection (OADP) en exécutant la commande suivante:

    $ oc get all -n openshift-adp
    Copy to Clipboard

    Exemple de sortie

    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/restic-9cq4q                                         1/1     Running   0          94s
    pod/restic-m4lts                                         1/1     Running   0          94s
    pod/restic-pv4kr                                         1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    
    NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/restic   3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard

  2. Assurez-vous que la DataProtectionApplication (DPA) est réconciliée en exécutant la commande suivante:

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    Copy to Clipboard

    Exemple de sortie

    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
    Copy to Clipboard

  3. Assurez-vous que le type est défini sur Reconciled.
  4. Vérifiez l’emplacement de stockage de sauvegarde et confirmez que le PHASE est disponible en exécutant la commande suivante:

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    Copy to Clipboard

    Exemple de sortie

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
    Copy to Clipboard

1.3. La performance de l’OADP

1.4. Fonctionnalités et plugins OADP

Les fonctionnalités OpenShift API for Data Protection (OADP) offrent des options pour sauvegarder et restaurer les applications.

Les plugins par défaut permettent à Velero de s’intégrer à certains fournisseurs de cloud et de sauvegarder et restaurer Red Hat OpenShift Service sur les ressources AWS.

1.4.1. Caractéristiques OADP

L’API OpenShift pour la protection des données (OADP) prend en charge les fonctionnalités suivantes:

Backup

Il est possible d’utiliser OADP pour sauvegarder toutes les applications sur OpenShift Platform, ou vous pouvez filtrer les ressources par type, espace de noms ou étiquette.

L’OADP sauvegarde les objets Kubernetes et les images internes en les enregistrant comme fichier d’archive sur le stockage d’objets. L’OADP sauvegarde les volumes persistants (PV) en créant des instantanés avec l’API de snapshot cloud native ou avec l’interface de stockage de conteneurs (CSI). Dans le cas des fournisseurs de cloud qui ne prennent pas en charge les instantanés, OADP sauvegarde les ressources et les données PV avec Restic.

Note

Il faut exclure les opérateurs de la sauvegarde d’une application pour la sauvegarde et la restauration pour réussir.

Restore

Il est possible de restaurer des ressources et des PV à partir d’une sauvegarde. Il est possible de restaurer tous les objets dans une sauvegarde ou de filtrer les objets par l’espace de noms, le PV ou l’étiquette.

Note

Il faut exclure les opérateurs de la sauvegarde d’une application pour la sauvegarde et la restauration pour réussir.

Calendrier
Les sauvegardes peuvent être programmées à des intervalles spécifiés.
Crochets
Il est possible d’utiliser des crochets pour exécuter des commandes dans un conteneur sur un pod, par exemple, fsfreeze pour geler un système de fichiers. Il est possible de configurer un crochet pour s’exécuter avant ou après une sauvegarde ou une restauration. Les crochets de restauration peuvent fonctionner dans un conteneur d’init ou dans le conteneur d’application.

1.4.2. Plugins OADP

L’API OpenShift pour la protection des données (OADP) fournit des plugins Velero par défaut qui sont intégrés aux fournisseurs de stockage pour prendre en charge les opérations de sauvegarde et d’instantané. Il est possible de créer des plugins personnalisés basés sur les plugins Velero.

L’OADP fournit également des plugins pour Red Hat OpenShift Service sur les sauvegardes de ressources AWS, les sauvegardes de ressources OpenShift Virtualization et les instantanés CSI (Container Storage Interface).

Tableau 1.3. Plugins OADP
Plugin OADPFonctionEmplacement de stockage

AWS

Sauvegarde et restaure les objets Kubernetes.

AWS S3

Sauvegarde et restaure les volumes avec des instantanés.

AWS EBS

à propos de OpenShift

Sauvegarde et restaure Red Hat OpenShift Service sur les ressources AWS. [1]

Boutique d’objets

KubeVirt

Sauvegarde et restaure les ressources OpenShift Virtualization. [2]

Boutique d’objets

CSI

Sauvegarde et restaure des volumes avec des instantanés CSI. [3]

Le stockage en nuage qui prend en charge les instantanés CSI

le VSM

Le logiciel VolumeSnapshotMover déplace les snapshots du cluster dans un magasin d’objets à utiliser lors d’un processus de restauration pour récupérer des applications étatiques, dans des situations telles que la suppression de clusters. [4]

Boutique d’objets

  1. Il est obligatoire.
  2. Les disques de machine virtuelle sont sauvegardés avec des instantanés CSI ou Restic.
  3. Le plugin csi utilise l’API instantanée Kubernetes CSI.

    • Le logiciel OADP 1.1 ou version ultérieure utilise snapshot.storage.k8s.io/v1
    • Le logiciel OADP 1.0 utilise snapshot.storage.k8s.io/v1beta1
  4. L’OADP 1.2 seulement.

1.4.3. À propos des plugins OADP Velero

Lorsque vous installez Velero, vous pouvez configurer deux types de plugins:

  • Plugins de fournisseur de cloud par défaut
  • Des plugins personnalisés

Les deux types de plugins sont facultatifs, mais la plupart des utilisateurs configurent au moins un plugin fournisseur de cloud.

1.4.3.1. Plugins de fournisseurs de cloud Velero par défaut

Lorsque vous configurez le fichier oadp_v1alpha1_dpa.yaml, vous pouvez installer l’un des plugins par défaut suivants:

  • AWS (Amazon Web Services)
  • ajouter au panier OpenShift Velero plugin
  • CSI (Interface de stockage de conteneurs)
  • KubeVirt (KubeVirt)

Lors du déploiement, vous spécifiez les plugins par défaut souhaités dans le fichier oadp_v1alpha1_dpa.yaml.

Exemple de fichier

Le fichier .yaml suivant installe les plugins openshift, aws, azure et gcp:

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp
Copy to Clipboard
1.4.3.2. Plugins Velero personnalisés

Lors du déploiement, vous pouvez installer un plugin Velero personnalisé en spécifiant l’image et le nom du plugin lorsque vous configurez le fichier oadp_v1alpha1_dpa.yaml.

Lors du déploiement, vous spécifiez les plugins personnalisés souhaités dans le fichier oadp_v1alpha1_dpa.yaml.

Exemple de fichier

Le fichier .yaml suivant installe les plugins openshift, azure et gcp par défaut et un plugin personnalisé qui a le nom custom-plugin-example et l’image quay.io/example-repo/custom-velero-plugin:

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin
Copy to Clipboard
1.4.3.3. Les plugins Velero renvoient le message « EOF reçu, arrêt de la boucle recv »
Note

Les plugins Velero sont lancés en tant que processus distincts. Après la fin de l’opération Velero, soit avec succès ou non, ils sortent. La réception d’un EOF reçu, l’arrêt du message de boucle recv dans les journaux de débogage indique qu’une opération de plugin est terminée. Cela ne signifie pas qu’une erreur s’est produite.

1.4.4. Plugins OADP problèmes connus

La section suivante décrit les problèmes connus dans les plugins OpenShift API for Data Protection (OADP):

1.4.4.1. Le plugin Velero panique lors des sauvegardes d’images en raison d’un secret manquant

Lorsque la sauvegarde et l’emplacement de stockage de sauvegarde (BSL) sont gérés en dehors du champ d’application de l’application de protection des données (DPA), le contrôleur OADP, ce qui signifie que la réconciliation DPA ne crée pas le fichier oadp-&lt;bsl_name&gt;-bsl_provider&gt;-registry-secret pertinent.

Lorsque la sauvegarde est exécutée, le plugin OpenShift Velero panique sur la sauvegarde imagestream, avec l’erreur de panique suivante:

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…
Copy to Clipboard
1.4.4.1.1. Contournement pour éviter l’erreur de panique

Afin d’éviter l’erreur de panique du plugin Velero, effectuez les étapes suivantes:

  1. Étiqueter le BSL personnalisé avec l’étiquette correspondante:

    $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
    Copy to Clipboard
  2. Après que le BSL soit étiqueté, attendez que le DPA se réconcilie.

    Note

    Il est possible de forcer la réconciliation en apportant tout changement mineur au DPA lui-même.

  3. Lorsque le DPA se réconcilie, confirmez que les oadp-&lt;bsl_name&gt;-&lt;bsl_provider&gt;-registry-secret pertinents ont été créés et que les données de registre correctes y ont été peuplées:

    $ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
    Copy to Clipboard
1.4.4.2. Défaut de segmentation du contrôleur OpenShift ADP

Lorsque vous configurez un DPA avec à la fois cloudstorage et restic activé, le pod openshift-adp-controller-manager se bloque et redémarre indéfiniment jusqu’à ce que le pod échoue avec un défaut de segmentation de boucle de crash.

Le velero ou le cloudstorage peuvent être définis, car ce sont des champs mutuellement exclusifs.

  • Lorsque vous avez défini à la fois velero et cloudstorage, le gestionnaire openshift-adp-controller-manager échoue.
  • Lorsque vous n’avez ni velero ni cloudstorage défini, le gestionnaire openshift-adp-controller-manager échoue.

Consultez l’OADP-1054 pour plus d’informations à ce sujet.

1.4.4.2.1. Contournement de faille de segmentation du contrôleur OpenShift ADP

Lorsque vous configurez un DPA, vous devez définir le velero ou le cloudstorage. Lorsque vous définissez les deux API dans votre DPA, le pod openshift-adp-controller-manager échoue avec un défaut de segmentation de boucle de panne.

1.5. Cas d’utilisation OADP

1.5.1. Sauvegarde des charges de travail sur OADP avec ROSA STS

1.5.1.1. Effectuer une sauvegarde avec OADP et ROSA STS

L’exemple suivant d’application hello-world n’a pas de volumes persistants (PVs) attachés. Effectuez une sauvegarde avec l’API OpenShift pour la protection des données (OADP) avec Red Hat OpenShift Service sur AWS (ROSA) STS.

La configuration de l’application de protection des données (DPA) fonctionnera.

  1. Créez une charge de travail pour sauvegarder en exécutant les commandes suivantes:

    $ oc create namespace hello-world
    Copy to Clipboard
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
    Copy to Clipboard
  2. Exposez l’itinéraire en exécutant la commande suivante:

    $ oc expose service/hello-openshift -n hello-world
    Copy to Clipboard
  3. Assurez-vous que l’application fonctionne en exécutant la commande suivante:

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Copy to Clipboard

    Exemple de sortie

    Hello OpenShift!
    Copy to Clipboard

  4. Sauvegardez la charge de travail en exécutant la commande suivante:

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        includedNamespaces:
        - hello-world
        storageLocation: ${CLUSTER_NAME}-dpa-1
        ttl: 720h0m0s
    EOF
    Copy to Clipboard
  5. Attendez que la sauvegarde soit terminée, puis exécutez la commande suivante:

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
    Copy to Clipboard

    Exemple de sortie

    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }
    Copy to Clipboard

  6. Effacer la charge de travail de démonstration en exécutant la commande suivante:

    $ oc delete ns hello-world
    Copy to Clipboard
  7. Restaurer la charge de travail à partir de la sauvegarde en exécutant la commande suivante:

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
    Copy to Clipboard
  8. Attendez que la restauration se termine en exécutant la commande suivante:

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
    Copy to Clipboard

    Exemple de sortie

    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }
    Copy to Clipboard

  9. Assurez-vous que la charge de travail est restaurée en exécutant la commande suivante:

    $ oc -n hello-world get pods
    Copy to Clipboard

    Exemple de sortie

    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s
    Copy to Clipboard

  10. Cochez le JSONPath en exécutant la commande suivante:

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Copy to Clipboard

    Exemple de sortie

    Hello OpenShift!
    Copy to Clipboard

Note

Consultez la documentation de dépannage de l’équipe OADP pour obtenir des conseils de dépannage.

1.5.1.2. Le nettoyage d’un cluster après une sauvegarde avec OADP et ROSA STS

Dans le cas où vous devez désinstaller l’opérateur OpenShift API for Data Protection (OADP) avec les sauvegardes et le seau S3 de cet exemple, suivez ces instructions.

Procédure

  1. Effacer la charge de travail en exécutant la commande suivante:

    $ oc delete ns hello-world
    Copy to Clipboard
  2. Effacer l’application de protection des données (DPA) en exécutant la commande suivante:

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
    Copy to Clipboard
  3. Effacer le stockage en nuage en exécutant la commande suivante:

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    Copy to Clipboard
    Avertissement

    Dans le cas où cette commande est suspendue, vous devrez peut-être supprimer le finalisateur en exécutant la commande suivante:

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
    Copy to Clipboard
  4. Lorsque l’opérateur n’est plus requis, retirez-le en exécutant la commande suivante:

    $ oc -n openshift-adp delete subscription oadp-operator
    Copy to Clipboard
  5. Enlevez l’espace de noms de l’opérateur:

    $ oc delete ns openshift-adp
    Copy to Clipboard
  6. Lorsque les ressources de sauvegarde et de restauration ne sont plus nécessaires, retirez-les du cluster en exécutant la commande suivante:

    $ oc delete backups.velero.io hello-world
    Copy to Clipboard
  7. Afin de supprimer les objets de sauvegarde, de restauration et de télécommande dans AWS S3, exécutez la commande suivante:

    $ velero backup delete hello-world
    Copy to Clipboard
  8. Lorsque vous n’avez plus besoin des Définitions de ressources personnalisées (CRD), supprimez-les du cluster en exécutant la commande suivante:

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
    Copy to Clipboard
  9. Effacer le seau AWS S3 en exécutant les commandes suivantes:

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    Copy to Clipboard
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
    Copy to Clipboard
  10. Détachez la politique du rôle en exécutant la commande suivante:

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
    Copy to Clipboard
  11. Supprimez le rôle en exécutant la commande suivante:

    $ aws iam delete-role --role-name "${ROLE_NAME}"
    Copy to Clipboard

1.5.2. L’API OpenShift pour la protection des données (OADP) restaure le cas d’utilisation

Ci-dessous est un cas d’utilisation pour utiliser OADP pour restaurer une sauvegarde dans un espace de noms différent.

1.5.2.1. La restauration d’une application dans un espace de noms différent en utilisant OADP

Restaurer une sauvegarde d’une application en utilisant OADP dans un nouvel espace de noms cible, test-restauration-application. Afin de restaurer une sauvegarde, vous créez une ressource personnalisée de restauration (CR) comme indiqué dans l’exemple suivant. Dans le CR de restauration, l’espace de noms source fait référence à l’espace de noms de l’application que vous avez inclus dans la sauvegarde. Ensuite, vous vérifiez la restauration en changeant votre projet vers le nouvel espace de noms restauré et en vérifiant les ressources.

Conditions préalables

  • L’opérateur OADP a été installé.
  • La sauvegarde d’une application est à restaurer.

Procédure

  1. Créez une restauration CR comme indiqué dans l’exemple suivant:

    Exemple de restauration CR

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: test-restore 
    1
    
      namespace: openshift-adp
    spec:
      backupName: <backup_name> 
    2
    
      restorePVs: true
      namespaceMapping:
        <application_namespace>: test-restore-application 
    3
    Copy to Clipboard

    1
    Le nom de la restauration CR.
    2
    Indiquez le nom de la sauvegarde.
    3
    le namespaceMapping mappe l’espace de noms de l’application source à l’espace de noms de l’application cible. Indiquez l’espace de noms de l’application que vous avez sauvegardé. l’application test-restauration est l’espace de noms cible où vous souhaitez restaurer la sauvegarde.
  2. Appliquez le CR de restauration en exécutant la commande suivante:

    $ oc apply -f <restore_cr_filename>
    Copy to Clipboard

La vérification

  1. Assurez-vous que la restauration est en phase terminée en exécutant la commande suivante:

    $ oc describe restores.velero.io <restore_name> -n openshift-adp
    Copy to Clipboard
  2. Changer l’application de test-restauration de l’espace de noms restaurée en exécutant la commande suivante:

    $ oc project test-restore-application
    Copy to Clipboard
  3. Contrôlez les ressources restaurées telles que la revendication de volume persistant (pvc), le service (svc), le déploiement, le secret et la carte de configuration en exécutant la commande suivante:

    $ oc get pvc,svc,deployment,secret,configmap
    Copy to Clipboard

    Exemple de sortie

    NAME                          STATUS   VOLUME
    persistentvolumeclaim/mysql   Bound    pvc-9b3583db-...-14b86
    
    NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    service/mysql      ClusterIP   172....157     <none>        3306/TCP   2m56s
    service/todolist   ClusterIP   172.....15     <none>        8000/TCP   2m56s
    
    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/mysql   0/1     1            0           2m55s
    
    NAME                                         TYPE                      DATA   AGE
    secret/builder-dockercfg-6bfmd               kubernetes.io/dockercfg   1      2m57s
    secret/default-dockercfg-hz9kz               kubernetes.io/dockercfg   1      2m57s
    secret/deployer-dockercfg-86cvd              kubernetes.io/dockercfg   1      2m57s
    secret/mysql-persistent-sa-dockercfg-rgp9b   kubernetes.io/dockercfg   1      2m57s
    
    NAME                                 DATA   AGE
    configmap/kube-root-ca.crt           1      2m57s
    configmap/openshift-service-ca.crt   1      2m57s
    Copy to Clipboard

1.6. Installation et configuration d’OADP

1.6.1. Installation d’OADP

Il est possible d’utiliser l’API OpenShift pour la protection des données (OADP) avec Red Hat OpenShift Service sur AWS (ROSA) pour sauvegarder et restaurer les données des applications.

Avant d’installer l’API OpenShift pour la protection des données (OADP), vous devez configurer les informations d’identification des rôles et des politiques pour OADP afin qu’elle puisse utiliser l’API Amazon Web Services.

Ce processus se déroule en deux étapes:

  1. Créer des informations d’identification AWS
  2. Installez l’opérateur OADP et donnez-lui un rôle IAM
1.6.1.1. La préparation des identifiants AWS pour OADP

Le compte Amazon Web Services doit être préparé et configuré pour accepter une installation OpenShift API for Data Protection (OADP).

Procédure

  1. Créez les variables d’environnement suivantes en exécutant les commandes suivantes:

    Important

    Changez le nom du cluster pour correspondre à votre cluster ROSA et assurez-vous d’être connecté au cluster en tant qu’administrateur. Assurez-vous que tous les champs sont affichés correctement avant de continuer.

    $ export CLUSTER_NAME=my-cluster 
    1
    
      export ROSA_CLUSTER_ID=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .id)
      export REGION=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .region.id)
      export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||')
      export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
      export CLUSTER_VERSION=$(rosa describe cluster -c ${CLUSTER_NAME} -o json | jq -r .version.raw_id | cut -f -2 -d '.')
      export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials"
      export SCRATCH="/tmp/${CLUSTER_NAME}/oadp"
      mkdir -p ${SCRATCH}
      echo "Cluster ID: ${ROSA_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint:
      ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
    Copy to Clipboard
    1
    Le nom de votre cluster ROSA est remplacé par mon cluster.
  2. Dans le compte AWS, créez une politique IAM pour permettre l’accès à AWS S3:

    1. Vérifiez si la stratégie existe en exécutant la commande suivante:

      $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text) 
      1
      Copy to Clipboard
      1
      Remplacez RosaOadp par le nom de votre politique.
    2. Entrez la commande suivante pour créer le fichier JSON de stratégie, puis créez la stratégie dans ROSA:

      Note

      Lorsque la stratégie ARN n’est pas trouvée, la commande crée la stratégie. Dans le cas où la politique ARN existe déjà, la déclaration si elle saute intentionnellement la création de la politique.

      $ if [[ -z "${POLICY_ARN}" ]]; then
        cat << EOF > ${SCRATCH}/policy.json 
      1
      
        {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "s3:CreateBucket",
              "s3:DeleteBucket",
              "s3:PutBucketTagging",
              "s3:GetBucketTagging",
              "s3:PutEncryptionConfiguration",
              "s3:GetEncryptionConfiguration",
              "s3:PutLifecycleConfiguration",
              "s3:GetLifecycleConfiguration",
              "s3:GetBucketLocation",
              "s3:ListBucket",
              "s3:GetObject",
              "s3:PutObject",
              "s3:DeleteObject",
              "s3:ListBucketMultipartUploads",
              "s3:AbortMultipartUpload",
              "s3:ListMultipartUploadParts",
              "ec2:DescribeSnapshots",
              "ec2:DescribeVolumes",
              "ec2:DescribeVolumeAttribute",
              "ec2:DescribeVolumesModifications",
              "ec2:DescribeVolumeStatus",
              "ec2:CreateTags",
              "ec2:CreateVolume",
              "ec2:CreateSnapshot",
              "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
          }
        ]}
      EOF
      
        POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \
        --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
        --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \
        --output text)
        fi
      Copy to Clipboard
      1
      Le SCRATCH est un nom pour un répertoire temporaire créé pour les variables d’environnement.
    3. Consultez la stratégie ARN en exécutant la commande suivante:

      $ echo ${POLICY_ARN}
      Copy to Clipboard
  3. Créer une politique de confiance du rôle de l’IAM pour le cluster:

    1. Créez le fichier de stratégie de confiance en exécutant la commande suivante:

      $ cat <<EOF > ${SCRATCH}/trust-policy.json
        {
            "Version": "2012-10-17",
            "Statement": [{
              "Effect": "Allow",
              "Principal": {
                "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
              },
              "Action": "sts:AssumeRoleWithWebIdentity",
              "Condition": {
                "StringEquals": {
                  "${OIDC_ENDPOINT}:sub": [
                    "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
                    "system:serviceaccount:openshift-adp:velero"]
                }
              }
            }]
        }
      EOF
      Copy to Clipboard
    2. Créez le rôle en exécutant la commande suivante:

      $ ROLE_ARN=$(aws iam create-role --role-name \
        "${ROLE_NAME}" \
        --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
        --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} \
               Key=rosa_openshift_version,Value=${CLUSTER_VERSION} \
               Key=rosa_role_prefix,Value=ManagedOpenShift \
               Key=operator_namespace,Value=openshift-adp \
               Key=operator_name,Value=openshift-oadp \
        --query Role.Arn --output text)
      Copy to Clipboard
    3. Afficher le rôle ARN en exécutant la commande suivante:

      $ echo ${ROLE_ARN}
      Copy to Clipboard
  4. Joindre la politique de l’IAM au rôle de l’IAM en exécutant la commande suivante:

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
      --policy-arn ${POLICY_ARN}
    Copy to Clipboard
1.6.1.2. Installation de l’opérateur OADP et rôle IAM

AWS Security Token Service (AWS STS) est un service Web mondial qui fournit des informations d’identification à court terme pour les utilisateurs IAM ou fédérés. Le Red Hat OpenShift Service sur AWS (ROSA) avec STS est le mode d’identification recommandé pour les clusters ROSA. Ce document décrit comment installer l’API OpenShift pour la protection des données (OADP) sur ROSA avec AWS STS.

Important

Le Restic n’est pas pris en charge.

La sauvegarde du système de fichiers Kopia (FSB) est prise en charge lors de la sauvegarde des systèmes de fichiers qui n’ont pas de prise en charge de l’interface de stockage de conteneurs (CSI).

Exemple de systèmes de fichiers comprennent ce qui suit:

  • Amazon Elastic File System (EFS)
  • Le système de fichiers réseau (NFS)
  • les volumes videDir
  • Les volumes locaux

En cas de sauvegarde des volumes, OADP sur ROSA avec AWS STS ne prend en charge que les snapshots natifs et les snapshots CSI (Container Storage Interface).

Dans un cluster Amazon ROSA qui utilise l’authentification STS, la restauration des données sauvegardées dans une autre région AWS n’est pas prise en charge.

La fonction Data Mover n’est pas actuellement prise en charge dans les clusters ROSA. Il est possible d’utiliser des outils AWS S3 natifs pour déplacer les données.

Conditions préalables

  • A Red Hat OpenShift Service sur AWS ROSA cluster avec l’accès et les jetons requis. Consultez la procédure précédente Préparation des informations d’identification AWS pour OADP. Lorsque vous prévoyez d’utiliser deux clusters différents pour sauvegarder et restaurer, vous devez préparer des identifiants AWS, y compris ROLE_ARN, pour chaque cluster.

Procédure

  1. Créez un service Red Hat OpenShift sur AWS secret à partir de votre fichier jeton AWS en entrant les commandes suivantes:

    1. Créer le fichier d’identification:

      $ cat <<EOF > ${SCRATCH}/credentials
        [default]
        role_arn = ${ROLE_ARN}
        web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
        region = <aws_region> 
      1
      
      EOF
      Copy to Clipboard
      1
      &lt;aws_region&gt; par la région AWS à utiliser pour le point d’extrémité STS.
    2. Créer un espace de noms pour OADP:

      $ oc create namespace openshift-adp
      Copy to Clipboard
    3. Créez le service Red Hat OpenShift sur AWS secret:

      $ oc -n openshift-adp create secret generic cloud-credentials \
        --from-file=${SCRATCH}/credentials
      Copy to Clipboard
      Note

      Dans Red Hat OpenShift Service sur AWS version 4.15 et ultérieure, l’opérateur OADP prend en charge un nouveau flux de travail STS standardisé via le gestionnaire de cycle de vie de l’opérateur (OLM) et Cloud Credentials Operator (CCO). Dans ce flux de travail, vous n’avez pas besoin de créer le secret ci-dessus, vous n’avez besoin que de fournir le rôle ARN lors de l’installation d’opérateurs gérés par OLM en utilisant le service OpenShift Red Hat sur la console Web AWS, pour plus d’informations voir Installation depuis OperatorHub à l’aide de la console Web.

      Le secret précédent est créé automatiquement par CCO.

  2. Installez l’opérateur OADP:

    1. Dans le Red Hat OpenShift Service sur la console web AWS, accédez aux opérateurs → OperatorHub.
    2. Cherchez l’opérateur OADP.
    3. Dans le champ role_ARN, collez le rôle_arn que vous avez créé précédemment et cliquez sur Installer.
  3. Créez un stockage cloud AWS à l’aide de vos identifiants AWS en entrant la commande suivante:

    $ cat << EOF | oc create -f -
      apiVersion: oadp.openshift.io/v1alpha1
      kind: CloudStorage
      metadata:
        name: ${CLUSTER_NAME}-oadp
        namespace: openshift-adp
      spec:
        creationSecret:
          key: credentials
          name: cloud-credentials
        enableSharedConfig: true
        name: ${CLUSTER_NAME}-oadp
        provider: aws
        region: $REGION
    EOF
    Copy to Clipboard
  4. Consultez la classe de stockage par défaut de votre application en entrant la commande suivante:

    $ oc get pvc -n <namespace>
    Copy to Clipboard

    Exemple de sortie

    NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
    mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h
    Copy to Clipboard

  5. Bénéficiez de la classe de stockage en exécutant la commande suivante:

    $ oc get storageclass
    Copy to Clipboard

    Exemple de sortie

    NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
    gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    Copy to Clipboard

    Note

    Les classes de stockage suivantes fonctionneront:

    • gp3-csi
    • gp2-csi
    • Gp3
    • Gp2

    Lorsque l’application ou les applications en cours de sauvegarde sont toutes utilisant des volumes persistants (PV) avec Container Storage Interface (CSI), il est conseillé d’inclure le plugin CSI dans la configuration OADP DPA.

  6. Créez la ressource DataProtectionApplication pour configurer la connexion au stockage où les sauvegardes et les instantanés de volume sont stockés:

    1. Lorsque vous utilisez uniquement des volumes CSI, déployez une application de protection des données en entrant la commande suivante:

      $ cat << EOF | oc create -f -
        apiVersion: oadp.openshift.io/v1alpha1
        kind: DataProtectionApplication
        metadata:
          name: ${CLUSTER_NAME}-dpa
          namespace: openshift-adp
        spec:
          backupImages: true 
      1
      
          features:
            dataMover:
              enable: false
          backupLocations:
          - bucket:
              cloudStorageRef:
                name: ${CLUSTER_NAME}-oadp
              credential:
                key: credentials
                name: cloud-credentials
              prefix: velero
              default: true
              config:
                region: ${REGION}
          configuration:
            velero:
              defaultPlugins:
              - openshift
              - aws
              - csi
            nodeAgent:  
      2
      
              enable: false
              uploaderType: kopia 
      3
      
      EOF
      Copy to Clipboard
      1
      La ROSA prend en charge la sauvegarde interne d’image. Définissez ce champ sur false si vous ne voulez pas utiliser la sauvegarde d’image.
      2
      Consultez la note importante concernant l’attribut nodeAgent.
      3
      Le type de téléchargeur. Les valeurs possibles sont restiques ou kopia. Le Mover de données intégré utilise Kopia comme mécanisme de téléchargement par défaut, quelle que soit la valeur du champ uploaderType.
  1. Lorsque vous utilisez des volumes CSI ou non CSI, déployez une application de protection des données en entrant la commande suivante:

    $ cat << EOF | oc create -f -
      apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        name: ${CLUSTER_NAME}-dpa
        namespace: openshift-adp
      spec:
        backupImages: true 
    1
    
        backupLocations:
        - bucket:
            cloudStorageRef:
              name: ${CLUSTER_NAME}-oadp
            credential:
              key: credentials
              name: cloud-credentials
            prefix: velero
            default: true
            config:
              region: ${REGION}
        configuration:
          velero:
            defaultPlugins:
            - openshift
            - aws
          nodeAgent: 
    2
    
            enable: false
            uploaderType: restic
        snapshotLocations:
          - velero:
              config:
                credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials 
    3
    
                enableSharedConfig: "true" 
    4
    
                profile: default 
    5
    
                region: ${REGION} 
    6
    
              provider: aws
    EOF
    Copy to Clipboard
    1
    La ROSA prend en charge la sauvegarde interne d’image. Définissez ce champ sur false si vous ne voulez pas utiliser la sauvegarde d’image.
    2
    Consultez la note importante concernant l’attribut nodeAgent.
    3
    Le champ CredentialsFile est l’emplacement monté de l’identifiant du seau sur le pod.
    4
    Le champ enableSharedConfig permet aux snapshotLocations de partager ou de réutiliser l’identifiant défini pour le seau.
    5
    Utilisez le nom de profil défini dans le fichier d’identification AWS.
    6
    Indiquez la région en tant que région AWS. Cela doit être le même que la région des clusters.

    Désormais, vous êtes prêt à sauvegarder et restaurer Red Hat OpenShift Service sur les applications AWS, comme décrit dans les applications de sauvegarde.

Important

Le paramètre d’activation de restic est défini sur false dans cette configuration, car OADP ne prend pas en charge Restic dans les environnements ROSA.

Lorsque vous utilisez OADP 1.2, remplacez cette configuration:

nodeAgent:
  enable: false
  uploaderType: restic
Copy to Clipboard

avec la configuration suivante:

restic:
  enable: false
Copy to Clipboard

Lorsque vous souhaitez utiliser deux clusters différents pour sauvegarder et restaurer, les deux clusters doivent avoir les mêmes noms de stockage AWS S3 dans le CR de stockage en nuage et dans la configuration OADP DataProtectionApplication.

1.6.1.3. La mise à jour du rôle IAM ARN dans l’abonnement OADP Operator

Lors de l’installation de l’opérateur OADP sur un cluster ROSA Security Token Service (STS), si vous fournissez un rôle IAM incorrect Amazon Resource Name (ARN), le pod openshift-adp-controller donne une erreur. Les requêtes d’identification qui sont générées contiennent le mauvais rôle IAM ARN. Afin de mettre à jour l’objet de requêtes d’identification avec l’ARN du rôle IAM correct, vous pouvez modifier l’abonnement OADP Operator et corriger le rôle IAM ARN avec la valeur correcte. En modifiant l’abonnement OADP Operator, vous n’avez pas à désinstaller et réinstaller OADP pour mettre à jour le rôle IAM ARN.

Conditions préalables

  • Il existe un service Red Hat OpenShift sur le cluster AWS STS avec l’accès et les jetons requis.
  • Il a été installé OADP sur le cluster ROSA STS.

Procédure

  1. Afin de vérifier que l’abonnement OADP a le mauvais jeu de variable d’environnement ARN rôle IAM, exécutez la commande suivante:

    $ oc get sub -o yaml redhat-oadp-operator
    Copy to Clipboard

    Exemple d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      annotations:
      creationTimestamp: "2025-01-15T07:18:31Z"
      generation: 1
      labels:
        operators.coreos.com/redhat-oadp-operator.openshift-adp: ""
      name: redhat-oadp-operator
      namespace: openshift-adp
      resourceVersion: "77363"
      uid: 5ba00906-5ad2-4476-ae7b-ffa90986283d
    spec:
      channel: stable-1.4
      config:
        env:
        - name: ROLEARN
          value: arn:aws:iam::11111111:role/wrong-role-arn 
    1
    
      installPlanApproval: Manual
      name: redhat-oadp-operator
      source: prestage-operators
      sourceNamespace: openshift-marketplace
      startingCSV: oadp-operator.v1.4.2
    Copy to Clipboard

    1
    Vérifiez la valeur de ROLEARN que vous souhaitez mettre à jour.
  2. Actualisez le champ ROLEARN de l’abonnement avec le rôle correct ARN en exécutant la commande suivante:

    $ oc patch subscription redhat-oadp-operator -p '{"spec": {"config": {"env": [{"name": "ROLEARN", "value": "<role_arn>"}]}}}' --type='merge'
    Copy to Clipboard

    là où:

    &lt;role_arn&gt;
    Indique le rôle IAM ARN à mettre à jour. Arn:aws:iam::160….6956:role/oadprosa…..8wlf.
  3. Assurez-vous que l’objet secret est mis à jour avec la valeur ARN du rôle correct en exécutant la commande suivante:

    $ oc get secret cloud-credentials -o jsonpath='{.data.credentials}' | base64 -d
    Copy to Clipboard

    Exemple de sortie

    [default]
    sts_regional_endpoints = regional
    role_arn = arn:aws:iam::160.....6956:role/oadprosa.....8wlf
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
    Copy to Clipboard

  4. Configurez le fichier de manifestation DataProtectionApplication (CR) comme indiqué dans l’exemple suivant:

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-rosa-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - bucket:
          config:
            region: us-east-1
          cloudStorageRef:
            name: <cloud_storage> 
    1
    
          credential:
            name: cloud-credentials
            key: credentials
          prefix: velero
          default: true
      configuration:
        velero:
          defaultPlugins:
          - aws
          - openshift
    Copy to Clipboard
    1
    Indiquez le CloudStorage CR.
  5. Créez la DataProtectionApplication CR en exécutant la commande suivante:

    $ oc create -f <dpa_manifest_file>
    Copy to Clipboard
  6. Assurez-vous que le DataProtectionApplication CR est réconcilié et que l’état est défini sur "True" en exécutant la commande suivante:

    $  oc get dpa -n openshift-adp -o yaml
    Copy to Clipboard

    Exemple d’application de DataProtectionApplication

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    status:
        conditions:
        - lastTransitionTime: "2023-07-31T04:48:12Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    Copy to Clipboard

  7. Assurez-vous que BackupStorageLocation CR est dans un état disponible en exécutant la commande suivante:

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    Copy to Clipboard

    Exemple de BackupStorageLocation

    NAME       PHASE       LAST VALIDATED   AGE   DEFAULT
    ts-dpa-1   Available   3s               6s    true
    Copy to Clipboard

1.7. Désinstaller OADP

1.7.1. Désinstallation de l’API OpenShift pour la protection des données

Désinstaller l’API OpenShift pour la protection des données (OADP) en supprimant l’opérateur OADP. Consultez Supprimer les opérateurs d’un cluster pour plus de détails.

1.8. La sauvegarde de l’OADP

1.8.1. Sauvegarde des applications

Les sauvegardes fréquentes peuvent consommer du stockage sur l’emplacement de stockage de sauvegarde. Vérifiez la fréquence des sauvegardes, le temps de conservation et la quantité de données des volumes persistants (PV) si vous utilisez des sauvegardes non locales, par exemple des seaux S3. Étant donné que toutes les sauvegardes prises restent jusqu’à expiration, vérifiez également le réglage du temps de vie (TTL) de l’horaire.

Il est possible de sauvegarder les applications en créant une ressource personnalisée de sauvegarde (CR). En savoir plus, voir Créer une sauvegarde CR.

Le Backup CR crée des fichiers de sauvegarde pour les ressources Kubernetes et des images internes sur le stockage d’objets S3.

1.8.1.1. Aperçu des ressources avant d’exécuter la sauvegarde et la restauration

L’OADP sauvegarde les ressources applicatives en fonction du type, de l’espace de noms ou de l’étiquette. Cela signifie que vous pouvez afficher les ressources une fois la sauvegarde terminée. De même, vous pouvez voir les objets restaurés en fonction de l’espace de noms, du volume persistant (PV) ou de l’étiquette après la fin d’une opération de restauration. Afin de prévisualiser les ressources à l’avance, vous pouvez effectuer un cycle sec des opérations de sauvegarde et de restauration.

Conditions préalables

  • L’opérateur OADP a été installé.

Procédure

  1. Afin de prévisualiser les ressources incluses dans la sauvegarde avant d’exécuter la sauvegarde réelle, exécutez la commande suivante:

    $ velero backup create <backup-name> --snapshot-volumes false 
    1
    Copy to Clipboard
    1
    Indiquez la valeur du paramètre --snapshot-volumes comme false.
  2. Afin de connaître plus de détails sur les ressources de sauvegarde, exécutez la commande suivante:

    $ velero describe backup <backup_name> --details 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde.
  3. Afin de prévisualiser les ressources incluses dans la restauration avant d’exécuter la restauration réelle, exécutez la commande suivante:

    $ velero restore create --from-backup <backup-name> 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde créée pour examiner les ressources de sauvegarde.
    Important

    La commande de création de la restauration velero crée des ressources de restauration dans le cluster. Après avoir examiné les ressources, vous devez supprimer les ressources créées dans le cadre de la restauration.

  4. Afin de connaître plus de détails sur les ressources de restauration, exécutez la commande suivante:

    $ velero describe restore <restore_name> --details 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la restauration.

Il est possible de créer des crochets de sauvegarde pour exécuter des commandes avant ou après l’opération de sauvegarde. Découvrez Créer des crochets de sauvegarde.

Il est possible de planifier des sauvegardes en créant un Schedule CR au lieu d’un Backup CR. Consultez les sauvegardes de planification à l’aide de l’annexe CR.

1.8.1.2. Problèmes connus

Le service OpenShift Red Hat sur AWS 4 applique une politique d’admission de sécurité de pod (PSA) qui peut entraver la préparation des pods lors d’un processus de restauration Restic.

Ce problème a été résolu dans les versions 1.1.6 et OADP 1.2.2, il est donc recommandé aux utilisateurs de passer à ces versions.

1.8.2. Créer une sauvegarde CR

Kubernetes sauvegarde les ressources, les images internes et les volumes persistants (PV) en créant une ressource personnalisée de sauvegarde (CR).

Conditions préalables

  • Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
  • Le DataProtectionApplication CR doit être dans un état prêt.
  • Conditions préalables à l’emplacement de sauvegarde:

    • Le stockage d’objet S3 doit être configuré pour Velero.
    • Il faut avoir un emplacement de sauvegarde configuré dans DataProtectionApplication CR.
  • Conditions préalables à l’emplacement:

    • Le fournisseur de cloud doit disposer d’une API instantanée native ou prendre en charge les instantanés CSI (Container Storage Interface).
    • Dans le cas des snapshots CSI, vous devez créer un VolumeSnapshotClass CR pour enregistrer le pilote CSI.
    • L’emplacement du volume doit être configuré dans DataProtectionApplication CR.

Procédure

  1. Enregistrez les CRs de backupStorageLocations en entrant la commande suivante:

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    Copy to Clipboard

    Exemple de sortie

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m
    Copy to Clipboard

  2. Créez une sauvegarde CR, comme dans l’exemple suivant:

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      hooks: {}
      includedNamespaces:
      - <namespace> 
    1
    
      includedResources: [] 
    2
    
      excludedResources: [] 
    3
    
      storageLocation: <velero-sample-1> 
    4
    
      ttl: 720h0m0s
      labelSelector: 
    5
    
        matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>
      orLabelSelectors: 
    6
    
      - matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>
    Copy to Clipboard
    1
    Indiquez un tableau d’espaces de noms à sauvegarder.
    2
    Facultatif : Spécifiez un éventail de ressources à inclure dans la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, «po» pour «pods») ou entièrement qualifiés. En cas d’absence de précision, toutes les ressources sont incluses.
    3
    Facultatif : Spécifiez un éventail de ressources à exclure de la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, «po» pour «pods») ou entièrement qualifiés.
    4
    Indiquez le nom de backupStorageLocations CR.
    5
    Carte de {key,value} paires de ressources de sauvegarde qui ont toutes les étiquettes spécifiées.
    6
    Carte de {key,value} paires de ressources de sauvegarde qui ont une ou plusieurs des étiquettes spécifiées.
  3. Assurez-vous que l’état de la sauvegarde CR est complété:

    $ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'
    Copy to Clipboard

1.8.3. Création de crochets de sauvegarde

Lors de l’exécution d’une sauvegarde, il est possible de spécifier une ou plusieurs commandes à exécuter dans un conteneur à l’intérieur d’un pod, en fonction de la sauvegarde de la pod.

Les commandes peuvent être configurées pour être exécutées avant tout traitement d’action personnalisé (pré crochets), ou après que toutes les actions personnalisées aient été terminées et que tous les éléments supplémentaires spécifiés par l’action personnalisée aient été sauvegardés (hameçons postés).

Créez des crochets de sauvegarde pour exécuter des commandes dans un conteneur dans un pod en éditant la ressource personnalisée de sauvegarde (CR).

Procédure

  • Ajoutez un crochet au bloc spec.hooks du Backup CR, comme dans l’exemple suivant:

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 
    1
    
            excludedNamespaces: 
    2
    
            - <namespace>
            includedResources: []
            - pods 
    3
    
            excludedResources: [] 
    4
    
            labelSelector: 
    5
    
              matchLabels:
                app: velero
                component: server
            pre: 
    6
    
              - exec:
                  container: <container> 
    7
    
                  command:
                  - /bin/uname 
    8
    
                  - -a
                  onError: Fail 
    9
    
                  timeout: 30s 
    10
    
            post: 
    11
    
    ...
    Copy to Clipboard
    1
    Facultatif: Vous pouvez spécifier les espaces de noms auxquels le crochet s’applique. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les espaces de noms.
    2
    Facultatif: Vous pouvez spécifier les espaces de noms auxquels le crochet ne s’applique pas.
    3
    Actuellement, les pods sont la seule ressource prise en charge à laquelle les crochets peuvent s’appliquer.
    4
    Facultatif : Vous pouvez spécifier les ressources auxquelles le crochet ne s’applique pas.
    5
    Facultatif: Ce crochet ne s’applique qu’aux objets correspondant à l’étiquette. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les objets.
    6
    Gamme de crochets à exécuter avant la sauvegarde.
    7
    Facultatif: Si le conteneur n’est pas spécifié, la commande s’exécute dans le premier conteneur dans le pod.
    8
    C’est le point d’entrée pour le conteneur d’init ajouté.
    9
    Les valeurs autorisées pour le traitement des erreurs sont Fail and Continue. La valeur par défaut est l’échec.
    10
    Facultatif: Combien de temps pour attendre que les commandes s’exécutent. La valeur par défaut est 30s.
    11
    Ce bloc définit un tableau de crochets à exécuter après la sauvegarde, avec les mêmes paramètres que les crochets de pré-back.

1.8.4. Calendrier des sauvegardes à l’aide de l’annexe CR

L’opération de planification vous permet de créer une sauvegarde de vos données à un moment donné, spécifié par une expression Cron.

Les sauvegardes sont planifiées en créant une ressource personnalisée (CR) au lieu d’une sauvegarde CR.

Avertissement

Laissez suffisamment de temps dans votre calendrier de sauvegarde pour qu’une sauvegarde se termine avant la création d’une autre sauvegarde.

Ainsi, si une sauvegarde d’un espace de noms prend généralement 10 minutes, ne planifiez pas les sauvegardes plus fréquemment que toutes les 15 minutes.

Conditions préalables

  • Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
  • Le DataProtectionApplication CR doit être dans un état prêt.

Procédure

  1. Découvrez les CRs de backupStorageLocations:

    $ oc get backupStorageLocations -n openshift-adp
    Copy to Clipboard

    Exemple de sortie

    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m
    Copy to Clipboard

  2. Créer une annexe CR, comme dans l’exemple suivant:

    $ cat << EOF | oc apply -f -
    apiVersion: velero.io/v1
    kind: Schedule
    metadata:
      name: <schedule>
      namespace: openshift-adp
    spec:
      schedule: 0 7 * * * 
    1
    
      template:
        hooks: {}
        includedNamespaces:
        - <namespace> 
    2
    
        storageLocation: <velero-sample-1> 
    3
    
        defaultVolumesToFsBackup: true 
    4
    
        ttl: 720h0m0s
    EOF
    Copy to Clipboard
1
expression cron pour programmer la sauvegarde, par exemple 0 7 * * * pour effectuer une sauvegarde tous les jours à 7h00.
Note

Afin de planifier une sauvegarde à intervalles spécifiques, entrez le &lt;duration_in_minutes&gt; dans le format suivant:

  schedule: "*/10 * * * *"
Copy to Clipboard

Entrez la valeur des minutes entre les guillemets (" ").

2
Gamme d’espaces de noms à sauvegarder.
3
Le nom de backupStorageLocations CR.
4
Facultatif: Dans la version 1.2 et ultérieure d’OADP, ajoutez la sauvegarde par défautVolumesToFsBackup: vraie paire clé-valeur à votre configuration lors de l’exécution de sauvegardes de volumes avec Restic. Dans la version 1.1 de OADP, ajoutez la paire par défautVolumesToRestic: vraie paire clé-valeur lorsque vous sauvegardez des volumes avec Restic.
  1. Assurez-vous que l’état de l’annexe CR est terminé après l’exécution de la sauvegarde prévue:

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
    Copy to Clipboard

1.8.5. La suppression des sauvegardes

Il est possible de supprimer une sauvegarde en créant la ressource personnalisée DeleteBackupRequest (CR) ou en exécutant la commande de suppression velero comme expliqué dans les procédures suivantes.

Les artefacts de sauvegarde de volume sont supprimés à différents moments en fonction de la méthode de sauvegarde:

  • Les artefacts sont supprimés dans le prochain cycle de maintenance complet, une fois la sauvegarde supprimée.
  • Interface de stockage de conteneurs (CSI): Les artefacts sont supprimés immédiatement lorsque la sauvegarde est supprimée.
  • Kopia: Les artefacts sont supprimés après trois cycles de maintenance complets du référentiel Kopia, une fois la sauvegarde supprimée.
1.8.5.1. La suppression d’une sauvegarde en créant un DeleteBackupRequest CR

Il est possible de supprimer une sauvegarde en créant une ressource personnalisée DeleteBackupRequest (CR).

Conditions préalables

  • Exécutez une sauvegarde de votre application.

Procédure

  1. Créer un fichier manifeste DeleteBackupRequest CR:

    apiVersion: velero.io/v1
    kind: DeleteBackupRequest
    metadata:
      name: deletebackuprequest
      namespace: openshift-adp
    spec:
      backupName: <backup_name> 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde.
  2. Appliquez le DeleteBackupRequest CR pour supprimer la sauvegarde:

    $ oc apply -f <deletebackuprequest_cr_filename>
    Copy to Clipboard
1.8.5.2. La suppression d’une sauvegarde en utilisant le Velero CLI

Il est possible de supprimer une sauvegarde en utilisant le Velero CLI.

Conditions préalables

  • Exécutez une sauvegarde de votre application.
  • Le logiciel Velero CLI vous permet d’accéder au binaire Velero dans votre cluster.

Procédure

  • Afin de supprimer la sauvegarde, exécutez la commande Velero suivante:

    $ velero backup delete <backup_name> -n openshift-adp 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde.
1.8.5.3. À propos de la maintenance du référentiel Kopia

Il existe deux types d’entretien du référentiel Kopia:

Entretien rapide
  • Fonctionne toutes les heures pour maintenir le nombre de blobs d’index (n) bas. Le nombre élevé d’indices affecte négativement la performance des opérations de Kopia.
  • Il ne supprime aucune métadonnées du référentiel sans s’assurer qu’une autre copie des mêmes métadonnées existe.
Entretien complet
  • Fonctionne toutes les 24 heures pour effectuer la collecte des ordures du contenu du dépôt qui ne sont plus nécessaires.
  • Snapshot-gc, une tâche de maintenance complète, trouve tous les fichiers et listes d’annuaires qui ne sont plus accessibles à partir des manifestes instantanés et les marquent comme supprimés.
  • La maintenance complète est une opération rentable, car elle nécessite l’analyse de tous les répertoires dans tous les instantanés qui sont actifs dans le cluster.
1.8.5.3.1. Kopia maintenance dans OADP

Les tâches repo-maintain-job sont exécutées dans l’espace de noms où OADP est installé, comme indiqué dans l’exemple suivant:

pod/repo-maintain-job-173...2527-2nbls                             0/1     Completed   0          168m
pod/repo-maintain-job-173....536-fl9tm                             0/1     Completed   0          108m
pod/repo-maintain-job-173...2545-55ggx                             0/1     Completed   0          48m
Copy to Clipboard

Consultez les journaux du travail repo-maintain pour plus de détails sur le nettoyage et la suppression des artefacts dans le stockage d’objets de sauvegarde. Comme indiqué dans l’exemple suivant, vous pouvez trouver une note dans l’emploi repo-maintain lorsque la prochaine maintenance complète du cycle est due:

not due for full maintenance cycle until 2024-00-00 18:29:4
Copy to Clipboard
Important

Les trois exécutions réussies d’un cycle de maintenance complet sont nécessaires pour que les objets soient supprimés du stockage d’objets de sauvegarde. Cela signifie que vous pouvez vous attendre jusqu’à 72 heures pour que tous les artefacts du stockage d’objet de sauvegarde soient supprimés.

1.8.5.4. La suppression d’un référentiel de sauvegarde

Après que vous avez supprimé la sauvegarde, et après que les cycles de maintenance du référentiel Kopia pour supprimer les artefacts connexes sont terminés, la sauvegarde n’est plus référencée par aucune métadonnées ou objets manifestes. Ensuite, vous pouvez supprimer la ressource personnalisée (CR) de backuprepository pour terminer le processus de suppression de sauvegarde.

Conditions préalables

  • La sauvegarde de votre application a été supprimée.
  • Jusqu’à 72 heures après la suppression de la sauvegarde. Ce délai permet à Kopia d’exécuter les cycles de maintenance du dépôt.

Procédure

  1. Afin d’obtenir le nom du référentiel de sauvegarde CR pour une sauvegarde, exécutez la commande suivante:

    $ oc get backuprepositories.velero.io -n openshift-adp
    Copy to Clipboard
  2. Afin de supprimer le référentiel de sauvegarde CR, exécutez la commande suivante:

    $ oc delete backuprepository <backup_repository_name> -n openshift-adp 
    1
    Copy to Clipboard
    1
    Indiquez le nom du référentiel de sauvegarde de l’étape précédente.

1.9. La restauration de l’OADP

1.9.1. La restauration des applications

Les sauvegardes d’applications sont restaurées en créant une ressource personnalisée de restauration (CR). Découvrez la création d’un CR de restauration.

Il est possible de créer des crochets de restauration pour exécuter des commandes dans un conteneur dans un pod en éditant le CR Restaurer. Découvrez Créer des crochets de restauration.

1.9.1.1. Aperçu des ressources avant d’exécuter la sauvegarde et la restauration

L’OADP sauvegarde les ressources applicatives en fonction du type, de l’espace de noms ou de l’étiquette. Cela signifie que vous pouvez afficher les ressources une fois la sauvegarde terminée. De même, vous pouvez voir les objets restaurés en fonction de l’espace de noms, du volume persistant (PV) ou de l’étiquette après la fin d’une opération de restauration. Afin de prévisualiser les ressources à l’avance, vous pouvez effectuer un cycle sec des opérations de sauvegarde et de restauration.

Conditions préalables

  • L’opérateur OADP a été installé.

Procédure

  1. Afin de prévisualiser les ressources incluses dans la sauvegarde avant d’exécuter la sauvegarde réelle, exécutez la commande suivante:

    $ velero backup create <backup-name> --snapshot-volumes false 
    1
    Copy to Clipboard
    1
    Indiquez la valeur du paramètre --snapshot-volumes comme false.
  2. Afin de connaître plus de détails sur les ressources de sauvegarde, exécutez la commande suivante:

    $ velero describe backup <backup_name> --details 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde.
  3. Afin de prévisualiser les ressources incluses dans la restauration avant d’exécuter la restauration réelle, exécutez la commande suivante:

    $ velero restore create --from-backup <backup-name> 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la sauvegarde créée pour examiner les ressources de sauvegarde.
    Important

    La commande de création de la restauration velero crée des ressources de restauration dans le cluster. Après avoir examiné les ressources, vous devez supprimer les ressources créées dans le cadre de la restauration.

  4. Afin de connaître plus de détails sur les ressources de restauration, exécutez la commande suivante:

    $ velero describe restore <restore_name> --details 
    1
    Copy to Clipboard
    1
    Indiquez le nom de la restauration.
1.9.1.2. Création d’un CR de restauration

La restauration d’une ressource personnalisée de sauvegarde (CR) en créant un CR de restauration.

Conditions préalables

  • Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
  • Le DataProtectionApplication CR doit être dans un état prêt.
  • Il faut avoir un Velero Backup CR.
  • La capacité de volume persistant (PV) doit correspondre à la taille demandée au moment de la sauvegarde. Ajustez la taille demandée si nécessaire.

Procédure

  1. Créer un CR Restaurer, comme dans l’exemple suivant:

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      backupName: <backup> 
    1
    
      includedResources: [] 
    2
    
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      restorePVs: true 
    3
    Copy to Clipboard
    1
    Le nom du Backup CR.
    2
    Facultatif : Spécifiez un éventail de ressources à inclure dans le processus de restauration. Les ressources peuvent être des raccourcis (par exemple, po pour les pods) ou entièrement qualifiés. En cas d’absence de précision, toutes les ressources sont incluses.
    3
    Facultatif: Le paramètre de restaurationPVs peut être défini sur false pour désactiver la restauration de PersistentVolumes à partir de VolumeSnapshot of Container Storage Interface (CSI) instantanés ou à partir de snapshots natifs lorsque VolumeSnapshotLocation est configuré.
  2. Assurez-vous que l’état de la Restauration CR est complété en entrant la commande suivante:

    $ oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
    Copy to Clipboard
  3. Assurez-vous que les ressources de sauvegarde ont été restaurées en entrant la commande suivante:

    $ oc get all -n <namespace> 
    1
    Copy to Clipboard
    1
    Espace de noms que vous avez sauvegardé.
  4. Lorsque vous rétablissez DeploymentConfig avec des volumes ou si vous utilisez des crochets post-restauration, exécutez le script de nettoyage dc-post-restore.sh en entrant la commande suivante:

    $ bash dc-restic-post-restore.sh -> dc-post-restore.sh
    Copy to Clipboard
    Note

    Au cours du processus de restauration, les plug-ins OADP Velero réduisent les objets DeploymentConfig et restaurent les pods en tant que gousses autonomes. Ceci est fait pour empêcher le cluster de supprimer les pods restaurés DeploymentConfig immédiatement sur la restauration et pour permettre aux crochets de restauration et de post-restauration de compléter leurs actions sur les gousses restaurées. Le script de nettoyage ci-dessous supprime ces pods déconnectés et met à l’échelle tous les objets DeploymentConfig vers le nombre approprié de répliques.

    Exemple 1.1. DC-restic-post-restore.sh → script de nettoyage dc-post-restore.sh

    #!/bin/bash
    set -e
    
    # if sha256sum exists, use it to check the integrity of the file
    if command -v sha256sum >/dev/null 2>&1; then
      CHECKSUM_CMD="sha256sum"
    else
      CHECKSUM_CMD="shasum -a 256"
    fi
    
    label_name () {
        if [ "${#1}" -le "63" ]; then
    	echo $1
    	return
        fi
        sha=$(echo -n $1|$CHECKSUM_CMD)
        echo "${1:0:57}${sha:0:6}"
    }
    
    if [[ $# -ne 1 ]]; then
        echo "usage: ${BASH_SOURCE} restore-name"
        exit 1
    fi
    
    echo "restore: $1"
    
    label=$(label_name $1)
    echo "label:   $label"
    
    echo Deleting disconnected restore pods
    oc delete pods --all-namespaces -l oadp.openshift.io/disconnected-from-dc=$label
    
    for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}')
    do
        IFS=',' read -ra dc_arr <<< "$dc"
        if [ ${#dc_arr[0]} -gt 0 ]; then
    	echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]}
    	cat <<EOF | oc patch dc  -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin
    spec:
      replicas: ${dc_arr[2]}
      paused: ${dc_arr[3]}
    EOF
        fi
    done
    Copy to Clipboard
1.9.1.3. Créer des crochets de restauration

Créez des crochets de restauration pour exécuter des commandes dans un conteneur dans un pod en éditant la ressource personnalisée Restaurer (CR).

Il est possible de créer deux types de crochets de restauration:

  • Le crochet init ajoute un conteneur init à un pod pour effectuer des tâches de configuration avant le démarrage du conteneur de l’application.

    En cas de restauration d’une sauvegarde Restic, le conteneur init d’attente restique est ajouté avant le conteneur d’entrée du crochet de restauration.

  • Le crochet exec exécute des commandes ou des scripts dans un conteneur d’un pod restauré.

Procédure

  • Ajoutez un crochet au bloc spec.hooks de la Restauration CR, comme dans l’exemple suivant:

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 
    1
    
            excludedNamespaces:
            - <namespace>
            includedResources:
            - pods 
    2
    
            excludedResources: []
            labelSelector: 
    3
    
              matchLabels:
                app: velero
                component: server
            postHooks:
            - init:
                initContainers:
                - name: restore-hook-init
                  image: alpine:latest
                  volumeMounts:
                  - mountPath: /restores/pvc1-vm
                    name: pvc1-vm
                  command:
                  - /bin/ash
                  - -c
                timeout: 
    4
    
            - exec:
                container: <container> 
    5
    
                command:
                - /bin/bash 
    6
    
                - -c
                - "psql < /backup/backup.sql"
                waitTimeout: 5m 
    7
    
                execTimeout: 1m 
    8
    
                onError: Continue 
    9
    Copy to Clipboard
    1
    Facultatif: Arrivée des espaces de noms auxquels le crochet s’applique. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les espaces de noms.
    2
    Actuellement, les pods sont la seule ressource prise en charge à laquelle les crochets peuvent s’appliquer.
    3
    Facultatif: Ce crochet ne s’applique qu’aux objets correspondant au sélecteur d’étiquette.
    4
    Facultatif: Timeout spécifie la durée maximale d’attente de Velero pour que les conteneurs init se terminent.
    5
    Facultatif: Si le conteneur n’est pas spécifié, la commande s’exécute dans le premier conteneur dans le pod.
    6
    C’est le point d’entrée pour le conteneur d’init ajouté.
    7
    Facultatif: Combien de temps pour attendre qu’un conteneur soit prêt. Cela devrait être assez long pour que le conteneur puisse démarrer et pour que tous les crochets précédents dans le même conteneur soient terminés. Dans le cas contraire, le processus de restauration attend indéfiniment.
    8
    Facultatif: Combien de temps pour attendre que les commandes s’exécutent. La valeur par défaut est 30s.
    9
    Les valeurs autorisées pour le traitement des erreurs sont l’échec et la poursuite:
    • Continuer: Seuls les échecs de commande sont enregistrés.
    • Échec: Plus les crochets de restauration s’exécutent dans n’importe quel conteneur dans n’importe quelle gousse. Le statut de la Restauration CR sera partiellement affiné.
Important

Lors d’une opération de restauration de système de fichiers (FSB), une ressource de déploiement faisant référence à un ImageStream n’est pas restaurée correctement. La gousse restaurée qui exécute le FSB, et le postHook est interrompu prématurément.

Cela se produit parce que, pendant l’opération de restauration, le contrôleur OpenShift met à jour le champ spec.template.spec.containers dans la ressource Déploiement avec un hachage ImageStreamTag mis à jour. La mise à jour déclenche le déploiement d’un nouveau pod, mettant fin à la gousse sur laquelle velero exécute le FSB et le crochet de restauration de poste. En savoir plus sur le déclencheur du flux d’images, voir « Triggering update on image stream changes ».

La solution de contournement de ce comportement est un processus de restauration en deux étapes:

  1. D’abord, effectuer une restauration à l’exclusion des ressources de déploiement, par exemple:

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --exclude-resources=deployment.apps
    Copy to Clipboard
  2. Après le succès de la première restauration, effectuez une deuxième restauration en incluant ces ressources, par exemple:

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --include-resources=deployment.apps
    Copy to Clipboard

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat