e-backup

Presentación

e-backup admite respaldo y restauración de clústeres. Realiza copias de respaldo de los datos de las aplicaciones y los datos de servicio en OBS y proporciona copias de respaldo de datos locales y remotos.

Restricciones

• No agregue, elimine ni modifique el clúster durante la copia de respaldo/restauración. De lo contrario, la copia de respaldo/restauración puede fallar o quedar incompleta.
• Si cambia el clúster, se recomienda esperar 15 minutos hasta que el clúster esté estable y, a continuación, realizar la operación de copia de respaldo.
• Cuando se utilizan instantáneas de disco de EVS para la copia de respaldo, solo se admiten los PV de EVS y se aplican las restricciones de instantáneas (por ejemplo, no se admite la restauración entre las AZ). Los precios son los mismos que los de las instantáneas de disco de EVS.
• Cuando se utiliza restic para la copia de respaldo, los datos de EVS, SFS, SFS Turbo y PV de OBS se copian y se cargan en el repositorio de copia de respaldo de OBS.
• restic crea una instantánea para los datos en el punto de tiempo de copia de respaldo y carga los datos, lo que no afecta a la lectura y escritura de datos posteriores. Sin embargo, restic no verifica el contenido del archivo y la coherencia del servicio. Se aplican restricciones de restricción.
• La memoria ocupada por restic está relacionada con el tamaño de los datos de PV respaldados por primera vez. Si el tamaño de los datos es superior a 500 GB, se recomienda utilizar los métodos de migración proporcionados por los servicios de almacenamiento en la nube. Si utiliza este complemento, puede modificar las cuotas de recursos del contenedor estérico haciendo referencia a la guía de operaciones.
• Puede utilizar Hooks para garantizar la coherencia de los datos de servicio para las aplicaciones con estado durante la copia de respaldo, por ejemplo, sincronizar los datos de memoria con los archivos.
• Durante la restauración, puede ajustar las configuraciones para adaptarse a las diferencias del entorno antes y después de la migración.
  • Una aplicación se puede restaurar desde el espacio de nombres original a otro espacio de nombres especificado. Sin embargo, debe confirmar que no se accede a la aplicación con un Service fijo durante la restauración.
  • Puede cambiar la dirección de la imagen (repo) de la aplicación a otra ruta de la imagen. El nombre y la etiqueta de la imagen permanecen sin cambios durante la restauración.
  • Puede cambiar el nombre de la clase de almacenamiento utilizada por la aplicación a una nueva. Tenga en cuenta que los recursos de almacenamiento de backend deben ser del mismo tipo, por ejemplo, desde el almacenamiento de bloques hasta el almacenamiento de bloques.
• Se aplican restricciones de Velero y de restic. Por ejemplo, durante la restauración, el Service borrará ClusterIP para adaptarse mejor a las diferencias entre los clústeres de Kubernetes de origen y destino.

Instalación del complemento

1. Inicie sesión en la consola de CCE. En el panel de navegación, elija Add-ons. Localice el complemento de copia de respaldo electrónica y haga clic en Install.
2. En la página Install Add-on, seleccione el clúster, defina los parámetros y haga clic en Install.

   Se admite el siguiente parámetro:

   volumeWorkerNum: número de trabajos de copia de respaldo de volúmenes simultáneos. El valor predeterminado es 3.

Uso del complemento

e-backup utiliza los bucket de OBS como ubicación de almacenamiento de copia de respaldo. Antes de realizar una copia de respaldo de los datos, debe realizar operaciones de Preparación de claves y Creación de una ubicación de almacenamiento.

Las copias de respaldo pueden ser inmediatas y programadas. Las restauraciones pueden ser inmediatas.

Preparación de claves

1. Obtenga una clave de acceso.

   Inicie sesión en la consola de CCE, mueva el cursor al nombre de usuario en la esquina superior derecha y elija My Credentials. En el panel de navegación de la izquierda, elija Access Keys. En la página que se muestra, haga clic en Add Access Key.

