Un snapshot de disque sauvegarde le contenu d’un volume. Il ne sauvegarde ni la définition de vos Deployment, ni vos Secret, ni vos ConfigMap, ni la structure complète de ce qui tourne sur le cluster. Perdre un cluster entier (erreur de configuration catastrophique, panne matérielle sur l’infrastructure qui l’héberge) sans sauvegarde de son état laisse un tas de volumes de données intacts et aucun moyen simple de reconstruire ce qui les utilisait.

Ce que Velero sauvegarde réellement

Velero capture deux choses distinctes en une seule opération : les définitions de ressources Kubernetes (au format YAML, exportées depuis l’API server) et, en option, un instantané des volumes associés via l’intégration native du fournisseur de stockage.

# Sauvegarde complète d'un namespace : ressources + volumes associés
velero backup create prod-backup \
  --include-namespaces production \
  --snapshot-volumes

Cette double capture répond à une question que la réplication de données seule ne pose jamais : si le cluster entier disparaît, comment recréer non seulement les données, mais la structure exacte (labels, annotations, relations entre objets) qui les fait fonctionner ensemble ?

Program de sauvegarde, pas sauvegarde ponctuelle

Une sauvegarde manuelle lancée une fois ne protège que l’instant où elle a été prise. Velero se programme via un Schedule, l’équivalent d’un CronJob pour les sauvegardes :

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces: ["production"]
    ttl: "720h0m0s"

Le ttl (durée de rétention) mérite une attention particulière : une rétention trop courte élimine la sauvegarde dont vous auriez eu besoin avant que le problème ne soit détecté ; une rétention trop longue accumule un coût de stockage silencieux qui grossit indéfiniment sans jamais être révisé.

La restauration testée, ou une sauvegarde qui ne protège rien

Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une garantie. Le format d’export peut être corrompu, une ressource critique peut être exclue par erreur d’un filtre trop large, un CustomResourceDefinition requis peut manquer côté cluster de destination. Restaurer périodiquement une sauvegarde vers un cluster de test, même minimal, est la seule façon de savoir si la sauvegarde protège réellement ce qu’elle est censée protéger :

# Restauration vers un cluster différent : le vrai test d'une sauvegarde
velero restore create --from-backup prod-backup

Une organisation qui découvre qu’une sauvegarde ne se restaure pas correctement le fait presque toujours au pire moment possible : pendant l’incident qu’elle était censée couvrir.

Ce que Velero ne remplace pas

Velero sauvegarde l’état déclaré du cluster à un instant donné ; il ne remplace pas une source de vérité GitOps qui décrit cet état de façon continue et versionnée. Un cluster piloté en GitOps dispose déjà, dans son dépôt Git, d’une grande partie de ce que Velero exporterait pour les ressources elles-mêmes : la valeur ajoutée de Velero se concentre alors sur ce que Git ne capture jamais, les données elles-mêmes et l’état runtime (Secrets générés dynamiquement, par exemple).

À retenir

Un cluster Kubernetes complet a deux couches distinctes à protéger : les données qu’il stocke (couvertes par la réplication et les sauvegardes de Longhorn) et sa structure déclarée (ressources, Secrets, relations entre objets), que Velero couvre spécifiquement. Une sauvegarde programmée mais jamais restaurée pour test reste une hypothèse non vérifiée. Ce filet de sécurité complet fait partie du socle posé dès une migration Kubernetes qui prend la disponibilité au sérieux.