Sauvegardes des volumes persistants Kubernetes : outils, CronJobs et modèles de RESTauration

Dans cet article, j’expose de manière pragmatique comment planifier et exploiter de manière fiable les Kubernetes-Persistent-Volume-Backups. Le mot-clé principal Kubernetes-Persistent-Volume-Backups est placé dès le début, car les sauvegardes de stockage dans les conteneurs ont des prérequis, des risques et des schémas de RESTauration différents des sauvegardes classiques de systèmes de fichiers. Le public visé comprend les Administratoren, System Engineers et Betreiber : ils doivent, à la fin, pouvoir décider quels outils et quels processus correspondent à leurs SLAs et comment ils opérationnalisent la routine, les tests et les stratégies de repli.

Pourquoi les sauvegardes de PersistentVolume dans Kubernetes sont différentes

PersistentVolume (PV) est dans Kubernetes l’objet de stockage abstrait ; un PersistentVolumeClaim (PVC) est la demande d’une application à un PV. StorageClass décrit la provision (par ex. basé sur le bloc ou NFS). Dans les systèmes classiques, vous sauvegardez directement des systèmes de fichiers ou des périphériques bloc. Dans Kubernetes, des complexités supplémentaires apparaissent :

• Cycles de vie volatils : les Pods/StatefulSets peuvent être réaffectés dynamiquement.
• Plusieurs chemins d’accès : les partages NFS/SMB et le stockage en mode bloc se comportent différemment lors des snapshots.
• Cohérence applicative : les bases de données nécessitent une mise en repos (quiesce) ou des snapshots coordonnés.

Ces différences impliquent : l’outil de sauvegarde, le mécanisme de snapshot et le schéma de RESTauration doivent être alignés.

Kubernetes-Persistent-Volume-Backups: aperçu des outils

Il existe trois approches répandues, qui peuvent se compléter ou se substituer :

• CSI-Snapshots : snapshots point-in-time pris en charge par le fournisseur de stockage via le Container Storage Interface (CSI). Adaptés pour des copies rapides et cohérentes au niveau bloc ; ils ne remplacent pas une sauvegarde externe si une protection supplémentaire contre la défaillance du stockage est requise.
• Opérateurs de sauvegarde comme Velero ou Kasten : orchestrent les snapshots, sauvegardent les métadonnées et peuvent copier les volumes vers des dépôts externes (stockage d’objets). Velero est Open Source et largement répandu ; Kasten est commercial et offre davantage d’intégrations.
• Sauvegardes au niveau fichier/image avec RESTic/Borg/rsync : monter le volume dans un Job/Pod et copier les fichiers vers un dépôt. Utile pour les NAS/partages de fichiers et lorsque les CSI-snapshots natifs ne sont pas disponibles.

Les critères de choix sont le RTO (Recovery Time Objective), le RPO (Recovery Point Objective), le type de stockage (NAS vs bloc), les exigences de chiffrement et la conformité. Les CSI-snapshots offrent des RTO faibles ; les dépôts externes augmentent la résilience face à une défaillance du stockage.

CSI-Snapshots vs. sauvegardes réelles

Un CSI-snapshot est une opération sur les métadonnées implémentée en interne par le backend de stockage. C’est rapide et souvent cohérent pour des volumes individuels. Pourquoi cela ne suffit pas toujours :

• Les snapshots résident sur le même backend : une défaillance matérielle ou une erreur de cluster peut endommager à la fois les données sources et les snapshots.
• Les snapshots ne sont généralement pas versionnés comme les sauvegardes en stockage d’objets ; les politiques de rétention peuvent être plus complexes.
• Pour la cohérence entre applications (par ex. bases de données distribuées), des mécanismes de quiesce coordonnés sont nécessaires.

C’est pourquoi de nombreuses équipes combinent les CSI-snapshots (pour des RESTaurations rapides) avec des sauvegardes externes régulières (pour le Disaster Recovery).

Backup-CronJobs dans Kubernetes: modèles et bonnes pratiques

Pour des sauvegardes de fichiers simples ou des sauvegardes complémentaires, les exploitants utilisent des CronJobs Kubernetes (objet Kubernetes pour les jobs planifiés). L’idempotence, le verrouillage, la journalisation et des codes de sortie clairs sont essentiels.

Exemple : CronJob qui monte un PVC dans un Pod de sauvegarde et exécute rsync vers un NAS. Ce modèle convient pour NFS-PV ou lorsque les CSI‑Snapshots ne sont pas disponibles.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pvc-rsync-backup
spec:
  schedule: "0 2 * * *" # täglich 02:00
  jobTemplate:
    spec:
      template:
        spec:
          RESTartPolicy: OnFailure
          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: my-app-pvc
          containers:
            - name: backup
              image: alpine:3.18
              command: ["/bin/sh", "-c"]
              args:
                - |
                  set -euo pipefail
                  mountpoint -q /data || (echo "PVC not mounted"; exit 2)
                  rsync -a --delete /data/ /backup-nfs/my-app/$(date +%F)/
              volumeMounts:
                - name: data
                  mountPath: /data
          nodeSelector:
            backup: "true"