2. Cree un archivo de clave y lo formatee en una cadena usando Base64.

   # Create a key file.
   $ vi credential-for-huawei-obs
   HUAWEI_CLOUD_ACCESS_KEY_ID=your_access_key
   HUAWEI_CLOUD_SECRET_ACCESS_KEY=your_secret_key
   
   # Use Base64 to format the string.
   $ base64 -w 0 credential-for-huawei-obs
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS

3. Cree un secreto.
   Cree un secreto utilizando el siguiente contenido de YAML:

   apiVersion: v1
   kind: Secret
   metadata:
     labels:
       secret.everest.io/backup: 'true'   #Indicates that the secret is used by e-backup to access the backup storage location.
     name: secret-secure-opaque
     namespace: velero                  # The value must be velero. The secret must be in the same namespace as e-backup.
   type: cfe/secure-opaque
   data:
     # String obtained after the credential file is Base64-encoded.
     cloud: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS

   • El secreto debe estar en el mismo espacio de nombres que el e-backup, es decir, velero.
   • secret.data almacena el secreto para acceder a OBS. La clave debe ser cloud y el valor es la cadena codificada en Base64 de 2. En general, la cadena codificada en Base64 que se muestra contiene saltos de línea. Al escribir la cadena en secret.data debe eliminarlos manualmente.
   • El secreto debe estar etiquetado como secret.everest.io/backup: true, lo que indica que el secreto se utiliza para gestionar la ubicación de almacenamiento de copia de respaldo.

Creación de una ubicación de almacenamiento

Cree un objeto de recurso de Kubernetes utilizado por e-backup como ubicación de almacenamiento de copia de respaldo para obtener y detectar información sobre OBS de backend.

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: backup-location-001
  namespace: velero            # The object must be in the same namespace as e-backup.
spec:
  config:
    endpoint: obs.{regionname}.myhuaweicloud.com   # OBS endpoint
  credential:
    name: secret-secure-opaque   # Name of the created secret
    key: cloud                   # Key in secret.data
  objectStorage:
    bucket: tools-cce        # OBS bucket name
    prefix: for-backup       #Subpath name
  provider: huawei           # Uses the OBS service.

• El campo prefix es opcional y otros campos son obligatorios. El valor de provider se fija en huawei.
• Puede obtener el punto de conexión de Regiones y puntos de conexión. Asegúrese de que todos los nodos del clúster puedan acceder al punto de conexión. Si el punto de conexión no lleva una cabecera de protocolo (http o https), se utiliza https por defecto.
• Establezca correctamente name y key en la credencial. De lo contrario, la copia de respaldo electrónica no puede acceder a la ubicación de almacenamiento.

Una vez completada la creación, espere 30 segundos para comprobar y sincronizar la ubicación de almacenamiento de copia de respaldo. A continuación, compruebe si PHASE es de tipo Available. La ubicación solo está disponible cuando el valor es Available.

$ kubectl get backupstoragelocations.velero.io backup-location-001 -n velero 
NAME                  PHASE       LAST VALIDATED   AGE   DEFAULT
backup-location-001   Available   23s              23m  

Si PHASE no es Available durante mucho tiempo, puede ver los logs de copia de respaldo electrónica para localizar el fallo. Una vez instalada la copia de respaldo electrónica, se crea una carga de trabajo llamada velero en el espacio de nombres velero que se registra en los logs de velero.

Copia de respaldo inmediata

El proceso de copia de respaldo se inicia inmediatamente y se detiene al finalizar. Este modo se utiliza comúnmente para la clonación y la migración.

Puede usar el manifiesto de copia de respaldo que aparece a continuación y ejecutar kubectl create para crear una tarea de copia de respaldo.

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: backup-01
  namespace: velero
