## Introduction

Helm est le gestionnaire de paquets de facto pour Kubernetes, permettant aux développeurs et aux opérateurs de déployer des applications complexes avec une seule commande. Cependant, comme pour toute infrastructure critique, l'état de vos versions Helm peut être perdu en raison d'une suppression accidentelle, d'une défaillance du cluster ou d'une mauvaise configuration. Ce guide fournit des instructions pratiques, étape par étape, pour sauvegarder et restaurer les versions Helm, valider vos sauvegardes et planifier la reprise après sinistre. En suivant ces procédures, vous pouvez minimiser les temps d'arrêt et garantir que vos applications Kubernetes peuvent être récupérées rapidement et de manière fiable.

Dans cet article, vous apprendrez à inventorier votre environnement, à mettre en œuvre un chemin de configuration sûr pour les sauvegardes, à vérifier l'intégrité de vos sauvegardes, à gérer les modes de défaillance courants et à établir une liste de contrôle opérationnelle. Chaque étape majeure comprend des commandes concrètes, des extraits de configuration et des sorties attendues pour vous aider à exécuter ces tâches dans vos propres clusters.

## Inventaire des versions et de l'environnement

Avant de mettre en œuvre une stratégie de sauvegarde, vous devez comprendre votre environnement actuel. Cela inclut les versions de Helm et de Kubernetes que vous utilisez, le backend de stockage utilisé par Helm, ainsi que les emplacements de vos configurations de version et de vos secrets.

### Déterminer les versions de Helm et de Kubernetes

Exécutez les commandes suivantes pour vérifier les versions de votre client et de votre serveur Helm :

helm version --short
kubectl version --short 
 Sortie attendue (exemple) :

v3.12.0+g3a31588
Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3 
 Connaître votre version de Helm est crucial car Helm 2 et Helm 3 ont des mécanismes de stockage fondamentalement différents. Helm 2 utilisait Tiller et stockait les informations de version dans des ConfigMaps, tandis que Helm 3 stocke les informations de version sous forme de Secrets Kubernetes par défaut dans l'espace de noms de la version. Ce guide suppose Helm 3.

### Identifier le backend de stockage

Par défaut, Helm 3 utilise des Secrets pour le stockage. Vérifiez cela en consultant la configuration de Helm :

helm env 
 Recherchez la variable HELM_DRIVER . Si elle n'est pas définie, elle prend par défaut la valeur secret . Vous pouvez également inspecter l'objet de stockage d'une version existante :

kubectl get secrets -n <namespace> | grep sh.helm.release 
 Exemple de sortie :

sh.helm.release.v1.myapp.v1 helm.sh/release.v1 1 5d 
 Alternativement, si vous avez configuré Helm pour utiliser des ConfigMaps (en définissant HELM_DRIVER=configmap ), vous verriez plutôt des ConfigMaps. Connaître le backend de stockage est essentiel pour sauvegarder les bonnes ressources.

### Inventorier les espaces de noms et les versions

Listez toutes les versions Helm dans tous les espaces de noms :

helm list --all-namespaces 
 Exemple de sortie :

NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myapp default 1 2023-10-01 12:34:56.789 deployed myapp-1.2.3 1.0.0
web production 3 2023-09-15 09:15:22.123 deployed nginx-1.5.0 1.23.0 
 Enregistrez les espaces de noms et les noms des versions. Identifiez également les définitions de ressources personnalisées (CRD) ou les volumes persistants associés à vos versions, car ils peuvent nécessiter des stratégies de sauvegarde distinctes.

### Prérequis pour les outils de sauvegarde

Pour effectuer des sauvegardes, vous aurez besoin de :

- kubectl configuré avec un accès approprié au cluster.

- Le client helm installé.

- Optionnel : jq pour le traitement JSON, bien que ce ne soit pas strictement requis.

- Pour les sauvegardes au niveau du stockage (par exemple, les données des volumes persistants), un accès aux outils de snapshot de votre fournisseur cloud ou à une API de stockage.

## Chemin de configuration sûr

