15.4. Restauration des machines virtuelles


Vous restaurez une ressource personnalisée (CR) OpenShift API for Data Protection (OADP) Backup en créant une CRRestore .

Vous pouvez ajouter des crochets au CR Restore pour exécuter des commandes dans les conteneurs d'initialisation, avant le démarrage du conteneur d'application ou dans le conteneur d'application lui-même.

15.4.1. Création d'un CR de restauration

Vous restaurez une ressource personnalisée (CR) Backup en créant une CR Restore.

Conditions préalables

  • Vous devez installer l'opérateur OpenShift API for Data Protection (OADP).
  • Le CR DataProtectionApplication doit être dans un état Ready.
  • Vous devez avoir un Velero Backup CR.
  • Ajustez la taille demandée pour que la capacité du volume persistant (PV) corresponde à la taille demandée au moment de la sauvegarde.

Procédure

  1. Créez un CR Restore, 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
    1
    Nom du CR Backup.
    2
    Facultatif. Spécifiez un tableau de ressources à inclure dans le processus de restauration. Les ressources peuvent être des raccourcis (par exemple, "po" pour "pods") ou être entièrement qualifiées. Si rien n'est spécifié, toutes les ressources sont incluses.
  2. Vérifiez que l'état du CR Restore est Completed en entrant la commande suivante :

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
  3. Vérifiez que les ressources de sauvegarde ont été restaurées en entrant la commande suivante :

    $ oc get all -n <namespace> 1
    1
    Namespace que vous avez sauvegardé.
  4. Si vous utilisez Restic pour restaurer les objets DeploymentConfig ou si vous utilisez des crochets post-restauration, exécutez le script de nettoyage dc-restic-post-restore.sh en entrant la commande suivante :

    bash dc-restic-post-restore.sh <restore-name>
    Note

    Au cours du processus de restauration, les plug-ins OADP Velero réduisent les objets DeploymentConfig et restaurent les pods en tant que pods autonomes pour éviter que le cluster ne supprime les pods DeploymentConfig restaurés immédiatement après la restauration et pour permettre aux hooks Restic et post-restauration de terminer leurs actions sur les pods restaurés. Le script de nettoyage supprime ces pods déconnectés et met à l'échelle tous les objets DeploymentConfig jusqu'au nombre approprié de répliques.

    Exemple 15.1. dc-restic-post-restore.sh script de nettoyage

    #!/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}"
    }
    
    OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp}
    
    if [[ $# -ne 1 ]]; then
        echo "usage: ${BASH_SOURCE} restore-name"
        exit 1
    fi
    
    echo using OADP Namespace $OADP_NAMESPACE
    echo restore: $1
    
    label=$(label_name $1)
    echo label: $label
    
    echo Deleting disconnected restore pods
    oc delete pods -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

15.4.1.1. Création de crochets de restauration

Vous créez des crochets de restauration pour exécuter des commandes dans un conteneur dans un pod tout en restaurant votre application en modifiant la ressource personnalisée (CR) Restore.

Vous pouvez créer deux types de crochets de restauration :

  • Un crochet init ajoute un conteneur init à un pod pour effectuer des tâches de configuration avant que le conteneur d'application ne démarre.

    Si vous restaurez une sauvegarde Restic, le conteneur init restic-wait est ajouté avant le conteneur init restore hook.

  • Un hook exec exécute des commandes ou des scripts dans un conteneur d'un pod restauré.

Procédure

  • Ajoutez un crochet au bloc spec.hooks du CR Restore, 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
    1
    Facultatif : Tableau des espaces de noms auxquels le crochet s'applique. Si 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 indique la durée maximale pendant laquelle Velero attend la fin de initContainers.
    5
    Facultatif : si le conteneur n'est pas spécifié, la commande s'exécute dans le premier conteneur du pod.
    6
    Il s'agit du point d'entrée du conteneur init ajouté.
    7
    Facultatif : durée d'attente pour qu'un conteneur soit prêt. Cette durée doit être suffisante pour que le conteneur démarre et que tous les crochets précédents dans le même conteneur soient terminés. S'il n'est pas défini, le processus de restauration attend indéfiniment.
    8
    Facultatif : durée d'attente pour l'exécution des commandes. La valeur par défaut est 30s.
    9
    Les valeurs autorisées pour le traitement des erreurs sont Fail et Continue:
    • Continue: Seuls les échecs de commande sont consignés.
    • Fail: Plus aucun crochet de restauration n'est exécuté dans aucun conteneur, dans aucun pod. Le statut du CR Restore sera PartiallyFailed.
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.

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 leBlog 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.

© 2024 Red Hat, Inc.