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:
- Configurar el repositorio de copias de seguridad mediante cbbackupmgr config
- Realice una copia de seguridad incremental de la base de datos (en el repositorio) utilizando cbbackupmgr copia de seguridad
- Realizar la compactación de la copia de seguridad utilizando cbbackupmgr compacto para que el espacio en disco pueda utilizarse de forma eficiente.
- 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.
# Crear clase de almacenamiento para operaciones de copia de seguridad/restauración
apiVersion: storage.k8s.io/v1
tipo: StorageClass
metadatos:
labels:
k8s-addon: storage-aws.addons.k8s.io
nombre: gp2-backup-storage
parámetros:
tipo: gp2
fsTipo: xfs
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Retener
volumeBindingMode: WaitForFirstConsumerUtilizando la definición anterior en backup-sc.yaml podemos crear una clase de almacenamiento como ésta:
$ kubectl create -f backup-sc.yaml -n emart5.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.
# Definir volumen de almacenamiento de copia de seguridad
tipo: PersistentVolumeClaim
apiVersion: v1
metadatos:
name: backup-pvc
spec:
storageClassName: gp2-backup-storage
recursos:
peticiones:
almacenamiento: 50Gi
modos de acceso:
- LecturaEscrituraUnaVezGuardar la definición anterior en backup-pvc.yaml y crear la reclamación:
$ kubectl create -f backup-pvc.yaml -n emart5.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.
# Create a backup repository
kind: Job
apiVersion: batch/v1
metadata:
name: couchbase-cluster-backup-config
spec:
template:
spec:
containers:
- name: backup-config
image: couchbase/server:enterprise-6.5.0
command: ["cbbackupmgr", "config", "--archive", "/backups", "--repo", "couchbase"]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
volumes:
- name: couchbase-cluster-backup-volume
persistentVolumeClaim:
claimName: backup-pvc
restartPolicy: NeverGuardar la definición anterior en config.yaml y crear un repositorio de copias de seguridad:
$ kubectl create -f config.yaml -n emart5.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.
kind: CronJob
apiVersion: batch/v1beta1
metadata:
name: couchbase-cluster-backup-create
spec:
schedule: "*/5 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
#Delete backup-with-periodic-merge script so that new one can be pulled with each run
- name: delete-script
image: couchbase/server:enterprise-6.5.0
command: ["rm", "/backups/backup-with-periodic-merge.sh"]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
initContainers:
#Download the backup script from the git repo
- name: wget-backup-script
image: couchbase/server:enterprise-6.5.0
command: ["wget", "https://raw.githubusercontent.com/couchbaselabs/cboperator-hol/master/eks/cb-operator-guide/files/sh/backup-with-periodic-merge.sh", "-P", "/backups/."]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
#Change the mod of the backup script to execution
- name: chmod-script
image: couchbase/server:enterprise-6.5.0
command: ["chmod", "700", "/backups/backup-with-periodic-merge.sh"]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
#Run the script so it can do a) Backup b) Compaction c) Merge with each snapshot
- name: periodic-merge
image: couchbase/server:enterprise-6.5.0
command: ["sh", "-c" ,"/backups/backup-with-periodic-merge.sh --cluster cbdemo-srv.emart.svc"]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
volumes:
- name: couchbase-cluster-backup-volume
persistentVolumeClaim:
claimName: backup-pvc
restartPolicy: NeverEn 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:
$ kubectl apply -f periodic-backup.yaml -n emart
cronjob.batch/couchbase-cluster-backup-create creado5.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):
$ kubectl get pods -n emart -w
NAME READY STATUS RESTARTS AGE
backup-node 1/1 En ejecución 0 1d
cbdemo-0000 1/1 En ejecución 0 5d
cbdemo-0001 1/1 En ejecución 0 5d
cbdemo-0002 1/1 En ejecución 0 5d
cbdemo-0003 1/1 En ejecución 0 5d
cbdemo-0004 1/1 En ejecución 0 5d
couchbase-operator-7654d844cb-gn4bw 1/1 En ejecución 0 5d
couchbase-operator-admission-7ff868f54c-5pklx 1/1 En ejecución 0 5d
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Pendiente 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Pendiente 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:0/3 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:1/3 0 3s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:2/3 0 4s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:2/3 0 6s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 PodInitializing 0 27s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Finalizado 0 30sPuede 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:
$ kubectl logs couchbase-cluster-backup-create-1580357820-tz2hg -n emart -c periodic-merge
---------------------------------------------------------
BEGIN STEP 1: BACKUP : Thu Jan 30 04:17:12 UTC 2020
Running backup...
Command: cbbackupmgr backup --archive /backups --repo couchbase --cluster couchbase://cbdemo-srv.emart.svc --username Administrator --password password --threads 2
Warning: Progress bar disabled because terminal width is less than 80 characters
Backup successfully completed
Backed up bucket "gamesim-sample" succeeded
Mutations backedup; 586, Mutations failed to backup: 0
Deletions backedup: 0, Deletions failed to backup: 0
Backed up bucket "travel-sample" succeeded
Mutations backedup; 0, Mutations failed to backup: 0
Deletions backedup: 0, Deletions failed to backup: 0
---------------------------------------------------------
BEGIN STEP 2: COMPACTION : Thu Jan 30 04:17:20 UTC 2020
List of backup snapshots ...
2020-01-28T23_01_37.592188562Z
2020-01-28T23_03_34.160387835Z
2020-01-28T23_05_08.103740281Z
2020-01-30T04_17_12.702824188Z
Last backup name is: 2020-01-30T04_17_12.702824188Z
Compacting the backup...
Command: cbbackupmgr compact --archive /backups --repo couchbase --backup 2020-01-30T04_17_12.702824188Z
Compaction succeeded, 0 bytes freed
---------------------------------------------------------
BEGIN STEP 3: Merging old backup : Thu Jan 30 04:17:24 UTC 2020
Size Items Name
604.93MB - + couchbase
192.00MB - + 2020-01-28T23_01_37.592188562Z
192.00MB - + beer-sample
37B 0 analytics.json
414B 0 bucket-config.json
192.00MB 7303 + data
192.00MB 7303 1024 Shards
2B 0 full-text.json
1.94KB 1 gsi.json
784B 1 views.json
192.02MB - + 2020-01-28T23_03_34.160387835Z
192.02MB - + travel-sample
0B 0 analytics.json
416B 0 bucket-config.json
192.00MB 31591 + data
192.00MB 31591 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.json
64.02MB - + 2020-01-28T23_05_08.103740281Z
64.02MB - + travel-sample
0B 0 analytics.json
416B 0 bucket-config.json
64.00MB 0 + data
64.00MB 0 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.json
156.89MB - + 2020-01-30T04_17_12.702824188Z
92.88MB - + gamesim-sample
0B 0 analytics.json
417B 0 bucket-config.json
92.88MB 586 + data
92.88MB 586 1024 Shards
2B 0 full-text.json
1.95KB 1 gsi.json
501B 1 views.json
64.02MB - + travel-sample
0B 0 analytics.json
416B 0 bucket-config.json
64.00MB 0 + data
64.00MB 0 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.json
Start 2020-01-28T23_01_37.592188562Z, END 2020-01-28T23_03_34.160387835Z
Merging old backups...
Command: cbbackupmgr merge --archive /backups --repo couchbase --start 2020-01-28T23_01_37.592188562Z --end 2020-01-28T23_03_34.160387835Z
Merge completed successfully
Size Items Name
412.92MB - + couchbase
192.02MB - + 2020-01-28T23_03_34.160387835Z
192.02MB - + travel-sample
37B 0 analytics.json
416B 0 bucket-config.json
192.00MB 31591 + data
192.00MB 31591 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.json
64.02MB - + 2020-01-28T23_05_08.103740281Z
64.02MB - + travel-sample
0B 0 analytics.json
416B 0 bucket-config.json
64.00MB 0 + data
64.00MB 0 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.json
156.89MB - + 2020-01-30T04_17_12.702824188Z
92.88MB - + gamesim-sample
0B 0 analytics.json
417B 0 bucket-config.json
92.88MB 586 + data
92.88MB 586 1024 Shards
2B 0 full-text.json
1.95KB 1 gsi.json
501B 1 views.json
64.02MB - + travel-sample
0B 0 analytics.json
416B 0 bucket-config.json
64.00MB 0 + data
64.00MB 0 1024 Shards
2B 0 full-text.json
15.57KB 10 gsi.json
2B 0 views.jsonNota: 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.
kind: Job
apiVersion: batch/v1
metadata:
name: couchbase-cluster-restore
spec:
template:
spec:
containers:
- name: couchbase-cluster-restore
image: couchbase/server:enterprise-6.0.2
command: ["cbbackupmgr", "restore", "--archive", "/backups", "--repo", "couchbase", "--cluster", "couchbase://cbdemo-srv.emart.svc", "--username", "Administrator", "--password", "password"]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
volumes:
- name: couchbase-cluster-backup-volume
persistentVolumeClaim:
claimName: backup-pvc
restartPolicy: NeverSi 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:
apiVersion: v1
kind: Pod
metadata:
name: backup-node
spec: # specification of the pod's contents
containers:
- name: backup-pod
image: couchbase/server:enterprise-6.5.0
# Just spin & wait forever
command: [ "/bin/bash", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumeMounts:
- name: "couchbase-cluster-backup-volume"
mountPath: "/backups"
volumes:
- name: couchbase-cluster-backup-volume
persistentVolumeClaim:
claimName: backup-pvc
restartPolicy: NeverEjecute kubectl para abrir el pod temporalmente:
$ kubectl apply -f br/backup-pod.yaml -n emart
$ kubectl get pods -n emart
NAME READY STATUS RESTARTS AGE
backup-node 1/1 En ejecución 0 3d1h
cbdemo-0000 1/1 En ejecución 0 7d1h
cbdemo-0001 1/1 En ejecución 0 7d1h
cbdemo-0002 1/1 En ejecución 0 7d1h
cbdemo-0003 1/1 En ejecución 0 7d1h
cbdemo-0004 1/1 En ejecución 0 7d1h
couchbase-operator-7654d844cb-gn4bw 1/1 En ejecución 0 7d2h
couchbase-operator-admission-7ff868f54c-5pklx 1/1 En ejecución 0 7d2hUna vez que el nodo de respaldo está en ejecución, podemos iniciar sesión en ese pod:
$ kubectl exec -it backup-node -n emart -- /bin/bash
root@nodo-de-respaldo:/Y ejecutar cbbackupmgr list para ver las copias de seguridad existentes:
# cbbackupmgr list --repo couchbase --archive /backups
Tamaño Elementos Nombre
256.04MB - + couchbase
0B - + 2020-01-30T04_17_12.702824188Z
0B - + gamesim-sample
0B 0 analytics.json
0B 0 + datos
0B 0 Error: no se han encontrado fragmentos de datos
0B 0 full-text.json
0B 0 gsi.json
0B 0 views.json
128.02MB - + 2020-01-30T04_18_13.021340423Z
....Y también puede ejecutar cbbackupmgr restaurar manualmente:
# cbbackupmgr restore --archive /backups --repo couchbase --cluster couchbase://cbdemo-srv.emart.svc --username Administrator --password passwordUna vez que haya terminado de restaurar sólo tiene que eliminar el pod:
$ kubectl delete -f backup-pod.yaml -n emart7. 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.
