Backup/restauração do Couchbase no ambiente K8s

1. Introdução

O backup periódico dos dados é uma parte importante de qualquer implantação de banco de dados de produção, o que ajuda a garantir a recuperação dos dados em caso de desastre e também minimiza a inconsistência dos dados quando uma restauração é necessária.

O Couchbase fornece cbbackupmgr que foi aprimorado ao longo dos anos para se tornar uma ferramenta de backup e restauração de nível empresarial para fazer backup de grandes conjuntos de dados com desempenho muito mais alto; portanto, recomendamos que essa ferramenta seja usada na produção. Vale a pena mencionar que, em Servidor Couchbase 6.5 reformulamos completamente o mecanismo de armazenamento de backup e introduzimos uma taxa de compactação mais alta, o que resultou em um desempenho de backup-restauração muito melhor e reduziu os requisitos de armazenamento para cada instantâneo de backup, resultando em economia de custos.

2. Melhores práticas

Embora cbbackupmgr existe em Couchbase_HOME, ele é não Recomenda-se executar esse utilitário em qualquer um dos nós ativos do cluster. Como ele estaria competindo por recursos de solicitações ativas, poderia prejudicar o desempenho do seu sistema de banco de dados.

Portanto, é uma prática recomendada fornecer uma instância separada (para necessidades de backup e restauração) com apenas os binários do Couchbase instalados, mas sem serviços do Couchbase em execução, para que os recursos possam ser mais bem gerenciados para o cluster do banco de dados e o nó de backup.

Como pode ser visto na figura acima, um nó de backup/restauração separado é provisionado além de um cluster do Couchbase de cinco nós. Outra prática recomendada é alocar armazenamento suficiente para manter pelo menos 5x o tamanho do conjunto de dados do Couchbase, de modo que haja espaço suficiente para armazenar os snapshots necessários do banco de dados para atender aos requisitos de Objetivo do ponto de recuperação (RPO) da empresa.

3. Estratégia de backup

cbbackupmgr fornece um conjunto de comandos que permite que os DBAs implementem uma estratégia de backup que atenda melhor às suas necessidades comerciais. Veja a seguir alguns dos comandos:

• cbbackupmgr backup - Faz o backup dos dados de um cluster do Couchbase.
• cbbackupmgr compact - Compacta um backup
• cbbackupmgr merge - Mescla backups
• Configuração do cbbackupmgr - Cria um novo repositório de backup
• Lista cbbackupmgr - Lista os backups no arquivo

Usando esses comandos, é possível implementar qualquer uma das três estratégias de backup mencionadas na seção documentação. No exemplo abaixo, descreveremos Mesclagem periódica no contexto do Couchbase Cluster em execução no ambiente Kubernetes.

4. Mesclagem periódica

Essa estratégia de backup deve ter a menor sobrecarga de banco de dados, pois requer o menor tempo possível para fazer o backup das alterações e praticamente nenhum consumo de recursos do cluster do banco de dados para consolidar os dados durante o processo de compactação e mesclagem (como ocorre no nó de backup).

Em um nível elevado, veja como Mesclagem periódica estratégia funciona:

1. Configurar o repositório de backup usando Configuração do cbbackupmgr
2. Faça um backup incremental do banco de dados (no repositório) usando cbbackupmgr backup
3. Executar a compactação de backup usando cbbackupmgr compact para que o espaço em disco possa ser usado com eficiência.
4. Mesclar os backups mais antigos usando cbbackupmgr merge para que o número de backups no repositório não cresça infinitamente e os requisitos de espaço permaneçam sob controle.

Observação: As etapas acima são capturadas no backup-com-periodic-merge.sh que usaremos posteriormente em nossa configuração do Kubernetes para fazer backups periódicos.

5. Backup dos dados do Couchbase

No meu último blog sobre o Couchbase Autonomous Operator, descrevi passo a passo como como implantar um cluster do Couchbase com autocorreção e alta disponibilidade usando Persistent Volumes. Supondo que você tenha seguido essas etapas e já tenha implantado o cluster, as etapas abaixo descreverão como você pode configurar o recurso de backup automático usando o cronjob. É considerada uma prática recomendada fazer backups regulares dos dados e também testar a restauração de backups para confirmar o processo de restauração antes que a recuperação de desastres seja realmente necessária.

Essa funcionalidade não é fornecida pelo Operador e é deixada para o administrador do cluster definir políticas de backup e testar a restauração de dados. Esta seção descreve alguns padrões comuns que podem ser empregados para executar as funções necessárias.

5.1. Criar classe de armazenamento

As definições de recursos do Kubernetes abaixo ilustram um arranjo típico para backup que salva o estado de todo o cluster. Primeiro, precisaríamos definir o recurso Classe de armazenamento que será formatado usando xfs para obter o melhor desempenho possível.

# Create storage class for backup/restore operations
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  labels:
    k8s-addon: storage-aws.addons.k8s.io
  name: gp2-backup-storage
parameters:
  type: gp2
  fsType: xfs
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Usando a definição acima em backup-sc.yaml podemos criar uma classe de armazenamento como esta:

$ kubectl create -f backup-sc.yaml -n emart

5.2. Criar volume persistente

Um volume persistente é reivindicado para manter os dados seguros no caso de uma interrupção. Você precisará planejar o tamanho da reivindicação com base no tamanho esperado do conjunto de dados, no número de dias de retenção de dados e se os backups incrementais são usados.

# Define backup storage volume
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: backup-pvc
spec:
  storageClassName: gp2-backup-storage
  resources:
    requests:
      storage: 50Gi
  accessModes:
    - ReadWriteOnce