Une stratégie de sauvegarde sûre doit être limitée pour minimiser l'impact et les risques. Au lieu de sauvegarder l'ensemble du cluster sans discernement, concentrez-vous sur les métadonnées des versions Helm et les ressources Kubernetes associées qui sont critiques pour la récupération.

### Sauvegarder les métadonnées des versions Helm

Les métadonnées des versions Helm incluent la version du chart, les valeurs utilisées et le statut de la version. Sauvegarder ces métadonnées vous permet de reconstruire l'historique des versions et de faire un rollback si nécessaire.

### Option 1 : Utiliser helm get pour exporter les informations de version

Pour chaque version, vous pouvez exporter ses valeurs et son manifeste :

# Exporter les valeurs fournies par l'utilisateur
helm get values <release-name> -n <namespace> -o yaml > release-values.yaml

# Exporter le manifeste complet tel que déployé
helm get manifest <release-name> -n <namespace> > release-manifest.yaml 
 Exemple de commande et de sortie pour les valeurs :

$ helm get values myapp -n default -o yaml
USER-SUPPLIED VALUES:
replicaCount: 3
image:
 repository: nginx
 tag: latest
service:
 type: LoadBalancer 
 Notez que helm get values ne renvoie que les valeurs fournies par l'utilisateur, pas les valeurs par défaut. Si vous avez besoin des valeurs effectives, y compris les valeurs par défaut, utilisez helm get values --all .

### Option 2 : Sauvegarder directement les objets de stockage Helm

Étant donné que Helm stocke les informations de version dans des Secrets Kubernetes (ou des ConfigMaps), vous pouvez sauvegarder ces objets directement. Pour le stockage basé sur des Secrets :

kubectl get secrets -n <namespace> -l owner=helm -o yaml > helm-secrets-<namespace>.yaml 
 Cette commande exporte tous les secrets de version Helm dans l'espace de noms. L'étiquette owner=helm est appliquée par défaut aux secrets de version Helm 3. Pour le stockage sous forme de ConfigMap, remplacez secrets par configmaps .

Pour plusieurs espaces de noms, faites une boucle :

for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
 kubectl get secrets -n $ns -l owner=helm -o yaml > helm-secrets-$ns.yaml
done 
 Stockez ces fichiers YAML dans un emplacement sécurisé et versionné.

### Sauvegarder les ressources Kubernetes associées

Les versions Helm créent souvent des Deployments, des Services, des ConfigMaps, des Secrets et d'autres ressources. Bien que celles-ci puissent être reconstruites à partir du chart et des valeurs, avoir une sauvegarde des ressources en direct peut accélérer la récupération et capturer toute modification manuelle.

Utilisez kubectl pour exporter les ressources étiquetées avec la version :

# Obtenir toutes les ressources pour une version en utilisant l'étiquette de version
kubectl get all -n <namespace> -l app.kubernetes.io/managed-by=Helm -o yaml > release-resources.yaml 
 Remarque : L'étiquette app.kubernetes.io/managed-by=Helm est couramment ajoutée par les charts Helm 3, mais tous les charts ne l'incluent pas. Vérifiez les étiquettes sur vos ressources et ajustez en conséquence. Alternativement, vous pouvez capturer toutes les ressources de l'espace de noms, mais cela peut inclure des ressources non Helm.

### Sauvegarder les CRD

Si vos charts installent ou dépendent de définitions de ressources personnalisées (CRD), sauvegardez-les séparément :

kubectl get crds -o yaml > crds.yaml 
 Les CRD sont au niveau du cluster et ne sont pas liées à un espace de noms, donc une seule exportation couvre tout.

### Sauvegarder les données des volumes persistants

Les sauvegardes Helm n'incluent généralement pas les données stockées dans les PersistentVolumes. Vous devez mettre en œuvre une stratégie de sauvegarde distincte pour les données persistantes, par exemple en utilisant la capacité de snapshot de votre fournisseur cloud, Velero ou un outil de sauvegarde spécifique à la base de données. Pour la démonstration, voici un exemple utilisant un snapshot pour un fournisseur cloud hypothétique :

