La CNCF publicó el 10 de septiembre de 2026 unas directrices basadas en tres escenarios de fallo reproducibles, con el objetivo de probar la recuperación ante desastres de aplicaciones Kubernetes con estado, en lugar de limitarse a comprobar que la copia de seguridad terminó con el estado Completed. Los experimentos, que pueden ejecutarse en un ordenador portátil desde el repositorio del laboratorio, utilizaron una aplicación PostgreSQL con contenido conocido compuesto por cuatro filas, de modo que se pudiera verificar el resultado real de la restauración en lugar de depender de indicadores de estado generales.
El material fue elaborado por Saiyam Pathak y Saloni Narang, ambos embajadores de la CNCF. Su alcance se limita a la restauración del estado de las aplicaciones dentro de Kubernetes; no aborda marcos de cumplimiento, comparaciones de productos ni la restauración de la infraestructura subyacente de la nube o del centro de datos. Herramientas como Velero y las interfaces CSI Snapshot aparecieron como implementaciones de referencia para los escenarios, mientras que los patrones de fallo se aplican a herramientas que desempeñan las mismas funciones.
Una copia de seguridad completada no demuestra que pueda restaurarse
En el primer escenario, los componentes de la copia de seguridad de Kubernetes se separaron en definiciones de recursos en formato YAML y datos de volúmenes persistentes. El laboratorio utilizó Velero con un mecanismo de transferencia de datos a un almacén de objetos compatible con S3 situado fuera de los dos clústeres. La inspección de los objetos DataUpload mostró que 47,989,888 bytes de datos del volumen se transfirieron realmente al almacén externo.
Tras eliminar el espacio de nombres, incluido el PVC, la restauración recuperó las mismas cuatro filas en aproximadamente dos minutos. Sin embargo, la CNCF advierte que proteger los datos del volumen no hace que la copia de la base de datos sea automáticamente coherente desde el punto de vista de la aplicación; las aplicaciones pueden necesitar procedimientos de flush o quiesce. Además, la restauración en una infraestructura diferente puede requerir adaptar StorageClass y realizar otras transformaciones que el equipo debe diseñar y probar.
Lo más importante es que las herramientas de copia de seguridad restauran los recursos en un clúster que ya existe, y no crean los nodos, la red, los balanceadores de carga ni el DNS. Por ello, el plan de recuperación debe especificar claramente el entorno que recibirá la copia, asignando la restauración de Kubernetes a la infraestructura como código o a Cluster API cuando sea necesario.
Git recupera la intención, no el estado almacenado
En el segundo escenario, el clúster de producción se detuvo, mientras que el clúster de recuperación ya existía y contenía un controlador GitOps conectado a un repositorio Git y una herramienta de copia de seguridad conectada al almacén compartido. La sincronización de la aplicación tuvo éxito, el StatefulSet estaba en ejecución y el panel mostraba un estado saludable, pero la consulta a la base de datos devolvió el error: relation "attendees" does not exist.
La causa no era un fallo de Kubernetes ni de GitOps. El repositorio contenía únicamente las definiciones, por lo que el controlador volvió a crear el StatefulSet, el Service y un nuevo volumen de almacenamiento vacío. En la práctica, Git almacena el estado declarado o la intención del equipo, mientras que las copias de seguridad almacenan los datos reales; ninguno de los dos puede restaurar por sí solo la aplicación completa.
El método de recuperación del laboratorio consistió en eliminar la aplicación vacía creada por la sincronización, restaurar después la aplicación junto con sus volúmenes desde el almacén de copias de seguridad y, finalmente, comparar los datos con el contenido esperado. El tiempo transcurrido desde la detención de producción hasta la aparición de datos verificados fue de cuatro minutos en el experimento en vivo y de algo menos de dos minutos en la repetición de la prueba. La CNCF aclara que estas cifras cubren únicamente la parte programada y no incluyen la detección del incidente, la toma de decisiones, el cambio del tráfico ni el regreso al entorno original.
Las instantáneas individuales pueden producir un punto de recuperación que nunca existió
El tercer escenario probó una aplicación que utilizaba dos volúmenes de almacenamiento relacionados: uno para los pedidos y otro para los pagos. El laboratorio escribía pares coincidentes cinco veces por segundo, con la condición de que cada pago correspondiera a un pedido. Al tomar dos instantáneas separadas por cinco segundos, cada instantánea parecía preparada y saludable por separado, pero la restauración reveló que el último pedido registrado era el 108352, frente a 108377 pagos; es decir, había 25 pagos sin pedidos correspondientes.
El resultado demuestra que el éxito de cada operación de almacenamiento individual no garantiza la coherencia de una aplicación que utiliza varios volúmenes; las dos instantáneas juntas pueden describir un momento que nunca existió realmente. El material señala que la diferencia puede ampliarse en producción cuando la herramienta de copia recorre un gran número de PVCs uno tras otro.
VolumeGroupSnapshot, que alcanzó el estado GA en Kubernetes 1.36, proporciona un mecanismo para identificar volúmenes mediante una sola etiqueta y solicitar un punto de recuperación coherente a través de CSI. En la prueba coordinada, el último número de pedidos y pagos coincidió en 109169, y la verificación de la relación entre ambos tuvo éxito. Sin embargo, la compatibilidad depende del controlador; la compatibilidad con VolumeSnapshots normales no demuestra compatibilidad con instantáneas de grupos, y la mayoría de los principales controladores de nube examinados para el laboratorio no las implementaban hasta mediados de 2026. Asimismo, los CRDs, la función de instantáneas y los complementos relacionados deben habilitarse explícitamente.
¿Qué debe medir una prueba de recuperación?
- Restaurar una aplicación completa en un objetivo limpio en el que nunca se haya ejecutado, en lugar de limitarse a eliminar un Pod y observar cómo se vuelve a crear.
- Verificar los datos y la ruta de acceso del usuario utilizando contenido esperado, en lugar de conformarse con el estado de los recursos o los colores de los paneles.
- Medir todo el proceso con un cronómetro, teniendo en cuenta que el tiempo real de recuperación incluye la detección, la decisión, el cambio del tráfico y posiblemente el regreso al entorno original.
- Utilizar dos dominios de fallo independientes, como un clúster de producción y un clúster de recuperación, y mantener el almacén de copias de seguridad fuera de ambos.
Lectura editorial: una brecha entre las herramientas y la secuencia de recuperación
El cambio práctico que destacan estos experimentos es trasladar el criterio de éxito de «la copia de seguridad se completó» a «los datos correctos regresaron y se puede acceder a ellos». La limitación más amplia es que Kubernetes básico no define un contrato común para coordinar los datos, la aplicación, el clúster, el tráfico y la identidad, ni proporciona un recurso estándar y sostenible que describa la unidad completa de recuperación de una aplicación y sus dependencias externas. Por ello, los límites entre GitOps, las copias de seguridad, la infraestructura y la ruta del usuario siguen siendo responsabilidad del equipo incluso cuando existen herramientas maduras para cada capa. La CNCF menciona que la iniciativa Cloud Native Business Continuity de CNCF TAG Operational Resilience busca reunir contribuciones sobre el análisis de las brechas del ecosistema, las directrices de recuperación y las arquitecturas de referencia.