Salvar a definição acima em backup-pvc.yaml e criar a reivindicação:

$ kubectl create -f backup-pvc.yaml -n emart

5.3. Configurar o repositório de backup

Antes de começarmos a tirar instantâneos de nossos dados periodicamente, precisamos configurar o local do arquivo de backup. É criado um trabalho para montar o volume persistente e inicializar um repositório de backup. O repositório é denominado couchbase que será mapeado para o nome do cluster em especificações 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: Never

Salvar a definição acima em config.yaml e criar um repositório de backup:

$ kubectl create -f config.yaml -n emart

5.3. Executar backup como CronJob

Crie um cronjob conforme descrito na seção periodic-backup.yaml que faz um backup do cluster do Couchbase: a) baixando o script de backup no pod; b) executando o script e fazendo o backup dos dados do cluster usando o volume de armazenamento 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: Never

No YAML acima, estamos executando o backup a cada 5 minutos, mas você pode alterar a frequência para que ele possa atender ao RPO da sua empresa. Como nosso cluster do Couchbase está implantado no namespace emart portanto, implantaremos o cronjob de backup no mesmo namespace:

$ kubectl apply -f periodic-backup.yaml -n emart

cronjob.batch/couchbase-cluster-backup-create created

5.4 Validar trabalho de backup periódico

Nesse ponto, você pode começar a observar o cronjob entrando em ação a cada 5 minutos. E assim que ele se tornar ativo, executará três initContainers (wget-backup-script, chmod-script, periodic-merge) em ordem sequencial, seguidos pelos comandos contêineres (script de exclusão):

$ kubectl get pods -n emart -w

NAME                                            READY     STATUS    RESTARTS   AGE
backup-node                                     1/1       Running   0          1d
cbdemo-0000                                     1/1       Running   0          5d
cbdemo-0001                                     1/1       Running   0          5d
cbdemo-0002                                     1/1       Running   0          5d
cbdemo-0003                                     1/1       Running   0          5d
cbdemo-0004                                     1/1       Running   0          5d
couchbase-operator-7654d844cb-gn4bw             1/1       Running   0          5d
couchbase-operator-admission-7ff868f54c-5pklx   1/1       Running   0          5d

couchbase-cluster-backup-create-1580357820-tz2hg   0/1       Pending   0         2s
couchbase-cluster-backup-create-1580357820-tz2hg   0/1       Pending   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       Completed   0         30s

Você pode visualizar os registros de cada initContainers depois que o pod exibir o status Concluído. O initContainers em que estamos interessados é chamado de mesclagem 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.json

Observação: como pode ser visto nos registros acima, antes da etapa de mesclagem, havia quatro backups disponíveis e, após a mesclagem, há três instantâneos de backup que são chamados de PONTOS DE RESTAURAÇÃO em backup-com-periodic-merge.sh roteiro.

Isso conclui a seção de backup.

6. Restauração

Assim como em um backup, podemos restaurar os dados em um novo cluster do Couchbase com um Kubernetes Job.

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: Never

Se preferir criar um pod de backup-restauração temporário para ver quais backups estão disponíveis ou para solucionar um problema, você pode montar o mesmo pod persistentVolumeClaim para um novo pod. Aqui está a definição do pod que pode ser armazenada em 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: Never

Execute o kubectl para abrir o pod temporariamente:

$ kubectl apply -f br/backup-pod.yaml -n emart
$ kubectl get pods -n emart

NAME                                            READY     STATUS    RESTARTS   AGE
backup-node                                     1/1       Running   0          3d1h
cbdemo-0000                                     1/1       Running   0          7d1h
cbdemo-0001                                     1/1       Running   0          7d1h
cbdemo-0002                                     1/1       Running   0          7d1h
cbdemo-0003                                     1/1       Running   0          7d1h
cbdemo-0004                                     1/1       Running   0          7d1h
couchbase-operator-7654d844cb-gn4bw             1/1       Running   0          7d2h
couchbase-operator-admission-7ff868f54c-5pklx   1/1       Running   0          7d2h

Quando o nó de backup estiver em execução, poderemos fazer login nesse pod:

$ kubectl exec -it backup-node -n emart -- /bin/bash

root@backup-node:/

E executar Lista cbbackupmgr para visualizar os backups existentes:

# cbbackupmgr list --repo couchbase --archive /backups

Size      Items          Name
256.04MB  -              + couchbase
0B        -                  + 2020-01-30T04_17_12.702824188Z
0B        -                      + gamesim-sample
0B        0                          analytics.json
0B        0                          + data
0B        0                              Error: no data shards were found
0B        0                          full-text.json
0B        0                          gsi.json
0B        0                          views.json
128.02MB  -                  + 2020-01-30T04_18_13.021340423Z
....

E você também pode executar cbbackupmgr restore manualmente:

# cbbackupmgr restore --archive /backups --repo couchbase --cluster couchbase://cbdemo-srv.emart.svc --username Administrator --password password

Quando terminar de restaurar, basta excluir o pod:

$ kubectl delete -f backup-pod.yaml -n emart

7. Conclusão

Explicamos passo a passo como é possível configurar um cronjob de backup, que automatiza o processo de fazer o backup periódico em um intervalo predefinido. Usamos um backup-com-periodic-merge.sh que executa a) backup, b) compactação e c) mesclagem em um único script. Esse script foi então usado no periodic-backup.yaml que automatizou o processo de fazer backup no ambiente do Kubernetes. Esperamos que você use as práticas recomendadas descritas neste blog e planeje fazer backups regulares, bem como validar esses backups usando o comando restore regularmente.