Pourquoi ce modèle fonctionne : un job monte le PVC dans un pod autonome, effectue une copie au niveau fichier et écrit sur un partage NAS distinct, situé en dehors du stockage Kubernetes. Cela découple la rétention des sauvegardes du PV‑backend.

Quand cela peut échouer : si des fichiers sont ouverts, si les données sont écrites de manière incohérente (journal WAL de la base de données non vidangé), ou si le pod de sauvegarde s’exécute sur un nœud qui n’a pas les chemins réseau adéquats vers le NAS.

Compléments pratiques pour les CronJobs

• Verrouillage via ConfigMap/Lease pour empêcher l’exécution simultanée de plusieurs jobs.
• Journalisation exposée (p. ex. stdout → collecteur de logs) et stratégie de code de sortie, pour éviter les échecs silencieux.
• Limites de ressources et NodeSelectors pour la stabilité réseau et I/O.

Exemple : verrouillage avec ConfigMap

Un verrou simple peut être réalisé via une ConfigMap ou une Lease. Ce modèle empêche les jobs parallèles :

#!/bin/bash
set -euo pipefail
LOCK_NAME=my-backup-lock
NAMESPACE=backup
# Try to create ConfigMap as lock
kubectl -n "$NAMESPACE" create configmap "$LOCK_NAME" --from-literal=owner=$(hostname) --dry-run=client -o yaml | kubectl apply -f -
# Check owner (simple approach)
OWNER=$(kubectl -n "$NAMESPACE" get configmap "$LOCK_NAME" -o jsonpath='{.data.owner}')
if [ "$OWNER" != "$(hostname)" ]; then
  echo "Another backup is running (owner=$OWNER)"; exit 3
fi
# Run backup here
# On exit (trap) delete lock

Modèles de RESTauration : RESTauration de PVC, clonage et récupération applicative

La RESTauration s’articule sur plusieurs niveaux : RESTauration du volume, ré-attachement du Pod/StatefulSet, et reconstruction de l’application (p. ex. récupération de base de données). Trois modèles courants :

1. RESTauration de volume via le backend de stockage (CSI Snapshot RESTore) : snapshot → nouveau PV → PVC se lie au nouveau PV. Avantage : rapide, au niveau bloc. Inconvénient : mêmes risques liés au stockage.
2. Objet/Repository → RESTauration de fichiers : copier la sauvegarde depuis l’object storage ou le NAS vers un nouveau PVC. Avantage : possibilité de vérification avant montage en production. Inconvénient : durée.
3. RESTauration orientée application : p. ex. RESTauration point-in-time d’une base de données avec WAL‑replay. La RESTauration doit rétablir l’état applicatif (schéma, logs, index).

Exemple : RESTaurer un PVC à partir d’une sauvegarde objet (niveau fichier)

Étapes :

• Créer un nouveau PVC avec la même StorageClass, mais un nom temporaire.
• Démarrer un Pod qui monte le PVC et recopie la sauvegarde dans le volume.
• Effectuer des vérifications d’intégrité (sommes de contrôle, dénombrement des fichiers).
• Repointer l’application en production et remplacer le PVC ou ajuster le déploiement.

# Beispiel: RESTore-Skript im RESTore-Pod
set -euo pipefail
BACKUP_PATH=/backup-nfs/my-app/2026-07-27/
TARGET=/data
rsync -a --delete "$BACKUP_PATH" "$TARGET/"
# einfache Integritätsprüfung
find "$TARGET" -type f -exec sha256sum {} ; > /tmp/RESTore.sha256
# optional: vergleichen mit manifestierter Prüfsumme

Konsistenz für Datenbanken und NAS: Quiesce, Flush und WAL

Bei Datenbanken ist eine reine Dateisicherung oft unzureichend. Sie benötigen:

• Quiesce oder Flush: Anwendung anweisen, Caches zu flushen (z. B. MySQL FLUSH TABLES WITH READ LOCK), damit Dateien konsistent sind.
• WAL/Transaction Logs: Für Point-in-Time-​Recovery (PITR) müssen Transaktionslogs separat archiviert werden.

Bei NAS‑Dateifreigaben (NFS/SMB) sind zusätzliche Probleme möglich: offene Handles, File‑Locks und verteilte UID/GID. Die Backup‑Job muss offen Dateien behandeln und idealerweise abgestimmte Prozesse zum Moment der Sicherung anstoßen.

