Respaldos en Kubernetes: qué proteger y cómo restaurar

Respuesta rápida: guarda tres capas y demuestra que puedes restaurarlas

Un plan de recuperación para Kubernetes debe cubrir el estado del clúster, los volúmenes persistentes y los datos propios de cada aplicación. Esas capas tienen ciclos de vida y requisitos de consistencia distintos. Una copia que nunca se ha restaurado solo demuestra que se creó un archivo, no que el servicio pueda volver.

Antes de elegir herramientas, define cuánto tiempo de indisponibilidad y qué pérdida de datos puede tolerar el negocio. Después, documenta quién opera cada respaldo, dónde se almacena y cómo se valida.

Empieza por RPO y RTO

El Recovery Point Objective (RPO) indica el punto de tiempo hasta el cual debes recuperar datos después de una interrupción. El Recovery Time Objective (RTO) limita el tiempo disponible para recuperar el servicio antes de afectar la operación. Define ambos con los responsables del negocio; no los copies de una plantilla. Consulta lasdefiniciones de RPO yRTO del NIST.

Si una aplicación puede perder los cambios de varias horas, una copia diaria quizá encaje. Si cada minuto de transacciones importa, necesitarás una estrategia de datos y recuperación más frecuente. Estos ejemplos son ilustrativos: solo el negocio puede aceptar el impacto y el costo asociados.

Inventaría qué necesita volver

Esta separación evita asumir que respaldar manifiestos cubre los datos, o que guardar discos conserva por sí solo la configuración que los conecta. Relaciona cada elemento con su responsable y con el procedimiento concreto para recuperarlo.

1. Protege el estado del clúster

En un clúster autoadministrado, etcd conserva el estado de los objetos de Kubernetes. La guía del proyecto recomienda crear snapshots periódicos, verificar el archivo y cifrarlo porque contiene información sensible. Confirma antes si la distribución o proveedor administra el control plane y ofrece su propio mecanismo de respaldo.

Si usas GitOps o manifiestos declarativos, guárdalos en un repositorio protegido: ayudan a reconstruir la configuración deseada. No contienen por sí solos los datos de las aplicaciones ni necesariamente cada objeto creado en tiempo de ejecución. El estado de etcd y el repositorio de configuración son piezas complementarias; define cuál usarías para cada escenario.

Ejemplo ilustrativo para guardar y consultar un snapshot de etcd:

ETCDCTL_API=3 etcdctl --endpoints="$ETCD_ENDPOINT" snapshot save ./etcd-snapshot.db
etcdutl --write-out=table snapshot status ./etcd-snapshot.db

El endpoint, certificados, versión de etcd, permisos y destino dependen de tu instalación. Protege el archivo fuera del clúster, limita quién lo puede leer y cifra la copia. No pegues certificados, claves ni snapshots en tickets o servicios públicos.

Restaurar etcd cambia el estado central del control plane. La secuencia debe seguir la documentación de la versión y distribución exactas, con los API servers detenidos cuando corresponda. No ejecutes una receta genérica sobre un clúster activo. Lee también la guía derecuperación y revisiones de etcd.

2. Respalda los volúmenes con el método que soporta tu almacenamiento

Kubernetes ofrece la API VolumeSnapshot para solicitar snapshots de volúmenes, pero la función requiere soporte del driver CSI y los componentes de snapshots instalados por la distribución. Comprueba la matriz del proveedor de almacenamiento, el comportamiento de la clase de snapshots y las restricciones de zona o topología antes de depender de ella.

Un snapshot puede facilitar una restauración rápida en el mismo backend. Para recuperación ante pérdida del clúster o del almacenamiento, verifica cómo exportar o replicar la copia a un destino independiente y cómo reconstruir el volumen en la ubicación de recuperación. La existencia de un recursoVolumeSnapshot no confirma por sí misma que exista una copia fuera del dominio de fallo.

Herramientas como Velero ofrecen más de una ruta para volúmenes. Su respaldo de sistema de archivos lee los datos desde el sistema vivo; la documentación advierte que no captura todos los archivos en el mismo instante que un snapshot. Evalúa el método contra tu almacenamiento, la consistencia requerida y tu RPO. Revisa también las limitaciones de la versión elegida.

3. Trata bases de datos y datos de aplicación por separado

Una base de datos necesita un método compatible con su motor. Para PostgreSQL,pg_dump produce una copia lógica consistente desde el inicio del proceso; otros motores tienen sus propias herramientas y condiciones. Un snapshot del volumen puede ser parte del plan, pero no sustituye la validación de transacciones, WAL, archivos relacionados ni el procedimiento de inicio de la base.

Documenta también cómo recuperar los secretos desde una ubicación protegida, los certificados, las políticas de red y las dependencias externas. Separa las credenciales de respaldo de las credenciales de administración del clúster y comprueba que siguen disponibles durante un incidente.

4. Ordena los pasos de recuperación antes del incidente

Un runbook debe decir quién puede iniciar la recuperación, qué versiones y accesos necesita, y dónde se encuentran las copias y las claves de cifrado. En un ensayo podrías recuperar primero el control plane y el acceso al almacenamiento; después, los recursos base, secretos protegidos, volúmenes y datos de aplicación; al final, desplegar cargas, restablecer entrada de tráfico y comprobar dependencias externas. Es un orden de referencia, no una receta universal: valida los requisitos de tu distribución y proveedor.

Separa los escenarios. Recuperar un namespace borrado no es lo mismo que perder el control plane, una zona de almacenamiento o todo el clúster. Para cada caso, anota qué componentes siguen disponibles, qué copia usarás y cómo evitar que la restauración afecte otros entornos. Si una base usa varios volúmenes, confirma cómo coordinar los datos relacionados antes de aceptar un snapshot como recuperable.

5. Ensaya la restauración en un entorno aislado

1. Elige una aplicación representativa y anota sus dependencias y responsables.
2. Recupera los recursos y datos en un entorno aislado, sin modificar producción.
3. Confirma que el PVC se enlaza, el volumen se monta y la aplicación inicia.
4. Ejecuta una comprobación funcional y valida datos con el responsable de la aplicación.
5. Mide cuánto tardó y cuál fue el punto recuperado; compáralos con RTO y RPO.
6. Registra errores, corrige el procedimiento y vuelve a ensayar tras cambios importantes.

Una restauración de prueba debe tener un alcance, ventana, permisos y plan de limpieza definidos. En producción, acuerda por adelantado impacto y reversión. Si el clúster usa políticas de retención, replicación o cifrado, inclúyelas en el ensayo.

Para la operación diaria, complementa esta guía con nuestros artículos derespaldos y restauración en Linux,probes de Kubernetes ydiagnóstico de CrashLoopBackOff.

Lista de revisión antes de depender de un respaldo

• RPO, RTO, alcance y responsables aprobados por el negocio.
• Copias cifradas, con acceso limitado y almacenadas fuera del clúster protegido.
• Estado del control plane, datos persistentes y datos de aplicación cubiertos.
• Compatibilidad de versiones, CSI, almacenamiento y distribución documentada.
• Restauración ensayada y validación funcional registrada.
• Ruta de contacto y permisos de emergencia disponibles para el personal autorizado.

Si necesitas revisar una plataforma existente, comparte solo el contexto general: distribución, almacenamiento, tipos de datos y objetivos de recuperación. No envíes credenciales, kubeconfig ni direcciones privadas en el formulario.

Conoce el alcance de infraestructura osolicita un diagnóstico técnico.