# Exemple pour une CLI de fournisseur cloud (hypothétique)
cloud-provider snapshot create --volume-id <pv-id> --snapshot-name myapp-snapshot-$(date +%Y%m%d) 
 Cette commande crée un snapshot du PersistentVolume. La commande exacte dépend de votre environnement.

### Automatisation et planification

Pour des sauvegardes régulières, planifiez les commandes d'exportation à l'aide de tâches cron ou d'un pipeline CI/CD. Voici un exemple de script shell simple qui sauvegarde toutes les versions Helm :

#!/bin/bash
BACKUP_DIR="/backups/helm/$(date +%Y%m%d_%H%M%S)"
mkdir -p $BACKUP_DIR
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
 kubectl get secrets -n $ns -l owner=helm -o yaml > $BACKUP_DIR/helm-secrets-$ns.yaml
done
# Optionnellement, télécharger vers un stockage distant
# aws s3 cp $BACKUP_DIR s3://my-helm-backups/ --recursive 
 Planifiez ce script via une tâche cron sur une machine de gestion ou un CronJob Kubernetes si vous préférez l'exécuter à l'intérieur du cluster.

## Vérification et diagnostic

Après avoir créé des sauvegardes, vous devez vérifier qu'elles sont complètes et utilisables. Cette section fournit des contrôles pour garantir que vos sauvegardes sont valides et que vous pouvez les restaurer en cas de besoin.

### Valider les fichiers de sauvegarde

Pour les exportations YAML, assurez-vous que les fichiers sont syntaxiquement corrects et contiennent les ressources attendues. Utilisez kubectl apply --dry-run=client pour valider sans appliquer :

kubectl apply --dry-run=client -f helm-secrets-default.yaml 
 Sortie attendue si valide :

secret/sh.helm.release.v1.myapp.v1 created (dry run) 
 Si le fichier est mal formé, vous verrez des erreurs de syntaxe.

Pour la sortie de helm get , vérifiez que les valeurs et le manifeste sont non vides et s'analysent correctement :

helm get values myapp -n default -o yaml | yq eval '.' - 
 Vous pouvez également comparer les valeurs exportées à un ensemble de valeurs connu et correct.

### Tester la restauration dans un environnement de test

La meilleure vérification consiste à effectuer une restauration de test dans un espace de noms ou un cluster séparé. Cela garantit que la sauvegarde contient toutes les informations nécessaires pour recréer la version.

### Restaurer à partir d'une sauvegarde de Secrets

Si vous avez sauvegardé les Secrets de version, vous pouvez les restaurer en appliquant le YAML au cluster cible. Cependant, le simple fait d'appliquer le Secret peut ne pas enregistrer correctement la version dans le stockage de Helm car Helm utilise des annotations et des étiquettes spécifiques. Une approche plus sûre consiste à utiliser helm install avec les valeurs exportées et la même version du chart.

- Exportez la version du chart utilisée :

helm show chart <release-name> -n <namespace> | grep version 

- Installez le chart avec la même version et les valeurs exportées :

 helm install <release-name> <chart-repo>/<chart-name> --version <chart-version> --values release-values.yaml -n <namespace> 
 Exemple :

helm install myapp myrepo/myapp --version 1.2.3 --values release-values.yaml -n default 
 Sortie attendue :

NAME: myapp
LAST DEPLOYED: Mon Oct 2 10:00:00 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1 

### Restaurer directement à partir de l'objet de stockage (avancé)

 Si vous préférez restaurer les métadonnées de version exactes, y compris l'historique des révisions, vous pouvez appliquer les Secrets sauvegardés puis informer Helm. Cependant, cela n'est pas recommandé pour la plupart des utilisateurs car Helm peut ne pas reconnaître la version. Pour être complet, voici une méthode :

- Appliquez le Secret sauvegardé :

kubectl apply -f helm-secrets-default.yaml 