NAS‑How‑To: Best Practices, Troubleshooting und Checkliste

NAS in Kubernetes wird oft über NFS oder SMB bereitgestellt. Solche Dateifreigaben haben eigene Fallstricke, die im Betrieb regelmäßig Probleme verursachen.

Worauf Sie priorisieren sollten

• UID/GID‑Konsistenz: Nutzer‑IDs und Gruppen müssen zwischen Cluster und NAS übereinstimmen oder über Mapping-Layer geregelt werden; sonst passen Berechtigungen nach RESTore nicht.
• Offene Handles prüfen: Vor Backup sollten Sie offene File‑Handles und Locks erkennen, weil rsync/Copy sonst inkonsistente Daten nutzt.
• Quotas und Monitoring: NAS‑Zielvolumes müssen überwacht werden, sonst läuft Backup‑Storage voll und Jobs schlagen still fehl.

Konkrete Prüfschritte (Troubleshooting)

Beispielbefehle, die im Troubleshooting helfen:

# offene Handles auf einem gemounteten NAS prüfen
lsof +D /data | head
# prüfen, welche Prozesse auf NFS Dateien halten
fuser -m /data
# Platz prüfen auf NAS-Mount
df -h /backup-nfs
# Berechtigungen eines Beispieldatei prüfen
stat -c '%U %G %a' /data/somefile

Interpretation: lsof/fuser zeigen Prozesse mit offenen Handles. Wenn wichtige DB‑Prozesse offene Logs halten, muss vor Backup ein Flush/Quiesce erfolgen oder Snapshot/Provider‑unterstützte Mechanismen genutzt werden.

Rsync: Chunking und Performance

Bei sehr großen Dateimengen hilft das Aufteilen und parallele Übertragen, kombiniert mit deduplizierendem Ziel (z. B. deduplizierende NAS oder Objekt-Storage mit Dedupe). Beispiel für GNU Parallel mit rsync:

# chunked rsync: find list of top-level dirs and sync in parallel
cd /data
find . -maxdepth 1 -mindepth 1 -type d -print0 | 
  xargs -0 -n1 -P4 -I{} rsync -a --delete "{}" /backup-nfs/my-app/$(date +%F)/"{}"

Vorsicht: Paralleles Sync kann I/O-Spitzen erzeugen; passen Sie Anzahl der Parallelprozesse an Node‑I/O‑Limits an.

Checkliste für NAS‑Backups

• Vorab: Storage‑Quotas prüfen, Zielplatz > 2× erwartete Backup‑Größe planen.
• Vor dem Job: Offene Handles (lsof/fuser) und DB‑Flush durchführen.
• Während Job: Logging, Exit‑Codes und Transfer‑Rate messen.
• Nach Job: Prüfsummen, Dateizählung und Aufbewahrungsbereinigung (Purge) prüfen.

Velero & Objekt‑Repository: Kurzer Praxis‑Workflow

Velero (Open Source) orchestriert Cluster‑weit Backups von Ressourcen und Volumes. Für PVs nutzt Velero CSI‑Snapshots (wenn verfügbar) oder Plugin‑basierte Volume‑Backups. Typische Schritte sind:

1. Installieren mit Provider‑Plugin (z. B. S3/MinIO/AWS S3).
2. Configurer les plannings de sauvegarde et l’intégration RESTic/CSI pour les données de volumes.
3. Effectuer des exercices de RESTauration réguliers.

Exemple CLI : sauvegarde d’un namespace incluant les volumes (Velero & RESTic) :

# Velero Backup starten
velero backup create myapp-backup-$(date +%F) --include-namespaces my-app-namespace --snapshot-volumes
# Status prüfen
velero backup get
# RESTore (in Test-namespace)
velero RESTore create --from-backup myapp-backup-2026-07-27 --namespace-mappings my-app-namespace:RESTore-test

Velero fournit la gestion des métadonnées et une orchestration de RESTauration simple ; l’intégration de RESTic est pertinente si vous souhaitez stocker les données au niveau fichier dans un stockage d’objets.

Sauvegardes de PersistentVolumes Kubernetes : monitoring, métriques et alertes

Opérationnaliser signifie mesurer des indicateurs. Métriques importantes :

• Taux de réussite des sauvegardes (proportion de jobs réussis).
• Durée des sauvegardes (durée par job).
• Durée des RESTaurations et taux de réussite des RESTaurations.
• Espace libre du dépôt et taux de croissance.

Prometheus convient à la collecte ; exemple d’AlertRule pour les sauvegardes échouées :

