Waarom de meeste Kubernetes-backupstrategieën een echte uitwijk niet overleven

De meeste production Kubernetes-clusters in 2026 hebben wel een backupstrategie. Velero draait z'n schedules, etcd-snapshots landen in object storage en CSI-snapshots worden netjes op tijd gemaakt. Of dat allemaal ook werkt als de ramp er daadwerkelijk is, is een andere vraag. En het is een vraag die de meeste teams niet kunnen beantwoorden.

Het patroon herhaalt zich: backups zijn ingericht, retentiepolicies staan goed, dashboards zijn groen. En dan corrupt etcd tijdens een upgrade, of er wordt een namespace verwijderd in de verkeerde kube-context, of ransomware raakt een stateful workload. En vervolgens levert het herstellen partial failures op, PVC's met gemangelde namen, finalizers die niet loslaten, of een werkend cluster zonder de data die ertoe deed.

Dit is geen tool-review. De tools zijn over het algemeen prima. Het gat zit in operationele discipline: de meeste teams kunnen je niet vertellen wanneer ze voor het laatst succesvol een restore hebben gedaan, welke faalklassen hun huidige setup eigenlijk dekt, of hoe het herstel zich houdt als GitOps er bovenop staat te reconcilen. Dat gat maakt het verschil tussen een routine-outage en een meerdaags incident.

TL;DR

• Backups waarvan nooit gerestored wordt zijn theater. Het Veeam 2026 Data Trust and Resilience Report liet zien dat slechts 28% van de ransomware-slachtoffers hun data volledig terugkreeg, terwijl 90% daarvan overtuigd was dat het wel zou lukken.
• Velero heeft in 2026 bekende restore-faalmodi rondom StatefulSets, CRD's met finalizers, operator-managed workloads en GitOps-reconciliation. De meeste zijn gedocumenteerd; geen ervan is een verrassing.
• etcd encryption-at-rest key-rotatie maakt oudere snapshots onherstelbaar. Teams ontdekken dat tijdens de restore, niet ervoor.
• CSI-volume-snapshots zijn crash-consistent, regio-lokaal en verbonden aan de lifecycle van het volume. Een handige primitive, geen backup.
• De juiste vraag is niet "hebben we backups", maar "wanneer hebben we voor het laatst succesvol gerestored en bewezen dat de workload consistent terugkwam".

Inhoudsopgave

• De drie soorten rampen waar je Kubernetes-backup tegen bestand moet zijn
• Velero in 2026: wat werkt er wel
• Waar het herstellen met Velero stukloopt
• De etcd-snapshot-lifecycle die de meeste teams verkeerd doen
• CSI-snapshots zijn geen backups
• De ramp met de verkeerde context
• Het oefenritme dat problemen daadwerkelijk vangt
• Wanneer een standby-cluster goedkoper is dan perfecte backups
• Belangrijkste punten

De drie soorten rampen waar je Kubernetes-backup tegen bestand moet zijn

Backupplanning klapt in elkaar als je "ramp" als één ding behandelt. In de praktijk hebben Kubernetes-clusters te maken met drie heel verschillende faalklassen, en voor elk daarvan zijn andere tools en patronen relevant.

Cluster-brede corruptie. etcd corrupteert tijdens een upgrade. Een control-plane-node faalt op een manier waarbij de clusterstate meegaat. Een cloud-provider heeft een regionale storing. De recovery-primitive is een etcd-snapshot of een parallel cluster.

Namespace- of workload-specifiek dataverlies. Een PVC wordt verwijderd, een database wordt leeggetrokken door een mislukte migratie, een applicatie corrupteert z'n eigen data. Het herstel is op object- en volumeniveau: Velero zet de namespace terug, de PVC's binden opnieuw, de applicatie start weer.

Per ongeluk een destructieve actie. Iemand draait kubectl delete -f in de verkeerde context. Een pipeline past een manifest toe dat resources verwijdert die het niet had moeten verwijderen. Een helm uninstall rolt verder terug dan verwacht. De ramp ziet er identiek uit als dataverlies, maar de oorzaak is menselijk en het responsvenster is minuten, geen uren.

Elke klasse heeft een ander herstelmodel nodig. Teams die één tool kopen en aannemen dat die alle drie dekt, worden verrast door de ramp waar de tool nooit voor bedoeld was.

Velero in 2026: wat werkt er wel

