El incidente describe un problema fundamental de consistencia en los backups de cargas de trabajo stateful en Kubernetes que utilizan múltiples PersistentVolumeClaims (PVCs) para almacenar su estado (ej., datos y WAL de PostgreSQL). Antes de Kubernetes v1.36 y la introducción de VolumeGroupSnapshot, el Container Storage Interface (CSI) solo permitía snapshots a nivel de PVC individual. Esto significaba que las herramientas de backup tomaban snapshots de cada PVC secuencialmente.
La causa raíz de la inconsistencia residía en la ventana de tiempo entre la toma de snapshots de PVCs individuales. Durante este breve período, la aplicación continuaba escribiendo, lo que podía resultar en que un volumen (ej., el WAL) registrara transacciones que hacían referencia a datos no capturados en otro volumen (ej., los archivos de datos), ya que este último había sido 'congelado' unos milisegundos antes. Aunque cada snapshot individual era crash-consistent, el conjunto de snapshots colectivamente describía un estado que nunca existió, llevando a fallos en la restauración que solo se manifestaban en el momento crítico de recuperación.
Las salvaguardas existentes fallaron porque el problema no era una corrupción de datos en tránsito o un fallo de la herramienta de backup, sino una inconsistencia inherente al modelo de snapshotting. Los mensajes de éxito de los snapshots individuales eran engañosos, ya que no reflejaban la coherencia del conjunto. La única alternativa era quiescer la aplicación, lo cual es disruptivo y a menudo inviable a escala de producción. La falta de una primitiva de 'consistency group' a nivel de API de Kubernetes fue la brecha arquitectónica que permitió que este modo de fallo silencioso persistiera durante años.