Copia de seguridad / restauración de Couchbase en el entorno K8s

1. Introducción

La copia de seguridad periódica de los datos es una parte importante de cualquier despliegue de bases de datos de producción, que ayuda a garantizar la recuperación de los datos en caso de desastre y también minimiza la inconsistencia de los datos cuando se requiere una restauración.

Couchbase proporciona cbbackupmgr que se ha mejorado a lo largo de los años hasta convertirse en una herramienta de copia de seguridad y restauración de nivel empresarial para realizar copias de seguridad de grandes conjuntos de datos con un rendimiento mucho mayor, por lo que recomendamos utilizar esta herramienta en la producción. Cabe mencionar que en Servidor Couchbase 6.5 hemos revisado por completo el motor de copia de seguridad y almacenamiento, y hemos introducido una mayor relación de compresión, lo que ha mejorado mucho el rendimiento de la copia de seguridad y la restauración y ha reducido los requisitos de almacenamiento de cada instantánea de copia de seguridad, con el consiguiente ahorro de costes.

---

2. 2. Buenas prácticas

Aunque cbbackupmgr existe en Couchbase_HOME, es no Se recomienda ejecutar esta utilidad desde cualquiera de los nodos activos del cluster. Ya que estaría compitiendo por los recursos de las peticiones activas y podría potencialmente obstaculizar el rendimiento de su sistema de base de datos.

Es, por tanto, una buena práctica proporcionar una instancia separada (para las necesidades de copia de seguridad y restauración) con sólo los binarios de Couchbase instalados pero sin los servicios de Couchbase ejecutándose, para que los recursos puedan ser mejor gestionados tanto para el cluster de base de datos como para el nodo de copia de seguridad.

Como se puede ver en la figura anterior, se aprovisiona un nodo de copia de seguridad/restauración separado además de un clúster Couchbase de cinco nodos. Otra buena práctica es asignar suficiente espacio de almacenamiento para almacenar al menos 5 veces el tamaño del conjunto de datos de Couchbase. Objetivo del Punto de Recuperación (OPR) de la empresa.

3. Estrategia de copia de seguridad

cbbackupmgr ofrece un conjunto de comandos que permite a los administradores de bases de datos aplicar la estrategia de copia de seguridad que mejor se adapte a sus necesidades. Estos son algunos de los comandos:

• cbbackupmgr copia de seguridad – Copia de seguridad de los datos de un clúster Couchbase.
• cbbackupmgr compacto – Compacta una copia de seguridad
• cbbackupmgr fusionar – Fusiona las copias de seguridad
• cbbackupmgr config – Crea un nuevo repositorio de copias de seguridad
• cbbackupmgr list – Lista las copias de seguridad del archivo

Con estos comandos se puede aplicar cualquiera de las tres estrategias de copia de seguridad mencionadas en el documentación. En el siguiente ejemplo, describiremos Fusión periódica en el contexto de Couchbase Cluster ejecutándose en un entorno Kubernetes.

4. Fusión periódica

Esta estrategia de copia de seguridad pretende tener la menor sobrecarga de la base de datos, ya que requiere la menor cantidad de tiempo para realizar la copia de seguridad de los cambios y prácticamente ningún consumo de recursos del clúster de la base de datos para consolidar los datos durante el proceso de compactación y fusión (como ocurre en el nodo de copia de seguridad).

A grandes rasgos, así es como Fusión periódica estrategia funciona:

1. Configurar el repositorio de copias de seguridad mediante cbbackupmgr config
2. Realice una copia de seguridad incremental de la base de datos (en el repositorio) utilizando cbbackupmgr copia de seguridad
3. Realizar la compactación de la copia de seguridad utilizando cbbackupmgr compacto para que el espacio en disco pueda utilizarse de forma eficiente.
4. Fusionar las copias de seguridad más antiguas con cbbackupmgr fusionar para que el número de copias de seguridad en el repositorio no crezca infinitamente y las necesidades de espacio se mantengan bajo control.

Nota: Los pasos anteriores se recogen en el backup-with-periodic-merge.sh que luego utilizaremos en nuestra configuración de Kubernetes para realizar copias de seguridad periódicas.

5. Copia de seguridad de los datos de Couchbase

En mi último blog sobre Couchbase Autonomous Operator, he descrito paso a paso en cómo desplegar un clúster Couchbase autorreparable y de alta disponibilidad mediante Persistent Volumes. Suponiendo que haya seguido estos pasos y ya haya desplegado el clúster, los pasos siguientes describirán cómo puede configurar la capacidad de copia de seguridad automática utilizando cronjob. Se considera una buena práctica hacer copias de seguridad de los datos con regularidad, así como probar la restauración de las copias de seguridad para confirmar el proceso de restauración antes de que sea realmente necesaria la recuperación en caso de desastre.