spec:
  includedNamespaces:
  - nginx
  - mysql
  labelSelector:
    matchExpressions:
    - key: direction
      operator: In
      values:
      - back
      - front
    matchLabels:
      app: nginx
      backup: velero
  runMode: Normal
  appData:
    volumes: Restic
  hooks:
    resources:
    - name: hook01
      includedNamespaces:
      - nginx
      labelSelector: {}
      pre:
      - exec:
          command:
          - /bin/sh
          - -c
          - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: container-0
          onError: Fail
          timeout: 30s
      post:
      - exec:
          command:
          - /bin/sh
          - -c
          - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: container-0
          onError: Fail
          timeout: 30s
  storageLocation: backup-location-001
  ttl: 720h0m0s

Descripción de parámetros:

• Parámetros de copia de respaldo
  • storageLocation: (obligatorio) nombre de la ubicación de almacenamiento de copia de respaldo donde se almacenan los datos que se van a hacer copia de respaldo.
  • ttl: duración para almacenar las copias de respaldo en la ubicación, después de la cual se eliminan las copias de respaldo. El valor debe estar en el formato especificado. h, m y s indican hora, minuto y segundo, respectivamente. Por ejemplo, 24h indica un día, y 3h4m5s indica tres horas, cuatro minutos y cinco segundos. El valor predeterminado es 30 días (720h0m0s).
• Filtrado de recursos: los siguientes parámetros se utilizan como filtros. La intersección de estos campos, si todos están configurados, se utiliza para filtrar todos los recursos del clúster.
  • includedNamespaces y excludedNamespaces: si se deben realizar copias de respaldo de los recursos en ciertos espacios de nombres. Estos dos parámetros entran en conflicto entre sí. Elija uno para configurar. De forma predeterminada, todos los espacios de nombres están seleccionados.
  • labelSelector: hace copias de respaldo de los recursos con etiquetas específicas. El principio de funcionamiento es el mismo que en Kubernetes.
  • runMode: (obligatorio) modo de copia de respaldo. Las opciones de valor incluyen Normal (copia de respaldo de aplicaciones y datos), AppOnly (solo copia de respaldo de aplicaciones), DataOnly (solo copia de respaldo de datos) y DryRun (no copia de respaldo de aplicaciones y datos; solo para verificación).
• Respaldo de datos de Service: los datos de servicio generados se pueden respaldar con copias instantáneas siempre (soportado solo cuando los EVS PVs como los volúmenes de datos) y backups restic (que respaldan todos los volúmenes de datos excepto los hostPath). Estos dos modos se pueden usar juntos.
  • appData: Modo de copia de seguridad de datos de PV. El valor puede ser Restic o Snapshot (no se usa por defecto). El modo Snapshot solo tiene efecto cuando el almacenamiento admite instantáneas y el complemento de instantáneas de CSI se despliega en el clúster.
• hook: Los ganchos son los comandos ejecutados antes o después de una copia de respaldo para gestionar con precisión sus copias de respaldo. Un hook es similar al comando kubectl exec y solo se aplica a pods.
  • includedNamespaces y excludedNamespaces: si se debe ejecutar un gancho en los pods en ciertos espacios de nombres. Estos dos parámetros entran en conflicto entre sí. Elija uno para configurar. De forma predeterminada, todos los espacios de nombres están seleccionados.
  • labelSelector: ejecuta un gancho en los pods con ciertas etiquetas. El principio de funcionamiento es el mismo que en Kubernetes.
  • command: comando a ejecutar.
  • contenedor: nombre del contenedor en el que se ejecuta el comando. El valor predeterminado es el primer contenedor cuando hay varios contenedores en el pod.
  • onError: acción a realizar cuando el gancho no se ejecuta. El valor puede ser Continue o Fail. El valor predeterminado es Fail.
  • Continue indica que las operaciones subsiguientes continúan independientemente de los fallos de ejecución de gancho. Fail indica que las operaciones posteriores no continuarán cuando se produzca un error de ejecución de gancho.
  • timeout: tiempo de espera de ejecución del gancho, después del cual el gancho falla. El valor predeterminado es 30s.

  Las fallas del gancho afectan solo a los pods. La copia de respaldo de otros objetos como los Services no se ve afectada.

  Los ganchos no están disponibles en todo el mundo. Si el pod para ejecutar un gancho no está seleccionado como el objeto de copia de respaldo, el gancho no se ejecutará. Se puede considerar que se filtran más los objetos a los que se va a realizar una copia de respaldo con includedNamespaces o excludedNamespaces.