Velero is de dominante open-source Kubernetes-backuptool en de basis onder meerdere commerciële offerings, en de governance-positie veranderde in maart 2026: Broadcom heeft Velero gedoneerd aan de CNCF als Sandbox-project, waarmee het voor het eerst sinds de Heptio-tijd formeel vendor-neutraal is. De huidige stable is v1.18.0 (2 maart 2026), met concurrent backup processing, cache-volumes voor de data mover en het definitieve einde van het al lang afgeschafte restic-pad (volledig verwijderd in v1.19).

Voor rechttoe rechtaan scenario's doet Velero wat erop staat. Een stateless namespace backuppen, alle Kubernetes-objecten met hun ConfigMaps en Secrets meenemen, gekoppelde PVC's snapshotten via de CSI-driver en het geheel in object storage zetten werkt zoals geadverteerd. Een verwijderde namespace terugzetten in hetzelfde cluster, of een non-stateful workload migreren naar een ander cluster met de AWS- of Azure-plugin, zijn paden die goed uitgesleten zijn.

Het gedoe begint zodra de workload de eigenschappen heeft die production-workloads gewoon hebben: persistente state die door een operator wordt beheerd, StatefulSet-volgordevereisten, CRD's met finalizers, of GitOps-reconciliation. Bijna elke interessante workload heeft er minstens één.

Waar het herstellen met Velero stukloopt

De GitHub-tracker van Velero is verplichte kost als je een DR-strategie aan het plannen bent. Een aantal terugkerende patronen:

PVC-naamcorruptie bij restore. Issue #9401 (november 2025): na de restore worden PVC's aangemaakt met automatisch gegenereerde namen zoals velero-viya-restore-fs-j6vcn-pvc-dc8f85ba-… in plaats van hun oorspronkelijke namen. Workloads die PVC's by name binden (Deployments met een verwijzing naar een named PVC, Helm-managed releases, alles met een stabiele claim) breken bij restore. De data is er wel. De binding niet.

DataMover die blijft hangen op plugin-operaties. Issue #6813: restores ronden maar een deel van de operaties af voor StatefulSet-workloads en blijven oneindig in WaitingForPluginOperations hangen. Het dashboard rapporteert progress; de workload komt nooit op.

CRD's met finalizers die blijven hangen. Issue #7207: een korte connection-blip tijdens de restore laat de Restore CR voor altijd "In Progress" staan, omdat Velero de update niet retried. De restore is niet gefaald. Hij is gewoon nooit klaar.

Operator-managed databases. CloudNativePG met Velero ondersteunt alleen snapshot-recovery, point-in-time recovery is er niet bij. Als je WordPress op Kubernetes draait of een andere database-gebaseerde applicatie via een operator, dan is wat de operator als backup ziet, niet wat Velero als backup ziet. Na een Velero-restore reconcilet de operator zijn state en kan hij de net teruggezette objecten overschrijven, omdat zijn control loop niet weet dat er een restore is gebeurd.

GitOps-drift na restore. Dit is de faalmodus die teams meestal op de harde manier ontdekken. Velero is klaar met de namespace restoren. Flux of Argo CD draait nog. De GitOps-controller ziet dat de clusterstate afwijkt van Git en reconcilet, waardoor de Velero-restore binnen seconden wordt overschreven. De officiële guidance is om reconciliation expliciet op te schorten: flux suspend kustomization vóór de restore, of argocd.argoproj.io/skip-reconcile: "true" zetten op de betreffende Applications. Teams die die stap vergeten, kijken toe hoe de teruggezette state in real time verdampt.

Geen van deze dingen is strikt genomen een bug. Het zijn voorspelbare interacties tussen Velero en de workload-patronen die de meeste teams draaien. Ze komen in drills naar boven. Ze komen niet op het backup-dashboard naar boven.

De etcd-snapshot-lifecycle die de meeste teams verkeerd doen

etcd-snapshots zijn een control-plane-recovery-primitive. De mechaniek is eenvoudig: etcdctl snapshot save schrijft de state weg, je verstuurt het naar object storage en je kunt het terugzetten tegen een verse etcd-member. De Kubernetes-docs beschrijven de procedure duidelijk.

De lifecycle die de meeste teams verkeerd doen, is encryption-at-rest key-rotatie. Als je cluster secrets at rest versleutelt met een KMS-provider, zijn de secrets in de etcd-snapshot versleuteld met de key die op het snapshot-moment primair was. Rotate je de KMS-key, en probeer je daarna die snapshot terug te zetten tegen een cluster met de nieuwe key-configuratie, dan kan de API-server de secrets niet meer ontsleutelen. Uit de Rancher RKE-documentatie:

The snapshot is taken before the keys are rotated and restore is attempted after. In this case, the old keys used for encryption at the time of the snapshot no longer exist in the cluster state file.

