Backup de Kubernetes: Velero y Kasten K10

Por Que Kubernetes Necesita un Backup Específico

La arquitectura de Kubernetes separa deliberadamente la definición de la carga (los objetos de la API: deployments, services, configmaps, secrets, RBAC) del dato que produce (los volúmenes persistentes). Ambos viven en sitios distintos: el estado de la API se guarda en etcd, mientras que los datos residen en volúmenes gestionados por el driver CSI del proveedor de almacenamiento. Un backup útil tiene que capturar los dos a la vez y de forma coherente.

Un snapshot de las VMs de los nodos parece una red de seguridad, pero es engañoso: los nodos son ganado, no mascotas. Cuando un pod se reprograma en otro nodo, sus datos ya no están en el disco que fotografiaste. Además, un snapshot de infraestructura no ofrece granularidad: no puedes restaurar únicamente el namespace produccion sin sobreescribir todo el clúster, ni recuperar un solo PersistentVolumeClaim.

Los escenarios de pérdida que un backup nativo de Kubernetes cubre y uno de VMs no son concretos y frecuentes:

• check_circle Borrado accidental de un namespace: un kubectl delete namespace mal dirigido elimina en segundos decenas de objetos y sus PVCs asociados.
• check_circle Error en un helm upgrade: una plantilla defectuosa o un valor equivocado deja la aplicación en un estado intermedio del que no hay rollback limpio.
• check_circle Ransomware: un atacante que llega a los volúmenes cifra los datos de las bases de datos y los ficheros de usuario del clúster.
• check_circle Migración entre clústeres: mover una aplicación de un clúster on-premise a otro, o entre proveedores, exige trasladar objetos y datos como una unidad consistente.

Que Hay Que Capturar: Estado, Volumenes y Consistencia

Un backup completo de Kubernetes tiene tres componentes que hay que proteger conjuntamente. Ignorar cualquiera de ellos deja la restauración incompleta:

• arrow_right Estado del clúster (objetos de la API): deployments, statefulsets, services, ingress, configmaps, secrets, RBAC, CRDs y sus recursos personalizados. Es la fotografía de qué debe estar corriendo y cómo. Se obtiene consultando la API de Kubernetes, no leyendo etcd directamente.
• arrow_right Volúmenes persistentes (PV/PVC): los datos reales de bases de datos, colas, repositorios de ficheros. Se protegen mediante snapshots CSI del proveedor de almacenamiento o copiando el contenido del volumen a un destino externo.
• arrow_right Consistencia con la aplicación: capturar el volumen en un instante en el que la aplicación tiene sus datos coherentes en disco. Sin esto, un snapshot de una base de datos activa puede quedar en un estado del que no arranca.

La consistencia se consigue con hooks pre y post backup: comandos que se ejecutan dentro del contenedor antes de la copia (por ejemplo, un FLUSH TABLES WITH READ LOCK o un fsfreeze) y después de ella. De este modo el snapshot del volumen se toma con la aplicación en un punto recuperable, no en mitad de una escritura.

Velero: El Estándar Open Source

Velero es la herramienta de backup para Kubernetes más extendida del ecosistema open source. Se despliega como un conjunto de pods dentro del clúster y funciona con un modelo sencillo: consulta la API de Kubernetes para capturar los objetos, dispara snapshots CSI de los volúmenes, y envía todo a un bucket de object storage compatible con S3.

Sus capacidades clave cubren la práctica totalidad de las necesidades de un equipo de plataforma:

• check_circle Backup de recursos de la API filtrable por namespace, etiqueta o tipo de recurso, con posibilidad de excluir lo que no interese.
• check_circle Snapshots de volúmenes vía CSI o copia a nivel de sistema de ficheros con el integrado Kopia/Restic cuando el driver no soporta snapshots.
• check_circle Backup a object storage S3, con soporte para cualquier endpoint compatible, incluido almacenamiento externo al proveedor del clúster.
• check_circle Scheduling con expresiones cron y políticas de retención (TTL) por backup.
• check_circle Restauración selectiva y migración entre clústeres: reasigna storage classes y mapea namespaces al restaurar en un clúster distinto.
• check_circle Hooks pre/post para garantizar la consistencia de aplicación en cargas con estado.

Velero brilla en equipos con cultura de infraestructura como código: se opera desde CLI y manifiestos, se integra bien en pipelines y no tiene coste de licencia. A cambio, exige más trabajo manual para diseñar las políticas por aplicación, no incluye interfaz gráfica de serie y la consistencia transaccional depende de que configures los hooks correctamente.

Kasten K10: La Plataforma Comercial de Veeam

Kasten K10, propiedad de Veeam, es una plataforma comercial de protección de datos diseñada específicamente para Kubernetes. Donde Velero ofrece los bloques de construcción, Kasten aporta una capa de gestión, gobierno y automatización pensada para entornos de producción exigentes y equipos que necesitan soporte con SLA.