Todos los elementos configurables se describen anteriormente. A continuación se proporcionan algunas sugerencias de configuración de copia de respaldo.

• Conservar las copias de respaldo por día (24 horas).
• Utilizar includeNamespace para especificar el ámbito de copia de respaldo, ya que en la mayoría de los casos, las aplicaciones se despliegan en un espacio de nombres específico. Utilizar labelSelector si necesita controlar los objetos de copia de respaldo con mayor precisión. Antes de esto, todos los objetos de destino deben tener etiquetas correspondientes. Usar includeNamespace y labelSelector juntos puede satisfacer la mayoría de los escenarios.
• Al usar Restic para hacer una copia de respaldo de los datos del servicio, si no está familiarizado con el modo OUT/IN, puede omitir agregar anotaciones a los pods que requieren una copia de respaldo de volumen. En su lugar, establezca defaultVolumesToRestic en true para hacer una copia de respaldo de los datos de servicio de los volúmenes de pod. El valor false indica que no hay copias de respaldo.
• Utilizar ganchos para controlar con precisión sus copias de respaldo. Evitar las tareas que se ejecutan durante mucho tiempo. No operar directamente el sistema de archivos cuando ejecutar los comandos en el gancho.

Copia de seguridad periódica

Se realiza una copia de respaldo de los datos periódicamente según lo configurado. Este modo se utiliza comúnmente para la recuperación ante desastres.

Puede usar el manifiesto de planificación que aparece a continuación y ejecutar el comando kubectl create para crear una planificación. Puede etiquetar la programación según sea necesario. Las etiquetas que agregue en el manifiesto se adjuntarán a las copias de respaldo creadas por la programación. Después de crear una programación en un clúster, se realiza una copia de respaldo inmediatamente. A continuación, se realiza una copia de respaldo de los datos periódicamente según se especifica.

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: schedule-backup-001
  namespace: velero
spec:
  schedule: 0 */10 * * *
  template:
    runMode: Normal
    hooks: {}
    includedNamespaces:
    - nginx
    - mysql
    labelSelector:
      matchExpressions:
      - key: direction
        operator: In
        values:
        - back
        - front
      matchLabels:
        app: nginx
        backup: velero
    storageLocation: backup-location-001
    ttl: 720h0m0s

Descripción de parámetros:

• schedule: tiempo de ejecución de copias de respaldo periódicas. El formato @every y las expresiones cron estándar de Linux son compatibles.
  • @every NUnit: N es un entero positivo. Las unidades s, m o h permanecen en reposo durante segundos, minutos y horas, respectivamente. Por ejemplo, @every 2h30m indica que la copia de respaldo se activa cada 2 horas y 30 minutos.
  • Expresión de Cron: Los cinco valores representan minutos, horas, día del mes, mes y día de la semana, respectivamente.
• template: manifiesto de copia de respaldo, que es el mismo que spec de Copia de respaldo inmediata.

Eliminación de una copia de seguridad

Puede eliminar los objetos de copia de respaldo y los objetos relacionados (como copias de respaldo, restauraciones y programaciones) de un clúster y eliminar las copias de respaldo de la ubicación de almacenamiento cuando se genera una gran cantidad de datos de copia de respaldo.

Puede usar el manifiesto DeleteBackupRequest a continuación y ejecutar el comando kubectl create para crear una solicitud de eliminación de copia de respaldo.