Kubernetes 1.29 heeft KMS v2 generally available gemaakt, wat de encryption-pipeline verbetert maar niets verandert aan de onderliggende waarheid: rotate je de KEK en verlies je het oude key-materiaal, dan worden snapshots van vóór de rotatie deels onleesbaar. Het cluster boot, maar de secrets zijn niet te lezen en de workloads die ervan afhankelijk zijn falen op subtiele manieren. De Kubernetes-docs zijn er expliciet over: als een resource niet meer te decrypten is omdat keys zijn veranderd, "your only recourse is to delete that entry from the underlying etcd directly."

De oplossing is niet ingewikkeld. Maak een verse snapshot direct na elke wijziging aan de encryption-configuratie, gooi nooit oude key-materiaal weg voordat alle secrets opnieuw zijn versleuteld, en documenteer welke key-generatie bij welke snapshot hoort. Teams die die documentatiestap overslaan, zijn de teams die het probleem tijdens de restore ontdekken.

CSI-snapshots zijn geen backups

VolumeSnapshot is GA sinds Kubernetes 1.20 en is de standaard primitive voor volume-recovery. Het wordt ook gewoon vaak als backup behandeld, en dat is het niet.

Vier eigenschappen maken CSI-snapshots ongeschikt als zelfstandige backupstrategie.

Crash-consistent, niet application-consistent. Een snapshot die wordt gemaakt terwijl de database draait, vangt op wat naar disk is geschreven plus wat er in de kernel-page-cache zit. De engine recovert bij restart, soms succesvol. Voor Postgres, MySQL of een andere database met write-ahead logging is een snapshot zonder pg_start_backup() of equivalent quiescing een gokje.

Hetzelfde failure-domein als de source. AWS EBS-snapshots worden opgeslagen binnen dezelfde Availability Zone als het bronvolume, tenzij je ze expliciet cross-region kopieert. Hetzelfde geldt voor GCP Persistent Disk-snapshots en Azure Disk-snapshots. Een regionale storing pakt je bronvolume en je snapshots tegelijk mee. Portworx is er in hun eigen documentatie recht voor zijn raap over: "Since snapshot data is stored in the same place as the original data, snapshots are no substitute for a backup."

Verbonden aan de lifecycle van het volume. In sommige configuraties verwijdert het wegnemen van het bronvolume ook de snapshots. Een verkeerd ingestelde retentiepolicy of een ongelukkige delete kan beide kopieën in één keer slopen.

Geen Kubernetes-objectstate. Een CSI-snapshot vangt volume-bytes. Hij vangt geen Deployments, Services, ConfigMaps, Secrets, RBAC, Ingress-config of wat dan ook dat een PV omzet in een draaiende workload. "De data" terugzetten zonder de omliggende objecten levert je een leeg cluster op met een gevulde disk.

Snapshots zijn een snelle, goedkope primitive. Behandel ze als de eerste stap van een backup, niet als het hele ding.

De ramp met de verkeerde context

De meest voorkomende ramp die ik tegenkom in DevOps-incidentretrospectives is geen infrastructuurfalen. Het is kubectl delete -f of helm uninstall uitgevoerd tegen een context waarvan de operator dacht dat het een sandbox was. Het hele ecosysteem aan context-isolatie-tools (kubie, kubert, de diverse kubectx-hardening-forks) bestaat omdat traditionele kubectx de context-wissel globaal maakt. Run kubectx prod in één terminal, schakel een uur later naar een ander venster, tik kubectl delete -f manifest.yaml en je hebt zojuist een productie-outage geproduceerd vanuit een workflow die de operator als veilig beschouwde.

De tool-fix is eenvoudig: kubie en consorten spawnen een subshell per context, zodat de wissel beperkt blijft tot die shell. De procedurele fix is belangrijker. Prompt-indicators die de huidige context laten zien, verplichte bevestiging voor destructieve acties tegen production-contexts, en policy-as-code-admissionregels die cluster-wide deletes vanaf non-platform service-accounts blokkeren, verkleinen allemaal de blast radius.

Als de verkeerde-context-ramp er toch is, ziet het herstel er meestal uit als een Velero-restore op de betreffende namespace plus een nieuwe GitOps-reconciliation. En dat is precies het pad waarvan de vorige sectie liet zien dat het op interessante manieren stukloopt. Daarom telt deze anti-pattern disproportioneel zwaar mee in DR-planning: de ramp die je het meest waarschijnlijk zelf veroorzaakt, is de ramp waar je tooling het minst goed schoon van herstelt.

Het oefenritme dat problemen daadwerkelijk vangt