Sus diferenciadores frente a la opción open source son claros:

• check_circle Descubrimiento por aplicación: agrupa automáticamente los objetos y volúmenes que forman una aplicación, en lugar de trabajar recurso a recurso.
• check_circle Políticas declarativas de frecuencia, retención y destino aplicables por etiqueta a decenas de aplicaciones a la vez.
• check_circle Consistencia transaccional con blueprints específicos para bases de datos y cargas con estado.
• check_circle Cifrado de los datos en tránsito y en reposo, y detección de ransomware que alerta ante cambios anómalos en los backups.
• check_circle Interfaz gráfica con panel de estado, informes de cumplimiento y gestión multi-clúster centralizada.

Kasten K10 es la elección natural cuando el número de clústeres y aplicaciones crece, cuando hay requisitos de cumplimiento que exigen informes, o cuando el equipo prefiere una herramienta con soporte comercial en lugar de mantener la integración por su cuenta. Su modelo de licencia por nodo trabajador introduce un coste que Velero no tiene, pero a cambio reduce el esfuerzo operativo.

Comparativa: Velero vs Kasten K10

Ambas herramientas resuelven el mismo problema de fondo, pero con filosofías distintas. La siguiente tabla resume las diferencias clave a la hora de elegir:

Buenas Practicas: 3-2-1, Inmutabilidad y Restauracion Probada

Elegir la herramienta es solo la mitad del trabajo. Una estrategia de backup de Kubernetes que aguante un incidente real se apoya en un puñado de principios que no dependen del producto:

• check_circle Regla 3-2-1: tres copias de los datos, en dos medios distintos, con una copia offsite. El destino S3 debe estar fuera del clúster y, preferiblemente, fuera del datacenter de producción.
• check_circle Destino S3 inmutable: usa object lock para que ni un ransomware ni un operador comprometido puedan borrar o cifrar los backups. Lo desarrollamos en nuestra guía sobre S3 Object Lock e inmutabilidad.
• check_circle Prueba la restauración completa de forma periódica en un clúster de recuperación. Un backup que nunca se ha restaurado es una hipótesis, no una garantía.
• check_circle No guardes secrets en claro: cifra los backups y protege las credenciales que contienen los objetos Secret. Un backup expuesto es una filtración de credenciales esperando a ocurrir.

Un punto que genera confusión frecuente: GitOps no es backup. Herramientas como Argo CD o Flux reconstruyen los manifiestos declarativos desde tu repositorio Git, pero no restauran los datos de los volúmenes ni el estado generado en runtime (secrets creados dinámicamente, tokens, datos en bases de datos). GitOps te devuelve la definición de la aplicación; el backup te devuelve la información. Son complementarios, no sustitutos. Si estás decidiendo dónde alojar tus clústeres, nuestra comparativa de Kubernetes bare metal frente a cloud te ayudará a dimensionar también la estrategia de recuperación.

EasyDataHost: Almacenamiento S3 y Servidores para tus Clusters

Tanto Velero como Kasten K10 necesitan un destino fiable donde depositar los backups y una infraestructura sólida donde correr los clústeres. En EasyDataHost cubrimos las dos piezas desde nuestro datacenter propio en España:

• arrow_right Nuestro almacenamiento S3 es un destino directo para los backups de Velero y Kasten, con soporte de object lock para copias inmutables offsite.
• arrow_right Ofrecemos servidores dedicados con NVMe para desplegar clústeres de Kubernetes con el rendimiento de I/O que exigen las cargas con estado.
• arrow_right Complementamos la estrategia con backup offsite Veeam para las cargas que viven fuera de Kubernetes, unificando la protección de todo tu entorno.

Toda nuestra infraestructura opera bajo certificación ISO 27001 y conformidad ENS, con soporte técnico 24/7. Si estás diseñando la protección de tus clústeres, contacta con nuestro equipo para un análisis técnico sin compromiso.

Preguntas Frecuentes

Conclusion

Proteger Kubernetes exige un enfoque propio que capture a la vez el estado de la API y los volúmenes persistentes, con consistencia de aplicación y un destino externo seguro. Las ideas clave para llevarte a casa:

• arrow_right Un snapshot de VMs no es un backup de Kubernetes: falta granularidad, consciencia de la API y consistencia entre estado y datos.
• arrow_right Velero es la opción open source: potente, sin coste de licencia y perfecta para equipos GitOps dispuestos a operar por CLI.
• arrow_right Kasten K10 es la plataforma comercial: interfaz gráfica, descubrimiento por aplicación, detección de ransomware y soporte con SLA para entornos grandes.
• arrow_right Aplica la regla 3-2-1 con destino S3 inmutable, prueba la restauración completa y recuerda que GitOps no es backup: reconstruye la definición, no los datos.