- Vérifiez si Helm voit la version :

 helm list -n default 
 Si la version apparaît, tant mieux. Sinon, vous devrez peut-être ajuster manuellement les étiquettes et les annotations.

### Diagnostiquer la couverture de la sauvegarde

Assurez-vous que toutes les versions sont sauvegardées. Comparez la liste des versions de helm list --all-namespaces avec les fichiers de sauvegarde. Écrivez un script simple pour vérifier les espaces de noms ou les versions manquants.

Par exemple, une vérification rapide :

# Comparer la liste des versions aux fichiers de sauvegarde
helm list --all-namespaces -o json | jq -r '.[].name' | sort > /tmp/releases.txt
ls helm-secrets-*.yaml | sed 's/helm-secrets-//;s/\.yaml//' | sort > /tmp/backups.txt
diff /tmp/releases.txt /tmp/backups.txt 
 Si diff n'affiche aucune sortie, toutes les versions sont prises en compte.

### Vérifier les snapshots de volumes persistants

Pour les snapshots de PV, vérifiez que le snapshot a été créé avec succès et peut être utilisé pour restaurer un volume. Par exemple, en utilisant une CLI cloud (hypothétique) :

cloud-provider snapshot list --volume-id <pv-id> 
 La sortie attendue montre le snapshot avec le statut available .

Si vous utilisez Velero ou un outil similaire, consultez ses journaux et son statut de sauvegarde pour vous assurer que les données PV sont incluses.

## Modes de défaillance et récupération

Malgré tous les efforts, des défaillances peuvent survenir. Comprendre les modes de défaillance courants et avoir un plan de récupération est essentiel.

### Scénarios de défaillance courants

- Suppression accidentelle d'une version Helm : Si vous exécutez helm uninstall , l'historique de la version est supprimé. La récupération nécessite une réinstallation à partir de la sauvegarde.

- Secret de version corrompu ou manquant : Si le Secret est supprimé, Helm perd la trace de la version, mais les ressources déployées restent. Vous devrez peut-être recréer le Secret ou adopter les ressources existantes.

- Défaillance du cluster : Si l'ensemble du cluster est perdu, vous devez restaurer à partir de sauvegardes hors cluster.

- Perte de données persistantes : Les sauvegardes de métadonnées Helm ne protègent pas les données applicatives ; si les données PV sont perdues, vous avez besoin de restaurations de snapshots.

### Procédures de rollback et de récupération

### Scénario 1 : helm uninstall accidentel

Si vous avez une sauvegarde des valeurs de version et de la version du chart, réinstallez :

helm install <release-name> <chart> --version <version> --values release-values.yaml -n <namespace> 
 Cela crée une nouvelle version avec le même nom. Notez que l'historique des révisions est réinitialisé ; si vous aviez plusieurs révisions, vous les perdez à moins d'avoir sauvegardé les objets de stockage.

Pour conserver l'historique des révisions, évitez de désinstaller et préférez helm rollback vers une révision précédente. Cependant, si la désinstallation a déjà eu lieu, la réinstallation est la seule option.

### Scénario 2 : Secret de version manquant

Si le Secret est supprimé mais que les ressources sont toujours en cours d'exécution, vous pouvez utiliser helm adopt (disponible dans Helm 3.13+) pour adopter les ressources existantes dans une nouvelle version. Pour les versions plus anciennes, vous pouvez recréer le Secret manuellement. Exemple avec helm adopt :

helm adopt myapp -n default --kube-context mycluster 
 helm adopt interroge le cluster pour les ressources correspondant au nom et aux étiquettes de la version, puis crée les métadonnées de version nécessaires.

Si helm adopt n'est pas disponible, vous pouvez créer une nouvelle version avec helm install en utilisant les ressources existantes, mais vous devrez peut-être les annoter pour éviter les conflits.

### Scénario 3 : Récupération complète du cluster

En cas de sinistre, suivez un runbook documenté. Étapes clés :

- Provisionnez un nouveau cluster Kubernetes.

- Restaurez d'abord les CRD : kubectl apply -f crds.yaml .

