Velero — sauvegarde du namespace

Velero sauvegarde le namespace openbao en entier : les objets Kubernetes et le contenu des volumes persistants, donc l'état Raft du coffre.

Pour savoir quand l'utiliser plutôt que Medusa, voir la vue d'ensemble.

Le contenu sauvegardé reste chiffré par le sceau

Velero copie les volumes tels quels. Sans les parts de descellement, les données restaurées ne sont pas exploitables.

C'est précisément le trou que Medusa comble.

Ce qui tourne

Six planifications couvrent le namespace, toutes en heure de Paris :

Planification	Fréquence	Rétention	Destination
velero-backup-daily-openbao	tous les jours à 00 h 30	15 jours	prod-daily
velero-backup-weekly-openbao	dimanche à 00 h 30	84 jours	prod-weekly
velero-backup-monthly-openbao	le 1er du mois	1 an	prod-monthly
velero-backup-monthly-openbao-nl-ams	le 1er du mois	1 an	prod-monthly-nl
velero-backup-yearly-openbao	le 2 septembre	10 ans	prod-yearly
velero-backup-yearly-openbao-nl-ams	le 2 septembre	10 ans	prod-yearly-nl

Les deux planifications nl-ams écrivent dans une seconde région, Amsterdam, pour survivre à la perte de fr-par.

Velero a son propre planificateur

Il n'y a aucun CronJob Kubernetes derrière ces planifications. Chercher un CronJob pour comprendre ou déclencher une sauvegarde est une piste sans issue.

Vérifier que ça tourne

kubectl -n velero get schedules | grep openbao

La colonne LASTBACKUP doit afficher une durée cohérente avec la fréquence : moins de 24 h pour la quotidienne. PAUSED doit être vide.

Les sauvegardes récentes, la plus récente en dernier :

kubectl -n velero get backups | grep openbao

Vérifier qu'une sauvegarde est complète

Le nom d'une sauvegarde suit le motif <planification>-<horodatage UTC> :

BACKUP=NOM_DU_BACKUP

kubectl -n velero get backup $BACKUP -o jsonpath='{"phase   : "}{.status.phase}{"\n"}{"items   : "}{.status.progress.itemsBackedUp}{"/"}{.status.progress.totalItems}{"\n"}{"erreurs : "}{.status.errors}{"\n"}'

Attendu : Completed, un compte d'items identique de part et d'autre du /, et aucune erreur.

Les volumes sont sauvegardés séparément des objets Kubernetes, et c'est là que les échecs passent le plus facilement inaperçus :

kubectl -n velero get podvolumebackups -l velero.io/backup-name=$BACKUP \
  -o custom-columns=POD:.spec.pod.name,VOLUME:.spec.volume,PHASE:.status.phase

Attendu : 8 lignes en Completed, les volumes data et home de chacun des 4 pods openbao-0 à openbao-3.

Une sauvegarde Completed avec des volumes en échec est un faux vert

La phase globale peut afficher Completed alors qu'un PodVolumeBackup a échoué. Dans ce cas l'état Raft d'un nœud manque, et la sauvegarde n'est pas restaurable.

Contrôlez toujours les 8 volumes, pas seulement la phase.

Ne jamais supprimer une sauvegarde en cours

Ne pas kubectl delete un objet Backup en phase InProgress

Cela bloque la file de travail du contrôleur : plus aucune sauvegarde ne démarre, les nouvelles restent en Queued, et les planifications de la nuit ne partent pas non plus.

Symptôme : aucune ligne controller=backup dans les logs alors qu'une sauvegarde attend.

Remède : kubectl -n velero rollout restart deploy/velero. Le serveur est sans état, c'est sûr tant qu'aucune sauvegarde ne tourne.

Restauration

Procédure non éprouvée

Aucune restauration Velero du namespace openbao n'a été testée à ce jour. Les commandes existent (velero restore create --from-backup) mais leur comportement sur un StatefulSet avec des PVC zonaux et un coffre scellé n'a pas été vérifié.

En cas de besoin réel, privilégiez Medusa, dont la restauration est éprouvée, et traitez Velero comme un filet dont il faut d'abord valider le fonctionnement.

Points à éclaircir avant de pouvoir écrire cette procédure :

• comportement sur les PVC zonaux, que le StatefulSet ne peut pas replacer dans une autre zone
• ordre entre la restauration des volumes et le descellement des pods
• interaction avec les pods vault-unseal, qui tentent de desceller pendant la restauration