apiVersion: velero.io/v1
kind: DeleteBackupRequest
metadata:
  name: backup-001-delete
  namespace: velero
spec:
  backupName: backup-001  # Name of the backup to be deleted.

Consulte el estado.

$ kubectl -n velero get deletebackuprequests backup-001-delete -o yaml | grep " phase"
   phase: InProgress

• InProgress: La tarea de eliminación está en curso.
• Processed: Se ha procesado la tarea de eliminación.

• El estado Processed indica que la copia de respaldo electrónica ha procesado la tarea pero puede que no la complete. Puede comprobar los errores en el campo deletebackuprequest.status.errors. Si e-backup procesa correcta y completamente la tarea de eliminación, también se elimina el objeto DeleteBackupRequest.
• No elimine manualmente el contenido en la ubicación de almacenamiento (bucket de OBS).

Restauración inmediata

Utilice una copia de respaldo inmediata como origen de datos y restaure los datos en otro espacio de nombres o clúster. Este modo se aplica a todos los escenarios.

Puede utilizar el manifiesto Restore a continuación y ejecutar el comando kubectl create para crear una solicitud de eliminación de copia de respaldo.

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: restore-01
  namespace: velero
spec:
  backupName: backup-01
  hooks:
    resources:
    - name: restore-hook-1
      includedNamespaces:
      - mysql
      labelSelector: {}
      postHooks:
      - init:
          initContainers:
          - name: restore-hook-init1
            image: alpine:latest
            volumeMounts:
            - mountPath: /restores/pvc1-vm
              name: pvc1-vm
            command:
            - /bin/ash
            - -c
            - echo -n "FOOBARBAZ" >> /restores/pvc1-vm/foobarbaz
          - name: restore-hook-init2
            image: alpine:latest
            volumeMounts:
            - mountPath: /restores/pvc2-vm
              name: pvc2-vm
            command:
            - /bin/ash
            - -c
            - echo -n "DEADFEED" >> /restores/pvc2-vm/deadfeed
      - exec:
          execTimeout: 1m
          waitTimeout: 5m
          onError: Fail
          container: mysql
          command:
          - /bin/bash
          - '-c'
          - 'while ! mysql_isready; do sleep 1; done'
      - exec:
          container: mysql
          waitTimeout: 6m
          execTimeout: 1m
          onError: Continue
          command:
          - /bin/bash
          - '-c'
          - 'mysql < /backup/backup.sql'
  includedNamespaces:
  - nginx
  - mysql
  namespaceMapping:
    nginx: nginx-another
    mysql: mysql-another
  labelSelector: {}
  preserveNodePorts: false
  storageClassMapping:
    disk: csi-disk
    obs: csi-obs
  imageRepositoryMapping:
    quay.io/coreos:  swr.ap-southeast-1.myhuaweicloud.com/everest

Descripción de parámetros:

• Fuente de datos

  backupName: (obligatorio) copia de respaldo inmediata que se utiliza como origen de datos.

• Parámetros de filtrado de recursos: similares a los de Copia de respaldo inmediata.
• Procesamiento personalizado
  • namespaceMapping: restaura los datos de copia de respaldo en otro espacio de nombres. El valor es una asignación en el formato de Source: Target. No es necesario que el nuevo espacio de nombres exista en el clúster de destino.
  • storageClassMapping: cambia el storageClassName usado por los recursos de copia de respaldo como PV y PVC. Los tipos storageClass deben ser los mismos.
  • imageRepositoryMapping: cambia el campo images de la copia de respaldo. Se utiliza para la asignación de repositorios, excluidos el cambio del nombre de la imagen y la etiqueta (para evitar que la migración y la actualización se acoplen). Por ejemplo, después de migrar quay.io/coreos/etcd:2.5 a SWR, puede usar swr.ap-southeast-1.myhuaweicloud.com/everest/etcd:2.5 en el repositorio de imágenes local. El formato de configuración es el siguiente: quay.io/coreos: swr.ap-southeast-1.myhuaweicloud.com/everest
  • preserveNodePorts: Si establece este parámetro en false, el sistema conservará únicamente los nodePorts configurados, no los generados automáticamente por el Service.