- Restaurez les volumes persistants à partir des snapshots.

- Réinstallez les versions Helm en utilisant les valeurs sauvegardées et les versions de chart.

- Vérifiez la santé des applications.

### Tester la récupération

Testez régulièrement les procédures de récupération pour vous assurer qu'elles fonctionnent. Planifiez un exercice de reprise après sinistre trimestriel où vous simulez une défaillance et restaurez à partir des sauvegardes dans un cluster de préproduction.

## Pièges courants et comment les éviter

Même avec un plan de sauvegarde solide, des erreurs surviennent. Voici quelques pièges fréquents dans les processus de sauvegarde et de restauration Helm, pourquoi ils se produisent et comment les éviter ou s'en remettre.

### 1. Ne pas sauvegarder le bon backend de stockage

Pourquoi cela arrive : Helm 3 utilise par défaut des Secrets, mais certains clusters sont configurés pour utiliser des ConfigMaps via HELM_DRIVER . Si vous supposez des Secrets et que votre cluster utilise des ConfigMaps, votre sauvegarde sera vide.

Comment l'éviter : Exécutez toujours helm env pour confirmer le pilote de stockage avant d'exécuter des commandes de sauvegarde. Ajustez vos commandes de sauvegarde en conséquence.

Récupération : Si vous découvrez l'erreur après une défaillance, vérifiez le pilote actuel et exécutez la bonne commande de sauvegarde. Assurez-vous également que vos scripts de sauvegarde détectent dynamiquement le pilote.

### 2. Omettre les données des PersistentVolumes

Pourquoi cela arrive : De nombreux opérateurs se concentrent uniquement sur les métadonnées Helm et oublient que les données applicatives vivent en dehors des objets de version. Une restauration qui ramène le déploiement mais pas les données de la base de données est incomplète.

Comment l'éviter : Intégrez les sauvegardes de PV dans votre stratégie dès le départ. Utilisez des snapshots cloud, Velero ou des outils spécifiques à la base de données, et incluez les étapes de restauration de PV dans votre runbook.

Récupération : Si vous n'avez pas de sauvegardes de PV, vous devrez peut-être compter sur la réplication au niveau applicatif ou des exportations récentes. Si les données sont corrompues, vous devrez peut-être restaurer à partir d'un snapshot plus ancien et rejouer les journaux.

### 3. Se fier uniquement à helm get values sans les valeurs par défaut

Pourquoi cela arrive : helm get values ne renvoie que les valeurs fournies par l'utilisateur, pas les valeurs par défaut du chart. Si vous restaurez en utilisant uniquement ces valeurs, vous risquez de perdre des personnalisations provenant des valeurs par défaut, du values.yaml du chart ou des mises à niveau précédentes.

Comment l'éviter : Utilisez helm get values --all pour capturer les valeurs effectives, ou mieux, utilisez le fichier de valeurs d'origine stocké dans votre dépôt Git.

Récupération : Si vous n'avez que les valeurs fournies par l'utilisateur, vous pouvez toujours restaurer en remplaçant les valeurs par défaut si nécessaire. Consultez le values.yaml par défaut du chart pour identifier les paramètres critiques à définir.

### 4. Ne pas tester régulièrement les restaurations

Pourquoi cela arrive : Les sauvegardes peuvent être créées mais jamais testées. Une sauvegarde qui ne peut pas être restaurée est inutile.

Comment l'éviter : Planifiez des tests de restauration réguliers dans un espace de noms ou un cluster de préproduction. Automatisez le test pour qu'il s'exécute après chaque cycle de sauvegarde.

Récupération : Si un test échoue, diagnostiquez immédiatement : vérifiez les fichiers manquants, la syntaxe incorrecte ou les incohérences de version. Corrigez le processus de sauvegarde et retestez avant de considérer le système comme fiable.

## Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour garantir des opérations de sauvegarde et de restauration cohérentes. Pour chaque élément, un propriétaire unique est identifié et la fréquence de révision est spécifiée.

