Consejos para tu estrategia de backup en la nube y Kubernetes

En el día a día, por norma general, nos sentimos confiados y pensamos que nuestra política de backups y de continuidad de negocio es la adecuada y que en caso de desastre, podemos recuperar nuestro sistema de producción con un RTO y RPO razonable.

Comprobar que las copias de seguridad se están realizando correctamente es una práctica bastante habitual, pero en muchas ocasiones, eso no es suficiente. En algunos casos hay problemas que pasan inadvertidos hasta que llega la hora de recuperar los datos. Estos, si se dan en sistemas críticos, pueden afectar al negocio de forma directa.

Además de comprobar que las copias de seguridad se están realizando correctamente, es muy importante:

• Disponer de un documento operativo de recuperación, accesible a todo el personal que deba llevar a cabo la restauración.
• Llevar a cabo restauraciones periódicas simuladas para comprobar que somos capaces de restaurar un sistema crítico dentro de los RTOs y RPOs establecidos.

El siguiente ejemplo demuestra porqué es importante disponer de una documentación operativa así como una política de backup adecuada al negocio:

Caso de estudio: Restauración tras un ataque de ransomware

Recientemente, un cliente sufrió un ataque de ransomware, afectando de forma directa a sus sistemas de producción y nos pidió ayuda para restablecer sus servicios. En sus sistemas de producción, basado en tecnología Kubernetes, se realizaban copias de seguridad. Estas copias, aparentemente se realizaban correctamente, y estaban alojadas en un almacenamiento de objetos utilizando Velero como software de backup.

Una vez analizados los posibles escenarios para restablecer el servicio, determinamos que lo más efectivo era desplegar el clúster de Kubernetes desde cero, ya que la infraestructura estaba desplegada mediante IaC y las aplicaciones mediante Helm, para los datos persistentes, decidimos llevar a cabo una restauración de los backups.  

Durante el ataque y la restauración de datos pasaron 8 días y la política de retención de backups era de 7 días. Aunque la creación y despliegue de las aplicaciones fue relativamente sencilla, y ya estábamos en situación de restaurar los datos, al conectar Velero con el almacenamiento de objetos en un recurso no crítico, nos llevamos una sorpresa:

• Al conectar el primer backup, Velero detectó que el tiempo de retención se había superado. A causa de esto, el garbage collector se activó y eliminó aquellos backups con retención superior a 7 días. Esto nos dejó con 1 único día de retención, es decir, el RPO quedó en el último día.
• Para evitar esta casuística tuvimos que modificar todos los ficheros de Velero alojados en el almacenamiento de objetos para modificar el tiempo de expiración.
• Generamos un script para llevar a cabo dicha acción, lo que consumió directamente al tiempo disponible de restauración:

• También nos encontramos con que algunos recursos de Kubernetes, no disponían de copias de seguridad. Por suerte estos no eran críticos y se podían reproducir.
• Una vez llevada a cabo esta modificación restauramos los datos de forma habitual y restauramos los datos del cliente y finalmente el servicio.

Esta incidencia nos demostró lo importante que es disponer de una documentación operativa de restauración que nos permita reaccionar con el tiempo suficiente e identificar los ítems necesarios de las copias de seguiridad ágilmente.

Lecciones aprendidas y recomendaciones de mejores prácticas

Desde Geko recomendamos, elaborar un plan de continuidad de negocio que incluya:

• Políticas de backup a aplicar para cumplir con RTOs y RPOs necesarios.
• Realizar procedimientos de backup y restauración.
• Describir procedimientos de validación de las copias de seguridad.
• Realizar restauraciones periódicas de sistemas críticos en entornos no productivos.
• Redactar un plan de contingencia y disaster recovery.

Estrategias específicas para Kubernetes

Si usas tecnologías de Kubernetes:

• Utiliza IaC para la infraestructura para que sea repetible en cualquier momento.
• Implementa un sistema basado en Gitops para levantar tus aplicaciones más rápidamente.
• Asegúrate que estás haciendo backups de todos los recursos necesarios. Los PVCs son un recurso importante.
• Cuando realices restauraciones en nuevos clústers deshabilita backups, schedules y gargabe collection durante el disaster recovery.

Opciones de contingencia en AWS

Si tu cloud predilecto es AWS puedes utilizar los siguientes servicios para la contingencia de tus aplicaciones:

• AWS backup
• AWS Vault lock para implementar WORM (write-once, read-many) en las copias de seguridad.
• EBS Snapshot
• EBS Snapshot schedules
• Continuos backups para los servicios soportados.
• Si usas Organizations utiliza AWS backup policies para centralizar las políticas y aplicarlas a toda la organización.
• S3 replication para replicar los datos a otras regiones.
• S3 Glacier para almacenar largas retenciones.

Esperamos que esta guía te haya sido útil para entender las mejores prácticas con tu estrategia de backup en la nube y Kubernetes. Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.