De industriedata over daadwerkelijk geteste backups is niet bepaald vleiend. Het Veeam 2026-rapport liet zien dat 90% van de organisaties ervan overtuigd is dat ze van een cyberincident kunnen herstellen, terwijl slechts 28% van de ransomware-slachtoffers daadwerkelijk volledig herstelde. Het Unitrends 2025 State of Backup and Recovery Report brengt hetzelfde gat in restoretermen: 60% van de respondenten dacht binnen een dag te kunnen herstellen, maar slechts 35% kon dat ook echt.

Het ritme dat het soort problemen hierboven vangt is gelaagd, en geen van de lagen is optioneel.

Wekelijkse geautomatiseerde canary-restore. Kies een representatieve workload (een stateful database, een stateless API, een operator-managed applicatie). Restore die volgens schema in een parallelle namespace en draai een validatiescript dat data-integriteit en bereikbaarheid checkt. Dit vangt Velero-versie-regressies, plugin-issues en stille backup-corruptie op voordat het samenvalt met andere problemen.

Maandelijkse namespace-drill. Pak één namespace willekeurig. Restore die tegen een parallel cluster. Klok de restore. Meet hoe lang het kostte om problemen te identificeren en op te lossen. Dit vangt de operator- en GitOps-interacties op die een geautomatiseerde single-workload-restore mist.

Kwartaal-cluster-drill. etcd-snapshot terugzetten op een parallel cluster, inclusief een bewuste reset van de encryption-configuratie. Dit is de enige drill die het KMS-rotatieprobleem vangt voordat het in productie toeslaat.

Teams die alle drie doen, vinden meestal minstens één gebroken aanname per kwartaal. Teams die geen van drieën doen, vinden hun gebroken aannames tijdens het echte incident, wanneer de kosten zich vertalen in klantgerichte downtime in plaats van een middagje debuggen.

Wanneer een standby-cluster goedkoper is dan perfecte backups

Voor sommige workloads is operationeel het goedkoopste antwoord om de geavanceerde backup-and-restore-tooling over te slaan en in plaats daarvan een warme of active-active standby te draaien. De AWS Well-Architected Reliability Pillar legt de trade-offs helder neer:

De kostenframing klopt op zichzelf niet. Een warm standby vraagt dat je doorlopend voor compute en storage betaalt. Een geavanceerde backup-en-restore-strategie vraagt dat je betaalt voor het engineeringwerk om hem werkend te krijgen, de drills om aan te tonen dat hij werkt, en de hersteltijd als een incident toeslaat. Voor mission-critical stateful workloads is die tweede kolom vaak groter dan de eerste, zeker zodra de drills de faalpunten boven water halen.

Multi-cluster-tooling in 2026 maakt het standby-model toegankelijker dan het was. Karmada (CNCF) ondersteunt active-active en remote DR-policies native, en AWS publiceert guidance voor Karmada met EKS waarin automatische failover tussen clusters wordt afgedekt. Voor multi-tenant clusters waar het per-tenant-restoremodel van Velero ongemakkelijk is, kan het standby-patroon operationeel eenvoudiger uitpakken.

De keuze is zelden "het één of het ander". Een verstandige productie-setup gebruikt Velero voor namespace- en workload-specifiek herstel, etcd-snapshots voor control-plane-corruptie, en een warme of active-active standby voor de workloads waarbij minuten downtime niet acceptabel zijn. De eerlijke move is om precies te zijn over welke workload in welke categorie hoort, in plaats van te beweren dat één tool alles afdekt.

Belangrijkste punten

• Schedule-groen is geen restore-groen. Een backup waarvan in het laatste kwartaal niet is gerestored, is een hypothese, geen herstelplan.
• Velero v1.18 doet wat het doet prima, maar PVC-naamcorruptie (#9401), CRD-finalizer-hangs (#7207) en het operator-restoreconflict zijn voorspelbare faalmodi. Schort GitOps-reconciliation altijd op vóór een restore.
• etcd-snapshots worden onherstelbaar als je encryption-at-rest-keys roteert zonder eerst alle secrets opnieuw te versleutelen. Maak na elke encryption-wijziging direct een nieuwe snapshot.
• CSI-snapshots zijn crash-consistent, regio-lokaal en lifecycle-gebonden. Een primitive, geen backup.
• Het ritme dat problemen vangt is wekelijks canary, maandelijks namespace, kwartaal full cluster. Teams die het ritme overslaan, vinden hun problemen tijdens het incident.
• Voor workloads waarbij minuten downtime onacceptabel zijn, is een warme of active-active standby vaak operationeel goedkoper dan een perfect-restore-verhaal.