Esta funcionalidad no la proporciona el Operador y se deja en manos del administrador del clúster para que defina las políticas de copia de seguridad y pruebe la restauración de los datos. Esta sección describe algunos patrones comunes que pueden emplearse para realizar las funciones requeridas.

5.1. Crear clase de almacenamiento

Las definiciones de recursos de Kubernetes que se muestran a continuación ilustran una disposición típica para la copia de seguridad que guarda el estado de todo el clúster. Primero tendríamos que definir el recurso StorageClass que formatearemos utilizando xfs para un rendimiento óptimo.

Utilizando la definición anterior en backup-sc.yaml podemos crear una clase de almacenamiento como ésta:

5.2. Crear Volumen Persistente

Un volumen persistente se reclama para mantener los datos a salvo en caso de interrupción. Deberá planificar el tamaño de la reclamación en función del tamaño previsto del conjunto de datos, el número de días de conservación de los datos y si se utilizan copias de seguridad incrementales.

Guardar la definición anterior en backup-pvc.yaml y crear la reclamación:

5.3. Configurar el repositorio de copias de seguridad

Antes de que podamos empezar a tomar instantáneas de nuestros datos periódicamente, necesitamos configurar la ubicación del archivo de copia de seguridad. Se crea un trabajo para montar el volumen persistente e inicializar un repositorio de copias de seguridad. El repositorio se llama couchbase que se asignará al nombre del clúster en especificaciones posteriores.

Guardar la definición anterior en config.yaml y crear un repositorio de copias de seguridad:

5.3. Ejecutar copia de seguridad como CronJob

Cree un cronjob como se describe en la sección periodic-backup.yaml que realiza una copia de seguridad del clúster Couchbase a) descargando el script de copia de seguridad en el pod b) ejecutando el script y realizando una copia de seguridad de los datos del clúster utilizando el volumen de almacenamiento persistente.

En el YAML anterior estamos ejecutando la copia de seguridad cada 5 minutos, pero puede cambiar la frecuencia para que pueda cumplir con su RPO de negocio. Como nuestro cluster Couchbase está desplegado dentro del espacio de nombres emart así que desplegaremos el cronjob de copia de seguridad bajo el mismo espacio de nombres:

5.4 Validar trabajo de copia de seguridad periódica

En este punto, puedes empezar a ver como el cronjob se activa cada 5 minutos. Y una vez que se activa se ejecutará tres initContainers (wget-backup-script, chmod-script, periodic-merge) en orden secuencial seguidos de los comandos cointainers (borrar-guión):

Puede ver los registros de cada initContainers después de que el pod muestre el estado Completado. En initContainers que nos interesa se llama fusión periódica:

Nota: Como puede verse en los registros anteriores, antes del paso de fusión había cuatro copias de seguridad disponibles y después de la fusión hay tres instantáneas de copia de seguridad que se denominan RESTOREPOINTS en backup-with-periodic-merge.sh guión.

Con esto concluye la sección de copias de seguridad.

6. Restauración de

Al igual que una copia de seguridad, podemos restaurar los datos a un nuevo clúster Couchbase con un trabajo de Kubernetes.

Si prefiere crear un pod temporal de copia de seguridad-restauración para ver qué copias de seguridad están disponibles o para solucionar un problema, puede montar el mismo persistentVolumeClaim a un nuevo pod. Esta es la definición del pod que se puede almacenar en backup-pod.yaml:

Ejecute kubectl para abrir el pod temporalmente:

Una vez que el nodo de respaldo está en ejecución, podemos iniciar sesión en ese pod:

Y ejecutar cbbackupmgr list para ver las copias de seguridad existentes:

Y también puede ejecutar cbbackupmgr restaurar manualmente:

Una vez que haya terminado de restaurar sólo tiene que eliminar el pod:

7. Conclusión

Examinamos paso a paso cómo se puede configurar un cronjob de copia de seguridad, que automatiza el proceso de tomar la copia de seguridad periódica en un intervalo predefinido. Utilizamos un backup-with-periodic-merge.sh que ejecuta a) la copia de seguridad, b) la compactación y c) la fusión en un único script. Este script se utilizó en el periodic-backup.yaml que automatizó el proceso de creación de copias de seguridad en el entorno Kubernetes. Esperamos que utilice las mejores prácticas descritas en este blog y planifique la realización de copias de seguridad periódicas, así como la validación de dichas copias mediante el comando de restauración con regularidad.