groups:
- name: backup.rules
  rules:
  - alert: BackupFailures
    expr: increase(kube_job_status_failed{job="pvc-rsync-backup"}[24h]) > 0
    for: 1h
    labels:
      severity: page
    annotations:
      summary: "Backup-Job fehlgeschlagen"
      description: "Mindestens ein Backup-Job ist innerhalb der letzten 24h fehlgeschlagen."

Important : les alertes doivent être liées à des runbooks qui vérifient s’il s’agit de problèmes de configuration/de stockage ou d’une panne réseau transitoire.

Validation de RESTauration : contrôles automatisés et plan de test

La validation est obligatoire. Un test de RESTauration doit toujours exécuter automatiquement les étapes suivantes :

1. Effectuer la RESTauration dans un namespace d’isolation.
2. Monter le PVC RESTauré et exécuter des vérifications d’intégrité des fichiers (sommes de contrôle, comptage de fichiers).
3. Smoke de l’application : endpoint de santé, exécution d’un flux métier minimal.
4. Cohérence de la base : vérification des index, de l’état de réplication, du WAL/de la latence de réplication.
5. Enregistrement des durées : documentation du temps nécessaire (pour le reporting RTO).

Exemple de smoke-check sous forme de script (voir plus haut dans l’article). Automatisez ces tests dans une pipeline CI/CD ou comme partie de la chaîne de jobs de sauvegarde, afin que des contrôles de sanité quotidiens s’exécutent sans intervention manuelle.

Cas pratiques, risques et écueils typiques

Causes fréquentes d’échecs de sauvegardes/RESTaurations :

• Dépôt de sauvegarde ou NAS plein : les jobs échouent silencieusement lorsqu’il n’y a plus d’espace.
• RESTrictions réseau : les jobs de sauvegarde sur des nœuds sans accès au stockage d’objets ou au NAS tournent à vide.
• Incompatibilité des permissions après RESTauration : UID/GID ou ACLs incorrects, les applications ne démarrent pas.
• Codes de sortie ignorés : des CronJobs qui n’exposent pas les erreurs apparaissent comme réussis alors que des opérations de copie ont échoué.

Liste de vérification avant mise en production :

• Cartographie des SLA : définir RTO/RPO.
• Tester le provisioning de stockage (CSI Snapshot & RESTore).
• Vérifier le chemin réseau du nœud de sauvegarde vers le dépôt.
• Mettre en place une vérification automatisée des RESTaurations.

Aspects sécurité et conformité

Le chiffrement, la gestion des clés et la journalisation des accès sont indispensables pour les données sensibles. Les dépôts doivent être chiffrés côté serveur ; il est en outre recommandé de stocker les clés séparément, par exemple dans un HSM ou un Vault (HashiCorp Vault est un outil de gestion des secrets qui gère les clés de manière sécurisée). Les journaux d’audit et les sommes de contrôle aident aux preuves de conformité.

Rollback- und Notfallstrategie

Une RESTauration peut échouer. Prévoyez des rollbacks gradués :

1. Basculement vers un standby (si disponible).
2. RESTauration dans un namespace isolé pour validation.
3. Basculement en production vers le PVC testé uniquement après des tests smoke réussis.

Documentez les étapes de déploiement et les responsabilités, afin d’éviter les pertes de temps liées aux coordinations en cas d’incident.

Empfehlungen und Fazit

En résumé, je recommande le plan pragmatique suivant :

1. Définissez RTO/RPO et vérifiez la fonctionnalité de StorageClass/CSI‑Snapshot.
2. Combinez les CSI‑Snapshots (pour des RESTores rapides) avec des sauvegardes externes de dépôt (pour les scénarios DR et la conformité).
3. N’utilisez les CronJobs que pour des sauvegardes au niveau fichier lorsqu’un CSI n’est pas disponible ; implémentez du locking et une journalisation claire.
4. Mesures spécifiques pour le NAS : vérifier les handles ouverts, assurer la cohérence UID/GID et prévoir un transfert en mode chunked.
5. Automatisez et testez régulièrement les parcours de RESTauration ; intégrez des tests smoke dans les pipelines CI/CD.

Avec cette structure, vous réduisez les risques opérationnels et établissez des processus de RESTauration reproductibles qui rendent le quotidien des administrateurs et des équipes d’exploitation maîtrisable.

Weiterlesen und interne Verlinkungsoptionen

Ce document est conçu comme un guide technique et peut être complété par des articles existants sur la maintenance des sauvegardes, l’architecture réseau pour les fenêtres de sauvegarde et la validation des RESTaurations. Des liens internes vers des checklists et des playbooks de RESTauration peuvent être insérés ici de manière pertinente.

FAQ

Les questions et réponses principales pour une orientation rapide se trouvent dans la section suivante.