<div class="my-stack-md overflow-x-auto">
<table class="min-w-[42rem] border-collapse text-left">
<thead><tr><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Étape</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Action</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Vérification</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Propriétaire</th><th scope="col" class="border border-outline-variant bg-surface-container-low px-4 py-3 text-left font-label-md font-semibold text-on-surface">Fréquence de révision</th></tr></thead>
<tbody><tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">1. Inventorier les versions</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><code class="font-mono text-[0.9em] bg-surface-container px-1 py-0.5 rounded">helm list --all-namespaces</code></td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Toutes les versions listées</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur plateforme (ex. Alex Johnson)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Hebdomadaire</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">2. Sauvegarder les secrets de version</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><code class="font-mono text-[0.9em] bg-surface-container px-1 py-0.5 rounded">kubectl get secrets -l owner=helm -o yaml &gt; backup.yaml</code></td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Fichier créé et non vide</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur DevOps (ex. Maria Garcia)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Quotidienne</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">3. Exporter les valeurs</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><code class="font-mono text-[0.9em] bg-surface-container px-1 py-0.5 rounded">helm get values &lt;release&gt; -n &lt;ns&gt; -o yaml &gt; values.yaml</code></td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Les valeurs correspondent aux attentes</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Propriétaire d&#39;application (ex. Priya Shah)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Hebdomadaire</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">4. Sauvegarder les CRD</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant"><code class="font-mono text-[0.9em] bg-surface-container px-1 py-0.5 rounded">kubectl get crds -o yaml &gt; crds.yaml</code></td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Le fichier inclut toutes les CRD</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur plateforme</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Hebdomadaire</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">5. Sauvegarder les données PV</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Créer des snapshots</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Les snapshots sont à l&#39;état disponible</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Administrateur de stockage (ex. Chen Wei)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Quotidienne</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">6. Stocker les sauvegardes hors cluster</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Copier les fichiers vers un stockage distant</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Les fichiers sont accessibles de l&#39;extérieur</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur DevOps</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Hebdomadaire</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">7. Tester la restauration dans un environnement de test</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Installer la version à partir de la sauvegarde dans un espace de noms de test</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">La version est déployée avec succès</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Responsable QA (ex. Sam Taylor)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Mensuelle</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">8. Planifier des sauvegardes régulières</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Configurer une tâche cron</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">La tâche cron s&#39;exécute et journalise le succès</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur DevOps</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Quotidienne</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">9. Examiner les journaux de sauvegarde</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Vérifier la sortie de la tâche de sauvegarde</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Aucune erreur signalée</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Ingénieur DevOps</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Quotidienne</td></tr>
<tr><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">10. Effectuer un exercice de reprise après sinistre</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Simuler une défaillance et restaurer</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">La restauration respecte les RTO/RPO</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Commandant d&#39;incident (ex. Jordan Lee)</td><td class="border border-outline-variant px-4 py-3 align-top text-body-md text-on-surface-variant">Trimestrielle</td></tr></tbody>
</table>
</div>

## Conclusion

La sauvegarde et la restauration des versions Helm sont une tâche opérationnelle critique qui, lorsqu'elle est effectuée correctement, protège vos applications Kubernetes contre la perte de données et les temps d'arrêt. En suivant les étapes de ce guide, vous avez établi une base solide : vous avez inventorié votre environnement, mis en œuvre une configuration de sauvegarde sûre et limitée, vérifié l'intégrité de vos sauvegardes et vous êtes préparé aux modes de défaillance avec des procédures de récupération.

Vos prochaines étapes devraient être :

- Automatiser le processus de sauvegarde à l'aide des scripts fournis.

- Configurer un stockage hors cluster pour les fichiers de sauvegarde.

- Effectuer une restauration de test dans un environnement de test pour valider vos sauvegardes.

- Planifier des exercices de reprise après sinistre réguliers.

Avec ces pratiques en place, vous pouvez utiliser Helm en production en toute confiance, sachant que vos versions et leurs configurations sont sûres et récupérables.