Skip to main content
NetApp Backup and Recovery
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utilisez les paramètres avancés de restauration des ressources personnalisées

Contributeurs netapp-mwallis
PDF

Vous pouvez personnaliser les opérations de restauration à l'aide de paramètres avancés tels que les annotations, les paramètres de namespace et les options de stockage pour répondre à vos besoins spécifiques.

Annotations et étiquettes d'espace de noms lors des opérations de restauration et de basculement

Lors de la restauration et du basculement, les étiquettes et annotations de l'espace de noms de destination sont mises à jour pour correspondre à la source : les clés de la source sont ajoutées ou remplacent les clés de destination, tandis que les clés qui existent uniquement dans la destination restent inchangées.

Remarque Dans Red Hat OpenShift, les annotations d'espace de noms sont importantes car elles garantissent que les pods restaurés reçoivent les contraintes et autorisations de contexte de sécurité appropriées, leur permettant ainsi d'accéder aux volumes et de s'exécuter sans erreurs d'autorisation. Pour plus d'informations, consultez la "Documentation des contraintes de contexte de sécurité OpenShift".

Définissez la variable d'environnement Kubernetes

RESTORE_SKIP_NAMESPACE_ANNOTATIONS

avant la restauration ou le basculement pour éviter que des annotations spécifiques de l’espace de noms de destination ne soient écrasées. Par exemple :

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
Remarque Lors d'une restauration ou d'un basculement, les annotations et étiquettes d'espace de noms spécifiées dans restoreSkipNamespaceAnnotations et restoreSkipNamespaceLabels sont exclues de l'opération de restauration ou de basculement. Assurez-vous que ces paramètres sont configurés lors de l'installation initiale de Helm. Pour en savoir plus, consultez "Configurer des paramètres supplémentaires du chart Helm Trident Protect".

Si vous avez utilisé Helm avec le --create-namespace paramètre pour installer l’application source, Trident Protect copie l’étiquette name dans l’espace de noms de destination. Si la valeur de l’étiquette correspond au nom de l’espace de noms source, elle est remplacée par celui de l’espace de noms de destination ; sinon, elle est conservée.

Exemple

L'exemple suivant montre les espaces de noms source et de destination avec des étiquettes et des annotations différentes, et affiche l'espace de noms de destination avant et après l'opération pour illustrer comment les clés sont ajoutées, fusionnées ou écrasées.

Avant l'opération de restauration ou de basculement

Le tableau suivant illustre l'état des espaces de noms source et de destination de l'exemple avant l'opération de restauration ou de basculement :

Espace de noms Annotations Étiquettes

Espace de noms ns-1 (source)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • environment=production

  • conformité=hipaa

  • name=ns-1

Espace de noms ns-2 (destination)

  • annotation.one/key: "true"

  • annotation.three/key: "false"

  • rôle=base de données

Après l'opération de restauration

Le tableau suivant illustre l'état de l'espace de noms de destination après l'opération de restauration ou de basculement. Certaines clés ont été ajoutées, d'autres ont été écrasées, et l' `name`étiquette a été mise à jour pour correspondre à l'espace de noms de destination :

Espace de noms Annotations Étiquettes

Espace de noms ns-2 (destination)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • conformité=hipaa

  • environment=production

  • rôle=base de données

Champs pris en charge

Cette section décrit les champs supplémentaires disponibles pour les opérations de restauration.

Correspondance des classes de stockage

L' `spec.storageClassMapping`attribut définit une correspondance entre une classe de stockage présente dans l'application source et une nouvelle classe de stockage sur le cluster cible. Vous pouvez l'utiliser lors de la migration d'applications entre des clusters avec des classes de stockage différentes ou lors du changement de système de stockage pour les opérations BackupRestore.

Exemple :

storageClassMapping:
  - destination: "destinationStorageClass1"
    source: "sourceStorageClass1"
  - destination: "destinationStorageClass2"
    source: "sourceStorageClass2"

Annotations prises en charge

Cette section répertorie les annotations prises en charge pour configurer différents comportements du système. Si une annotation n'est pas explicitement définie par l'utilisateur, le système utilisera la valeur par défaut.

Annotation Type Description valeur par défaut

protect.trident.netapp.io/data-mover-timeout-sec

chaîne

Le temps maximal (en secondes) autorisé pour que l'opération de déplacement de données soit bloquée.

"300"

protect.trident.netapp.io/kopia-content-cache-size-limit-mb

chaîne

La limite de taille maximale (en mégaoctets) pour le cache de contenu Kopia.

"1000"

protect.trident.netapp.io/pvc-bind-timeout-sec

chaîne

Temps maximal (en secondes) d'attente pour que tout nouveau PersistentVolumeClaims (PVC) atteigne la phase Bound avant que l'opération n'échoue. S'applique à tous les types de CR de restauration (BackupRestore, BackupInplaceRestore, SnapshotRestore, SnapshotInplaceRestore). Utilisez une valeur plus élevée si votre backend de stockage ou votre cluster nécessite souvent plus de temps.

"1200" (20 minutes)