• hooks: Puede agregar ganchos de inicio (usados para agregar initContainers al pod) y ganchos exec (usados para ejecutar algunos comandos). Para obtener más información sobre cómo configurar un gancho de inicio, consulte la definición de initContainers en Kubernetes. A continuación se describe la configuración general del gancho y los parámetros de un gancho exec.
  • includedNamespaces y excludedNamespaces: si se debe ejecutar un gancho en los pods en ciertos espacios de nombres. Estos dos parámetros entran en conflicto entre sí. Elija uno para configurar. De forma predeterminada, todos los espacios de nombres están seleccionados.
  • labelSelector: ejecuta un gancho en los pods con ciertas etiquetas. El principio de funcionamiento es el mismo que en Kubernetes.
  • command: comando a ejecutar.
  • contenedor: nombre del contenedor en el que se ejecuta el comando. El valor predeterminado es el primer contenedor cuando hay varios contenedores en el pod.
  • onError: acción a realizar cuando el gancho no se ejecuta. El valor puede ser Continue o Fail. El valor predeterminado es Fail.
  • Continue indica que las operaciones subsiguientes continúan independientemente de los fallos de ejecución de gancho. Fail indica que las operaciones posteriores no continuarán cuando se produzca un error de ejecución de gancho.
  • execTimeout: tiempo de espera de ejecución del gancho, después del cual el gancho falla. El valor predeterminado es 30s.
  • waitTimeout: período de tiempo de espera desde el momento en que e-backup se prepara para ejecutar el gancho hasta el momento en que el contenedor comienza a ejecutar el gancho. Si se excede este período, el gancho falla. El valor predeterminado es 0s, lo que indica que no hay límite de tiempo de espera.

• Seleccione un origen de datos correcto y asegúrese de que la copia de respaldo está en el estado Completed.
• Establezca los parámetros relacionados con el filtrado de recursos solo cuando sea necesario.
• Los datos de Service se restauran mediante una copia de respaldo electrónica basada en el modo de copia de respaldo seleccionado. No se requieren las configuraciones u operaciones manuales.
• Para obtener más información sobre cómo usar ganchos, consulte las sugerencias de uso de Immediate Backup. Puede omitir waitTimeout a menos que sea necesario.
• Se recomienda restaurar lo que se ha respaldado en un nuevo espacio de nombres para evitar configuraciones erróneas que pueden deshabilitar la aplicación restaurada.

Una vez completada la restauración, ejecute los siguientes comandos para ver el estado de restauración (status):

$ kubectl -n velero get restores restore-01 -o yaml | grep " phase"
  phase: Completed

$ kubectl -n velero get restores restore-01 -o yaml
......
status:
  ......

Descripción de estado

• FailedValidation: El manifiesto de restauración está configurado incorrectamente. Compruebe Restore.Status.ValidationErrors para encontrar la causa.
• InProgress: La restauración está en curso.
• Completed: La restauración está completa y no se produce ningún error.
• PartiallyFailed: La restauración está completa, pero se produce un error (como un error de ejecución de gancho) durante la restauración de ciertos objetos.
• Failed: Se produce un error de restauración y se produce un error que afecta a todo el proceso.

Compruebe los registros, avisos y errores generados durante la restauración.

Suponga que el nombre de restauración es restore-01. Vaya a la consola de OBS, busque la ubicación de almacenamiento basada en el nombre del bucket configurado y el nombre de la subruta, y vaya al directorio restores/restore-01. Existen los dos archivos siguientes:

• restore-01-logs.gz: archivo de log, que se puede descargar, descomprimir y ver.
• restore-01-results.gz: archivo de resultado de restauración, incluidos los avisos y errores.

Historial de cambios