FAQ about the backup center - Container Service for Kubernetes - Centro de documentación de Alibaba Cloud

La mayoría de los problemas del centro de copias de seguridad corresponden a un mensaje de error específico en el estado del trabajo. Localice su mensaje a continuación para encontrar la causa y la solución. Si aún no tiene un mensaje de error, consulte Obtener detalles del error.

Comprender el estado del trabajo

Antes de solucionar problemas, comprenda qué significa cada estado. Un estado Completed no garantiza que todos los recursos se hayan procesado correctamente; revise siempre los campos Errors y Warnings.

Status	Meaning
Completed	El trabajo finalizó. Si faltan recursos en el clúster de restauración, revise el campo `Warnings`; es posible que algunos recursos se hayan excluido por configuración o que la lógica de negocio los haya reciclado.
PartiallyFailed	El trabajo se completó, pero no se pudieron procesar algunos recursos. Revise los campos `Errors` y `Warnings` en los detalles del trabajo.
Failed	El trabajo no se completó. Obtenga los detalles del error mediante los métodos descritos a continuación.
InProgress	El trabajo sigue ejecutándose. Si un trabajo permanece en este estado durante un periodo prolongado, consulte Why is my job stuck in InProgress?

Obtener detalles del error

Cuando un trabajo de copia de seguridad, una tarea de conversión de StorageClass o un trabajo de restauración muestra Failed o PartiallyFailed, utilice los siguientes métodos para obtener los detalles del error.

Vista rápida: Pase el cursor sobre Failed o PartiallyFailed en la columna Status para ver un breve mensaje de error, como RestoreError: snapshot cross region request failed.

Detalles completos del error: Ejecute el comando correspondiente a su tipo de tarea para ver todos los eventos, incluidos los mensajes de error detallados.

Trabajo de copia de seguridad:

kubectl -n csdr describe applicationbackup <backup-name>

Tarea de conversión de StorageClass:

kubectl -n csdr describe converttosnapshot <backup-name>

Trabajo de restauración:

kubectl -n csdr describe applicationrestore <restore-name>

Si utiliza el centro de copias de seguridad con kubectl, actualice el componente migrate-controller a la versión más reciente antes de solucionar problemas. Esto no afecta las copias de seguridad existentes. Para obtener más información, consulte Gestionar componentes .

Problemas de la consola

¿Por qué la consola muestra "The working component is abnormal" o "Failed to fetch current data"?

El componente del centro de copias de seguridad no se instaló correctamente. Compruebe lo siguiente:

Verifique que el clúster tenga nodos. El centro de copias de seguridad no se puede desplegar en un clúster sin nodos.
Si el clúster utiliza FlexVolume, cambie primero a CSI (Container Storage Interface). Consulte The migrate-controller component in a FlexVolume cluster cannot start.
Si utiliza kubectl, verifique que sus configuraciones YAML sean correctas. Consulte Usar kubectl para realizar copias de seguridad y restaurar aplicaciones.
Para clústeres dedicados de ACK y clústeres registrados, verifique que se hayan otorgado los permisos necesarios. Consulte Clúster dedicado de ACK y Clúster registrado.
Compruebe si los despliegues csdr-controller y csdr-velero en el namespace csdr fallaron debido a recursos insuficientes o restricciones de programación, y resuelva cualquier problema.

¿Por qué la consola muestra "The name has been used. Change the name and try again"?

Al eliminar una tarea, el sistema crea un recurso deleterequest en el clúster y ejecuta una serie de operaciones de eliminación, no solo la eliminación del recurso de copia de seguridad en sí. Si la eliminación falla o se interrumpe, algunos recursos pueden permanecer en el clúster con el mismo nombre, lo que provoca este error.

Ejecute el siguiente comando para eliminar el recurso en conflicto. Por ejemplo, si el error es deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists:

kubectl -n csdr delete deleterequests xxxxx-dbr

Después, cree la tarea con un nuevo nombre.

¿Por qué no puedo seleccionar una copia de seguridad existente al restaurar entre clústeres?

Una posible causa es que la bóveda de copias de seguridad no se ha inicializado en el clúster de destino. En la página Create Restoration Task, busque Backup Vaults y haga clic en Initialize Backup Vault. Una vez completada la inicialización, seleccione la copia de seguridad y proceda con la restauración.

Si la inicialización falla, el recurso backuplocation en el clúster de destino muestra un estado Unavailable. Ejecute el siguiente comando para comprobarlo:

kubectl get -n csdr backuplocation <backuplocation-name>

Salida esperada:

NAME                    PHASE       LAST VALIDATED   AGE
<backuplocation-name>   Available   3m36s            38m

Si el estado es Unavailable, consulte Why does my job fail with "VaultError: xxx"?

Si el estado de la bóveda de copias de seguridad es correcto, confirme en la consola del clúster de origen que el trabajo de copia de seguridad muestra Completed. Los trabajos de copia de seguridad fallidos o en curso no se pueden seleccionar para la restauración entre clústeres.

¿Por qué la consola muestra "The service role required by the current component has not been authorized" (AddonRoleNotAuthorized)?

A partir de migrate-controller 1.8.0, se actualizó la lógica de autenticación de recursos en la nube para clústeres administrados de ACK. La primera vez que instale o actualice a esta versión, la cuenta de Alibaba Cloud debe completar la autorización.

Si ha iniciado sesión con una cuenta de Alibaba Cloud, haga clic en Authorize.
Si ha iniciado sesión como usuario RAM, haga clic en Copy Authorization Link y envíelo al titular de la cuenta de Alibaba Cloud para que realice la autorización.

¿Por qué la consola muestra "The current account has not been granted the cluster RBAC permissions required for this operation" (APISERVER.403)?

La consola interactúa con el servidor API para enviar y supervisar trabajos de copia de seguridad y restauración. Los conjuntos de permisos predeterminados para ingenieros de O&M y desarrolladores carecen de algunos permisos que requiere el centro de copias de seguridad.

Otorgue los siguientes permisos de ClusterRole a los operadores del centro de copias de seguridad. Para obtener instrucciones, consulte Restrict resource operations in a cluster by using custom RBAC.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csdr-console
rules:
  - apiGroups: ["csdr.alibabacloud.com","velero.io"]
    resources: ['*']
    verbs: ["get","create","delete","update","patch","watch","list","deletecollection"]
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get","list"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get","list"]

¿Por qué falla la actualización o desinstalación del componente del centro de copias de seguridad y el namespace csdr permanece en Terminating?

El centro de copias de seguridad se cerró de forma anómala y dejó trabajos en estado InProgress. El campo finalizers de estos trabajos bloquea la eliminación de recursos.

Ejecute el siguiente comando para identificar qué está bloqueando el namespace:

kubectl describe ns csdr

Confirme que los trabajos atascados ya no son necesarios y elimine sus finalizers. Una vez eliminado el namespace csdr:

Para actualizaciones, reinstale el componente migrate-controller.
Para desinstalaciones, el componente ya se habrá eliminado.

Fallos generales de trabajos

¿Por qué mi trabajo falla con "internal error"?

El componente o un servicio subyacente en la nube encontró una excepción inesperada. Por ejemplo, es posible que el servicio en la nube no esté disponible en la región actual.

Si el error es HBR backup/restore internal error, revise la consola de Cloud Backup para verificar que la función de copia de seguridad de contenedores esté disponible en su región.

¿Por qué mi trabajo falla con "create cluster resources timeout"?

Durante una conversión de StorageClass o una restauración, el centro de copias de seguridad crea pods temporales, solicitudes de volumen persistente (PVC) y volúmenes persistentes (PV). Si estos recursos permanecen en un estado no disponible durante demasiado tiempo, se produce este error de tiempo de espera.

Identifique el recurso atascado:
```
kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>
```
Por ejemplo, una salida como wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out significa que el PVC demo-pvc-for-convert202311151045 en el namespace default no se está vinculando.

Compruebe el estado del PVC para encontrar la causa raíz:

kubectl -n default describe pvc demo-pvc-for-convert202311151045

Las causas comunes incluyen:

Recursos insuficientes en el clúster o en los nodos.
Al clúster de restauración le falta la clase de almacenamiento necesaria. Utilice la función de conversión de StorageClass para seleccionar una clase de almacenamiento disponible antes de restaurar.
El almacenamiento subyacente de la clase de almacenamiento no está disponible; por ejemplo, el tipo de disco especificado no es compatible con la zona actual.
El Container Network File System (CNFS) asociado con alibabacloud-cnfs-nas presenta anomalías. Consulte Method 3: Use an existing NAS file system.
Se seleccionó una clase de almacenamiento con volumeBindingMode: Immediate en un clúster multizona.

Para obtener orientación sobre la solución de problemas de almacenamiento, consulte Troubleshoot storage issues.

¿Por qué mi trabajo falla con "addon status is abnormal"?

Los componentes en el namespace csdr presentan anomalías. Compruebe su estado:

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

Para conocer los pasos de resolución, consulte Why is my job stuck in InProgress?

¿Por qué mi trabajo falla con "VaultError: xxx"?

Este error indica que la bóveda de copias de seguridad no puede acceder al bucket de Object Storage Service (OSS). Realice las siguientes comprobaciones en orden.

1. Verifique que el bucket de OSS exista.

Inicie sesión en la consola de OSS y confirme que existe el bucket asociado con la bóveda de copias de seguridad. Si no existe, cree un nuevo bucket y vuelva a asociarlo. Consulte Crear buckets.

Importante

No puede crear una bóveda de copias de seguridad con el mismo nombre que una eliminada, ni asociar una bóveda con un bucket de OSS cuyo nombre no siga el formato cnfs-oss-*. Si tiene una bóveda existente asociada con un bucket con nombre incorrecto, cree una nueva bóveda con un nombre diferente y asóciela con un bucket cnfs-oss-*.

2. Verifique los permisos de acceso a OSS.

Los pasos necesarios dependen del tipo de clúster:

Clústeres ACK Pro: No se necesita configuración de permisos de OSS si el nombre del bucket de OSS comienza con cnfs-oss-.
Clústeres dedicados de ACK y clústeres registrados: Configure los permisos de OSS como se describe en Install migrate-controller and configure permissions.
Clústeres administrados de ACK: Si el componente se instaló o actualizó a la versión 1.8.0 o posterior fuera de la consola, ejecute el siguiente comando para comprobar si los permisos de OSS están configurados:
```
kubectl get secret -n kube-system | grep addon.aliyuncsmanagedbackuprestorerole.token
```
Salida esperada:
```
addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d
```
Si la salida coincide, los permisos están configurados. De lo contrario, otorgue permisos mediante uno de los siguientes métodos:
- Siga las instrucciones para clústeres dedicados de ACK y clústeres registrados. Consulte Install migrate-controller and configure permissions.
- Haga clic en Authorize para autorizar su cuenta de Alibaba Cloud. Solo necesita hacer esto una vez por cuenta.

3. Compruebe la configuración de red.

kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network

network: internal — la bóveda accede a OSS a través de la red interna.
network: public — la bóveda accede a OSS a través de Internet. Si esto causa un tiempo de espera, verifique que el clúster pueda acceder a Internet. Consulte Enable Internet access for an existing ACK cluster.

La bóveda de copias de seguridad debe usar acceso por red pública en estos escenarios:

El clúster y el bucket de OSS están en diferentes regiones.
El clúster es un clúster ACK Edge.
El clúster es un clúster registrado que no está conectado a una VPC mediante Cloud Enterprise Network (CEN), Express Connect o VPN, o no se ha configurado una ruta hacia el bloque CIDR interno de OSS de la región. En este caso, configure una ruta hacia el bloque CIDR interno de OSS de la región.
- Para obtener información sobre cómo conectar un centro de datos local a una VPC, consulte Combine multiple connection methods to build an enterprise-class hybrid cloud.
- Para conocer la asignación entre endpoints internos de OSS y bloques CIDR VIP, consulte Access OSS via endpoints and bucket domains.

Para cambiar al acceso por red pública, ejecute:

kubectl patch -n csdr backuplocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'
kubectl patch -n csdr backupstoragelocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'

Reemplace <region-id> con la región del bucket de OSS, como cn-hangzhou.

¿Por qué mi trabajo falla con "HBRError: check HBR vault error"?

Cloud Backup no está activado o carece de los permisos necesarios.

Active el servicio Cloud Backup. Consulte Activar Cloud Backup.
Para clústeres en China (Ulanqab), China (Heyuan) o China (Guangzhou), autorice también a Cloud Backup para acceder a API Gateway después de la activación. Consulte (Optional) Step 3: Grant Cloud Backup permission to use API Gateway.
Para clústeres dedicados de ACK y clústeres registrados, verifique que se hayan otorgado los permisos de RAM (Resource Access Management) de Cloud Backup. Consulte Install migrate-controller and configure permissions.

¿Por qué mi trabajo falla con "HBRError: ... code: 400, Illegal request. Please modify the parameters"?

Se eliminó el repositorio ack-backup-data de Cloud Backup en la región.

Cuando crea una copia de seguridad en una región por primera vez, el centro de copias de seguridad crea automáticamente un repositorio ack-backup-data para almacenar las copias de seguridad. Si se elimina este repositorio, los trabajos posteriores fallarán con este error.

Importante

Después de eliminar el repositorio, no se pueden restaurar las copias de seguridad creadas antes de la eliminación. Los siguientes pasos solo crean un nuevo repositorio para futuras copias de seguridad.

En todos los clústeres que utilizan el centro de copias de seguridad en la región afectada, borre los registros de la bóveda de copias de seguridad:
```
kubectl -ncsdr delete backuplocation --all
kubectl -ncsdr delete backupstoragelocation --all
```
Regrese al clúster y cree una nueva copia de seguridad. El componente crea automáticamente un nuevo repositorio ack-backup-data y lo asocia con la bóveda de copias de seguridad.

¿Por qué mi trabajo falla con "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist"?

El cliente de Cloud Backup (el DaemonSet hbr-client) en un nodo del namespace csdr no se está ejecutando correctamente.

Compruebe si hay pods hbr-client anómalos:
```
kubectl -n csdr get pod -lapp=hbr-client
```
Si algún pod se encuentra en un estado anómalo, compruebe si la causa es la insuficiencia de direcciones IP, memoria o CPU para los pods. Para los pods en estado CrashLoopBackOff, consulte los registros:
```
kubectl -n csdr logs -p <hbr-client-pod-name>
```
Si los registros contienen SDKError: StatusCode: 403, Code: MagpieBridgeSlrNotExist, siga (Optional) Step 3: Grant API Gateway permissions to Cloud Backup para otorgar los permisos necesarios.
Para otros errores de SDK, utilice el código de error EC para solucionar el problema. Consulte Self-help troubleshooting by using error codes.

¿Por qué mi trabajo se queda atascado en InProgress?

Causa 1: Componentes anómalos en el namespace csdr

Compruebe si los componentes se están reiniciando o si no logran iniciarse:

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

Si la causa es falta de memoria (OOM):

Si el pod afectado es csdr-velero-* y su clúster de restauración ejecuta muchos namespaces de producción, la caché Informer de Velero podría estar consumiendo demasiada memoria. Para deshabilitarla, agregue --disable-informer-cache=true a los argumentos de migrate-controller:

Deshabilitar la caché Informer reduce el uso de memoria, pero puede afectar el rendimiento del trabajo. Supervise el rendimiento del trabajo después de realizar este cambio.
```
kubectl -nkube-system edit deploy migrate-controller
```
Agregue el parámetro a los args del contenedor:
```
name: migrate-controller
args:
  - --disable-informer-cache=true
```

Para aumentar el límite de memoria sin deshabilitar la caché, ejecute:

kubectl patch deploy <deploy-name> -n csdr -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container-name>","resources":{"limits":{"memory":"<new-limit-memory>"}}}]}}}}'

Utilice csdr-controller para los pods csdr-controller-* y csdr-velero para los pods csdr-velero-*.

Si la causa es la falta de permisos de Cloud Backup:

Confirme que Cloud Backup esté activado. Si no lo está, actívelo en Cloud Backup.
Para clústeres dedicados de ACK y clústeres registrados, confirme que los permisos de Cloud Backup estén configurados. Consulte Instalar migrate-controller y otorgar permisos.
Compruebe si existe el token requerido por el cliente de Cloud Backup:

Describa el pod hbr-client:
```
kubectl describe pod <hbr-client-***> -n csdr
```
Si los eventos muestran couldn't find key HBR_TOKEN, falta el token. Para restaurarlo, realice los siguientes pasos:
1. Encuentre el nodo donde se ejecuta hbr-client-*:
```
kubectl get pod <hbr-client-***> -n csdr -owide
```
2. Cambie la etiqueta del nodo de true a false:
```
kubectl label node <node-name> csdr.alibabacloud.com/agent-enable=false --overwrite
```
Importante
El token se recrea automáticamente la próxima vez que ejecute una copia de seguridad o restauración. Si copia un token de otro clúster, el hbr-client iniciado no estará activo. Elimine el token copiado y el pod hbr-client-* asociado, y luego repita los pasos anteriores.

Causa 2: Permisos de instantáneas de disco no configurados

Si una aplicación tiene volúmenes de disco montados y el trabajo de copia de seguridad permanece en InProgress, compruebe los recursos VolumeSnapshot:

kubectl get volumesnapshot -n <backup-namespace>

Si el campo READYTOUSE permanece como false para todos los VolumeSnapshots, compruebe lo siguiente:

En la consola de ECS, verifique que la función de instantáneas de disco esté habilitada en la región. Si no lo está, habilítela. Consulte Habilitar instantáneas.
Compruebe que el pod del aprovisionador CSI se esté ejecutando:
```
kubectl -nkube-system get pod -l app=csi-provisioner
```

Verifique que los permisos de instantáneas de disco estén configurados. Los pasos dependen del tipo de clúster:

Clústeres administrados de ACK: En la consola de RAM, compruebe que la política AliyunCSManagedBackupRestoreRole incluya permisos para las acciones hbr:*, ecs:CreateSnapshot y oss:* en acs:oss:*:*:cnfs-oss*. Si falta el rol, vaya a la página de Autorización rápida de RAM para otorgarlo. La política requerida es:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "hbr:CreateVault",
        "hbr:CreateBackupJob",
        "hbr:DescribeVaults",
        "hbr:DescribeBackupJobs2",
        "hbr:DescribeRestoreJobs",
        "hbr:SearchHistoricalSnapshots",
        "hbr:CreateRestoreJob",
        "hbr:AddContainerCluster",
        "hbr:DescribeContainerCluster",
        "hbr:CancelBackupJob",
        "hbr:CancelRestoreJob",
        "hbr:DescribeRestoreJobs2"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecs:CreateSnapshot",
        "ecs:DeleteSnapshot",
        "ecs:DescribeSnapshotGroups",
        "ecs:CreateAutoSnapshotPolicy",
        "ecs:ApplyAutoSnapshotPolicy",
        "ecs:CancelAutoSnapshotPolicy",
        "ecs:DeleteAutoSnapshotPolicy",
        "ecs:DescribeAutoSnapshotPolicyEX",
        "ecs:ModifyAutoSnapshotPolicyEx",
        "ecs:DescribeSnapshots",
        "ecs:DescribeInstances",
        "ecs:CopySnapshot",
        "ecs:CreateSnapshotGroup",
        "ecs:DeleteSnapshotGroup"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:PutObject",
        "oss:GetObject",
        "oss:DeleteObject",
        "oss:GetBucket",
        "oss:ListObjects",
        "oss:ListBuckets",
        "oss:GetBucketStat"
      ],
      "Resource": "acs:oss:*:*:cnfs-oss*"
    }
  ],
  "Version": "1"
}

Clústeres dedicados de ACK: En la consola de ACK, vaya a la página Cluster Information del clúster, busque Master RAM Role y compruebe la pestaña Permission Management. Si la política k8sMasterRolePolicy-Csi-* falta o está incompleta, otorgue la misma política mostrada arriba al rol Master RAM.
Clústeres registrados: Solo los clústeres registrados cuyos nodos son instancias de Elastic Compute Service (ECS) de Alibaba Cloud pueden utilizar la función de instantáneas de disco. Compruebe si se configuraron los permisos necesarios cuando instaló el complemento de almacenamiento CSI. Consulte Configurar permisos de RAM para el componente CSI.

Causa 3: Tipo de volumen que no es de disco

La restauración entre regiones solo es compatible con volúmenes de disco (migrate-controller 1.7.7 y posteriores). Para otros tipos de volúmenes, si utiliza un servicio de almacenamiento compatible con acceso a Internet (como OSS), cree un PV y un PVC aprovisionados estáticamente y restaure la aplicación sin conversión de StorageClass. Consulte Usar un volumen aprovisionado estáticamente con ossfs 1.0.

Fallos de copias de seguridad

¿Por qué mi copia de seguridad falla con "backup already exists in OSS bucket"?

Ya existe una copia de seguridad con el mismo nombre en el bucket de OSS asociado con la bóveda de copias de seguridad. Recree la bóveda de copias de seguridad con un nuevo nombre.

Una copia de seguridad puede ser invisible en el clúster actual por varias razones: pertenece a un trabajo en curso o fallido (que no se sincronizan entre clústeres), se eliminó en un clúster diferente (el archivo está marcado pero no se eliminó de OSS), o el clúster actual no está asociado con la bóveda que la almacenó.

¿Por qué mi copia de seguridad falla con "get target namespace failed"?

Esto suele ocurrir en trabajos de copia de seguridad programados. La selección de namespaces no es válida:

Si seleccionó Include, todos los namespaces seleccionados se han eliminado.
Si seleccionó Exclude, el clúster no tiene otros namespaces aparte de los excluidos.

Actualice el plan de copia de seguridad para corregir la selección de namespaces.

¿Por qué mi copia de seguridad falla con "velero backup process timeout"?

Dos causas comunes:

Clase de almacenamiento del bucket de OSS: Si la clase de almacenamiento del bucket es Archive, Cold Archive o Deep Cold Archive, el centro de copias de seguridad no puede actualizar los archivos de metadatos (los archivos archivados deben restaurarse primero). Cambie la clase de almacenamiento del bucket a Standard. Para mantener los datos de copia de seguridad en la clase de almacenamiento Archive, configure una regla de ciclo de vida para convertir automáticamente la clase de almacenamiento y descongele los datos archivados antes de las operaciones de restauración. Consulte Convertir clases de almacenamiento.

Tiempo de espera de subtarea: El tiempo de espera predeterminado para las subtareas de copia de seguridad es de 60 minutos (migrate-controller 1.7.7 y posteriores). Si su clúster tiene muchos recursos o el servidor API tiene alta latencia, aumente este valor en el ConfigMap csdr-config:

kubectl edit -n csdr cm csdr-config

Agregue velero_timeout_minutes a la sección applicationBackup. Por ejemplo, para establecer un tiempo de espera de 100 minutos:

apiVersion: v1
data:
  applicationBackup: |
    ...
    velero_timeout_minutes: 100

Reinicie el controlador para que el cambio surta efecto:

kubectl -n csdr delete pod -l control-plane=csdr-controller

¿Por qué mi copia de seguridad falla con "HBR backup request failed"?

Tres causas posibles:

Complemento de almacenamiento incompatible: Si su clúster utiliza un complemento de almacenamiento CSI que no es de Alibaba Cloud, o si el PV no es un tipo de volumen estándar de Kubernetes (como NFS o LocalVolume), envíe un ticket para obtener asistencia.

Volumen en modo Block: Cloud Backup no admite volúmenes cuyo VolumeMode es Block. Si su clúster utiliza CSI, se usan instantáneas de disco para la copia de seguridad de datos de forma predeterminada, y las instantáneas de disco admiten volúmenes en modo Block. Si el tipo de complemento de almacenamiento es incorrecto, cambie a CSI, reinstale el componente de copia de seguridad y ejecute la copia de seguridad nuevamente.

Problema con el cliente de Cloud Backup: Para volúmenes de sistema de archivos (OSS, NAS, CPFS o local), el cliente de Cloud Backup puede haber agotado el tiempo de espera o haber fallado. Para investigar:

Inicie sesión en la consola de Cloud Backup.
Vaya a Backup > Container Backup y haga clic en la pestaña Backup Jobs.
Seleccione la región en la barra de navegación superior.
Seleccione Job Name en la lista desplegable frente al cuadro de búsqueda, luego busque <backup-name>-hbr para ver el estado del trabajo y el motivo del fallo. Consulte Realizar copias de seguridad de clústeres ACK.

Para consultar una conversión de StorageClass o un trabajo de copia de seguridad, busque por el nombre de la copia de seguridad.

¿Por qué mi copia de seguridad falla con "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST"?

Para CSI de terceros o tipos de almacenamiento autogestionados (NFS, Ceph):

El centro de copias de seguridad utiliza la ruta de montaje de volumen estándar de Kubernetes como ruta de copia de seguridad de datos. Para CSI estándar, la ruta predeterminada es /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Si se ha cambiado la ruta raíz de kubelet en su clúster, es posible que Cloud Backup no encuentre los datos.

Inicie sesión en el nodo donde está montado el volumen y solucione el problema:

Encuentre la ruta raíz de kubelet:
```
ps -elf | grep kubelet
```
Interprete la salida de la siguiente manera:
- Si el comando de inicio incluye --root-dir, ese valor es la ruta raíz de kubelet.
- Si el comando de inicio incluye --config, compruebe el campo root-dir en el archivo de configuración.
- Si ninguno de los parámetros está presente, compruebe /etc/systemd/system/kubelet.service en busca de una referencia EnvironmentFile, y luego revise ese archivo para buscar ROOT_DIR.
- Si no se encuentra nada de lo anterior, la ruta raíz de kubelet es la predeterminada: /var/lib/kubelet.
Compruebe si la ruta raíz es un enlace simbólico:
```
ls -al <root-dir>
```
Si la salida muestra algo como kubelet -> /var/lib/container/kubelet, la ruta raíz real es /var/lib/container/kubelet.
Confirme que los datos del volumen de destino existen bajo la ruta raíz en <root-dir>/pods/<pod-uid>/volumes.
Establezca la variable de entorno KUBELET_ROOT_PATH en el despliegue csdr/csdr-controller con la ruta raíz real de kubelet.

Para almacenamiento HostPath:

HostPath no crea una ruta de montaje bajo la ruta raíz de kubelet. El componente de copia de seguridad no puede leer datos de la ruta del nodo de forma predeterminada. Envíe un ticket para obtener asistencia.

¿Por qué mi copia de seguridad falla con los mensajes "check backup files in OSS bucket failed", "upload backup files to OSS bucket failed" o "download backup files from OSS bucket failed"?

El servidor OSS devolvió un error durante una operación de archivo en el bucket de la bóveda de copias de seguridad. Existen tres causas posibles:

Faltan permisos de KMS: Si habilitó el cifrado del lado del servidor con una clave maestra de cliente (CMK) de Key Management Service (KMS) en el bucket de OSS, el centro de copias de seguridad requiere permisos adicionales. Consulte ¿El centro de copias de seguridad admite el cifrado KMS para el bucket de OSS asociado?.

Permisos de OSS incompletos: Para clústeres dedicados de ACK y clústeres registrados, revise la política de permisos del usuario RAM utilizado durante la instalación del componente. Consulte Paso 1: Configurar permisos.

Credenciales de autenticación revocadas: Para clústeres dedicados de ACK y clústeres registrados, confirme que las credenciales de autenticación del usuario RAM sigan siendo válidas. Si fueron revocadas, obtenga nuevas credenciales, actualice el Secret alibaba-addon-secret en el namespace csdr y reinicie el componente:

kubectl -nkube-system delete pod -lapp=migrate-controller

¿Por qué mi copia de seguridad muestra PartiallyFailed con el mensaje "PROCESS velero partially completed"?

Algunos recursos del clúster no se pudieron respaldar correctamente. Ejecute el siguiente comando para identificar qué recursos fallaron y por qué:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name>

Revise los campos Errors y Warnings en la salida y corrija los problemas. Para obtener registros adicionales:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero backup logs <backup-name>

¿Por qué mi copia de seguridad muestra PartiallyFailed con el mensaje "PROCESS hbr partially completed"?

Cloud Backup no logró respaldar algunos volúmenes del sistema de archivos (OSS, NAS, CPFS o volúmenes locales). Esto puede deberse a lo siguiente:

El plugin de almacenamiento que utilizan algunos volúmenes no es compatible.
Se eliminaron archivos durante la copia de seguridad, lo que provocó un fallo de consistencia.

Para investigar, abra la pestaña Backup Jobs en la consola de Cloud Backup, seleccione la región correcta, elija Job Name en la lista desplegable junto al cuadro de búsqueda y busque <backup-name>-hbr. Revise el estado del trabajo y el motivo del fallo. Consulte Realizar copias de seguridad de clústeres ACK.

Fallos en la conversión de StorageClass

¿Por qué falla la conversión de StorageClass con el mensaje "storageclass xxx not exists"?

La clase de almacenamiento de destino seleccionada para la conversión no existe en el clúster actual.

Restablezca la tarea de conversión de StorageClass:

cat << EOF | kubectl apply -f -
apiVersion: csdr.alibabacloud.com/v1beta1
kind: DeleteRequest
metadata:
  name: reset-convert
  namespace: csdr
spec:
  deleteObjectName: "<backup-name>"
  deleteObjectType: "Convert"
EOF

Cree la clase de almacenamiento requerida en el clúster.
Ejecute nuevamente el trabajo de restauración con la conversión de StorageClass configurada.

¿Por qué falla la conversión de StorageClass con el mensaje "only support convert to storageclass with CSI diskplugin or nasplugin provisioner"?

La conversión de StorageClass solo admite como destino tipos de volúmenes de disco CSI y NAS de Alibaba Cloud. Para otros requisitos, envíe un ticket.

Si utiliza un servicio de almacenamiento compatible con acceso por red pública (como OSS), cree un PV y PVC aprovisionados estáticamente y restaure la aplicación sin realizar la conversión de StorageClass. Consulte Uso de un volumen aprovisionado estáticamente con ossfs 1.0.

¿Por qué falla la conversión de StorageClass con el mensaje "current cluster is multi-zoned"?

En un clúster multizona, si convierte a una StorageClass de tipo disco cuyo volumeBindingMode es Immediate, CSI crea el PV en una zona fija. Los pods no se pueden programar en una zona diferente, por lo que quedan en estado Pending.

Restablezca la tarea de conversión de StorageClass (utilice el mismo comando que se indicó anteriormente).
Seleccione la clase de almacenamiento correcta:
- Consola: Seleccione alicloud-disk, que utiliza la clase de almacenamiento alicloud-disk-topology-alltype de forma predeterminada.
- Línea de comandos: Utilice alicloud-disk-topology-alltype. Alternativamente, establezca volumeBindingMode en WaitForFirstConsumer para garantizar que el PV se cree en la misma zona que el pod.
Ejecute nuevamente el trabajo de restauración.

Fallos de restauración

¿Por qué falla mi restauración con el mensaje "multi-node writing is only supported for block volume"?

La aplicación que se va a restaurar tiene un volumen cuyo AccessMode es ReadWriteMany o ReadOnlyMany. Al restaurar en almacenamiento de disco de Alibaba Cloud (que no admite múltiples montajes de forma predeterminada), CSI valida la configuración de AccessModes de los volúmenes de disco durante el montaje y bloquea la operación. Esto evita que el disco sea montado por otro nodo durante el proceso, lo cual provocaría una desconexión forzada del disco.

Esto ocurre en tres escenarios:

Versión anterior de CSI o FlexVolume en el clúster de respaldo: Las versiones anteriores de CSI no verificaban AccessModes durante el montaje. El volumen falla cuando se restaura en un clúster con una versión más reciente de CSI. A partir de la v1.8.4, el componente de copia de seguridad convierte automáticamente los AccessModes de los volúmenes de disco a ReadWriteOnce. Actualice el componente y vuelva a intentar la restauración.
Falta la clase de almacenamiento en el clúster de restauración: El volumen se asocia de forma predeterminada a un volumen de disco de Alibaba Cloud. Restaurar automáticamente la clase de almacenamiento puede causar inaccesibilidad o sobrescritura de datos. Cree una clase de almacenamiento con el mismo nombre en el clúster de restauración antes de proceder, o utilice la conversión de StorageClass para especificar el destino.
Conversión manual de StorageClass a disco: Agregue el parámetro convertToAccessModes para convertir AccessModes a ReadWriteOnce. Consulte convertToAccessModes.

¿Por qué falla mi restauración con el mensaje "only disk type PVs support cross-region restore in current version"?

La restauración entre regiones solo es compatible con volúmenes de disco (migrate-controller 1.7.7 y posteriores). Para otros tipos de almacenamiento que admiten acceso a Internet (como OSS), cree un PV y PVC aprovisionados estáticamente y restaure la aplicación. Consulte Uso de un volumen aprovisionado estáticamente con ossfs 1.0.

¿Por qué falla mi restauración con el mensaje "ECS snapshot cross region request failed"?

La restauración entre regiones para volúmenes de disco requiere permisos de instantáneas de disco de ECS, los cuales no se otorgan de forma predeterminada para todos los tipos de clúster.

Para clústeres dedicados de ACK y clústeres registrados conectados a Kubernetes autoadministrado desplegado en instancias ECS, otorgue los permisos de instantáneas de disco de ECS. Consulte Clúster registrado.

¿Por qué falla mi restauración con el mensaje "accessMode of PVC xxx is xxx"?

El volumen de disco que se está restaurando tiene un AccessMode de ReadOnlyMany o ReadWriteMany. CSI aplica las siguientes reglas:

Solo los volúmenes con multiAttach habilitado pueden montarse en múltiples instancias.
Los volúmenes con VolumeMode: Filesystem (ext4 o xfs) solo pueden montarse en múltiples instancias en modo de solo lectura.

Se recomiendan dos enfoques:

Si está convirtiendo un volumen de montaje múltiple (como OSS o NAS) a almacenamiento de disco, cree un nuevo trabajo de restauración y seleccione alibabacloud-cnfs-nas como destino para la conversión de StorageClass. Esto utiliza un volumen NAS administrado por CNFS, que admite múltiples montajes. Consulte Uso de CNFS para administrar sistemas de archivos NAS (recomendado).
Si el PV de disco respaldado no cumple con los requisitos actuales de CSI (respaldado cuando la versión de CSI era anterior y no se aplicaba la detección de AccessMode), migre sus cargas de trabajo para usar volúmenes de disco aprovisionados dinámicamente y evitar la desconexión forzada de discos durante la programación.

El estado de mi restauración es Completed, pero faltan algunos recursos. ¿Por qué?

Un estado Completed no garantiza que se hayan restaurado todos los recursos. Compruebe cada posible causa:

El recurso no se incluyó en la copia de seguridad. Ejecute el siguiente comando para inspeccionar la copia de seguridad:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --details

Los recursos a nivel de clúster de los pods que se ejecutan en namespaces no seleccionados para la copia de seguridad no se respaldan de forma predeterminada. Para la configuración de copias de seguridad a nivel de clúster, consulte Copia de seguridad a nivel de clúster.

El recurso se excluyó durante la restauración. Verifique si el namespace, el tipo de recurso u otros filtros en el trabajo de restauración excluyeron el recurso, y vuelva a ejecutar la restauración.

La subtarea de restauración falló parcialmente. Ejecute el siguiente comando para identificar los fallos:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe restore <restore-name>

Corrija los problemas indicados en los campos Errors y Warnings.

El recurso se recicló después de su creación. Revise los registros de auditoría del recurso para determinar si se eliminó después de crearse, debido a ownerReferences o a la lógica de negocio.

Otras preguntas

El componente migrate-controller en un clúster FlexVolume no puede iniciarse

El componente migrate-controller no es compatible con clústeres FlexVolume. Migre a CSI antes de utilizar el centro de copias de seguridad:

Migración de FlexVolume a CSI mediante el componente csi-compatible-controller
Migración de FlexVolume sin clúster de almacenamiento a CSI
Migración de volúmenes NAS aprovisionados estáticamente de FlexVolume a CSI
Migración de volúmenes OSS aprovisionados estáticamente de FlexVolume a CSI
Para otros casos, contáctenos en el grupo de DingTalk (ID: 35532895).

Para respaldar aplicaciones en un clúster FlexVolume y restaurarlas en un clúster CSI durante la migración, consulte Uso del centro de copias de seguridad para migrar aplicaciones en un clúster de Kubernetes que ejecuta una versión anterior.

¿Puedo modificar una bóveda de copias de seguridad?

No. Para realizar cambios, elimine la bóveda de copias de seguridad actual y cree una nueva con un nombre diferente.

Dado que una bóveda de copias de seguridad es un recurso compartido que puede estar en uso activo en cualquier momento, modificar sus parámetros conlleva el riesgo de inaccesibilidad de los datos durante las operaciones de copia de seguridad o restauración en curso. Tampoco es posible crear una nueva bóveda con el mismo nombre que una eliminada previamente.

¿Puedo usar un bucket de OSS cuyo nombre no siga el formato `cnfs-oss-*`?

Para clústeres distintos a los clústeres dedicados de ACK y los clústeres registrados, el centro de copias de seguridad tiene acceso de lectura y escritura a buckets de OSS con nombres en formato cnfs-oss-* de forma predeterminada. El uso de un bucket con un nombre diferente requiere configuración adicional. Para evitar que las copias de seguridad sobrescriban datos existentes en un bucket, cree un bucket de OSS dedicado con el formato cnfs-oss-* para el centro de copias de seguridad.

Configure los permisos de OSS para el componente. Consulte Clúster dedicado de ACK.

Reinicie el componente del servicio de copia de seguridad:

kubectl -n csdr delete pod -l control-plane=csdr-controller
kubectl -n csdr delete pod -l component=csdr

Después de crear una bóveda con un nombre de bucket no estándar, espere a que finalice la verificación de conectividad (aproximadamente cinco minutos) antes de iniciar operaciones de copia de seguridad o restauración. Compruebe el estado de la bóveda:

kubectl -n csdr get backuplocation

Salida esperada:

NAME                    PHASE       LAST VALIDATED   AGE
a-test-backuplocation   Available   7s               6d1h

¿Cómo especifico la programación de copias de seguridad al crear un plan de respaldo?

La programación de copias de seguridad admite dos formatos:

Expresión Cron: Por ejemplo, 1 4 * * * ejecuta una copia de seguridad a las 4:01 AM todos los días.
Intervalo: Por ejemplo, 6h30m ejecuta una copia de seguridad cada 6 horas y 30 minutos.

Referencia del formato Cron:

 *  *  *  *  *
 |  |  |  |  |
 |  |  |  |  ·----- day of week (0 - 6, Sun to Sat)
 |  |  |  ·-------- month (1 - 12)
 |  |  .----------- day of month (1 - 31)
 |  ·-------------- hour (0 - 23)
 ·----------------- minute (0 - 59)

Ejemplo: 0 2 15 * 1 ejecuta una copia de seguridad a las 2:00 AM el día 15 de cada mes.

¿Qué cambios realiza un trabajo de restauración en los recursos YAML respaldados?

Los trabajos de restauración realizan los siguientes ajustes automáticos:

Tamaño del volumen de disco: Si un volumen de disco es menor a 20 GiB, el tamaño se incrementa a 20 GiB.

Servicios: Se restauran según el tipo de Service:

Services NodePort: Los puertos de servicio se conservan de forma predeterminada durante la restauración entre clústeres.
Services LoadBalancer:
- Cuando ExternalTrafficPolicy es Local, HealthCheckNodePort utiliza un puerto aleatorio. Para conservar el puerto original, establezca spec.preserveNodePorts: true en el trabajo de restauración.
- Si el Service utiliza una instancia existente de Server Load Balancer (SLB) del clúster de respaldo, el Service restaurado usa la misma instancia de SLB pero deshabilita sus listeners. Configure los listeners en la consola de SLB.
- Si la instancia de SLB es administrada por Cloud Controller Manager (CCM) en el clúster de respaldo, CCM crea una nueva instancia de SLB. Consulte Consideraciones para configurar un Service LoadBalancer.

¿Cómo consulto los recursos incluidos en una copia de seguridad?

Copias de seguridad de aplicaciones del clúster:

Ejecute en un clúster que tenga sincronizados los archivos de copia de seguridad:

kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1
kubectl -n csdr exec -it csdr-velero-xxx -c velero -- ./velero describe backup <backup-name> --details

O bien utilice la consola de ACK: vaya a su clúster > Operations > Application Backup > Backup Records, luego haga clic en un registro de copia de seguridad.

Copias de seguridad de volúmenes de disco:

En la consola de ECS, vaya a Storage & Snapshots > Snapshots y consulte las instantáneas por ID de disco.

Copias de seguridad de volúmenes que no son de disco:

En la consola de Cloud Backup, vaya a Backup > Container Backup y seleccione la región. La pestaña Clusters enumera los clústeres respaldados y sus PVC. La pestaña Backup Jobs muestra el estado de los trabajos.

Si Client Status es anómalo, Cloud Backup no se está ejecutando correctamente en el clúster ACK. Vaya a la página de DaemonSets en la consola de ACK para solucionar el problema.

¿Puedo respaldar desde una versión anterior de Kubernetes y restaurar en una versión más reciente?

Sí. De forma predeterminada, se respaldan todas las versiones de API compatibles con un recurso. Por ejemplo, un Deployment en Kubernetes 1.16 admite extensions/v1beta1, apps/v1beta1, apps/v1beta2 y apps/v1. Las cuatro versiones se almacenan en la bóveda de copias de seguridad independientemente de cuál se usó para crearlo. La función KubernetesConvert gestiona la conversión de versiones de API durante la restauración.

Al restaurar, se utiliza la versión de API recomendada por el clúster de destino. Por ejemplo, al restaurar en Kubernetes 1.28 se usa apps/v1 para Deployments.

Importante

Si no hay ninguna versión de API compartida entre los clústeres de origen y destino, despliegue el recurso manualmente. Por ejemplo, los Ingresses en clústeres de Kubernetes 1.16 usan extensions/v1beta1 y networking.k8s.io/v1beta1, que no son compatibles con Kubernetes 1.22 y posteriores (solo se admite networking.k8s.io/v1). Para detalles sobre la migración de versiones de API, consulte la guía de obsolescencia de Kubernetes. Evite migrar de versiones más recientes de Kubernetes a versiones anteriores, y evite migrar de versiones anteriores a la 1.16 a versiones más recientes.

¿El tráfico se cambia automáticamente a las instancias de SLB durante la restauración?

No. Después de la restauración, los listeners de SLB se deshabilitan o se crea una nueva instancia de SLB (dependiendo de la configuración original). El tráfico no se cambia automáticamente.

Si utiliza otros mecanismos de descubrimiento de servicios y desea controlar cuándo se cambia el tráfico, excluya los recursos Service durante la copia de seguridad y despliéguelos manualmente cuando esté listo para realizar el cambio.

¿Por qué los recursos en csdr, ack-csi-fuse, kube-system, kube-public y kube-node-lease no se respaldan de forma predeterminada?

csdr: Es el namespace propio del centro de copias de seguridad. Respaldarlo directamente provocaría fallos en los componentes del clúster de restauración. La sincronización de copias de seguridad se gestiona automáticamente; no necesita migrar las copias de seguridad manualmente.
ack-csi-fuse: Este namespace ejecuta pods de cliente FUSE mantenidos por CSI. El CSI del nuevo clúster sincroniza automáticamente estos clientes durante la restauración del almacenamiento.
kube-system, kube-public, kube-node-lease: Son namespaces del sistema de Kubernetes. Debido a diferencias en los parámetros y configuraciones del clúster, no se admite la restauración de estos namespaces entre clústeres. Respaldar directamente componentes del sistema de kube-system en un nuevo clúster puede provocar su mal funcionamiento. Antes de ejecutar un trabajo de restauración, instale y configure manualmente los componentes del sistema en el clúster de restauración; por ejemplo, el componente de extracción de imágenes sin contraseña de Container Registry (acr-configuration) y el componente ALB Ingress (ALBConfig).

¿El centro de copias de seguridad utiliza instantáneas de disco de ECS para los volúmenes de disco? ¿Cuál es el tipo de instantánea predeterminado?

El centro de copias de seguridad utiliza instantáneas de disco de ECS de forma predeterminada en los siguientes escenarios:

El clúster es un clúster administrado o dedicado de ACK.
El clúster ejecuta Kubernetes 1.18 o posterior y utiliza CSI 1.18 o posterior.

En otros escenarios, se utiliza Cloud Backup para la copia de seguridad de datos de disco.

Las instantáneas de disco de ECS creadas por el centro de copias de seguridad tienen habilitada la función de acceso instantáneo de forma predeterminada. El período de validez de la instantánea coincide con el período de validez especificado en la configuración de copia de seguridad. A partir del 12 de octubre de 2023, 11:00, Alibaba Cloud ya no cobra por el almacenamiento ni las operaciones de acceso instantáneo a instantáneas en ninguna región. Consulte Uso de la función de acceso instantáneo.

¿Por qué el período de validez de la instantánea de disco de ECS es diferente al que especifiqué en la configuración de copia de seguridad?

La configuración del período de validez depende del componente csi-provisioner. Si csi-provisioner es anterior a la versión 1.20.6, las VolumeSnapshots se crean sin la configuración de período de validez o acceso instantáneo, por lo que la configuración de copia de seguridad no afecta a las instantáneas de disco.

Actualice csi-provisioner a la versión 1.20.6 o posterior para garantizar que el período de validez se aplique correctamente.

Si no es posible actualizar, configure un período de validez de instantánea predeterminado en su lugar:

Actualice migrate-controller a la v1.7.10 o posterior.
Compruebe si existe una VolumeSnapshotClass con la configuración de retención de 30 días:
```
kubectl get volumesnapshotclass csdr-disk-snapshot-with-default-ttl
```

Si no existe, o si existe pero retentionDays no está establecido en 30, aplique lo siguiente:

apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Retain
driver: diskplugin.csi.alibabacloud.com
kind: VolumeSnapshotClass
metadata:
  name: csdr-disk-snapshot-with-default-ttl
parameters:
  retentionDays: "30"

Todas las copias de seguridad de volúmenes de disco en el clúster crearán entonces instantáneas con el período de retención establecido en retentionDays.

¿Qué es la copia de seguridad de datos de volumen y cuándo la necesito?

Qué hace: La copia de seguridad de datos de volumen copia los datos del volumen al almacenamiento en la nube mediante instantáneas de disco de ECS o Cloud Backup. Cuando restaura la aplicación, se crea un nuevo disco o sistema de archivos NAS a partir de esta copia. La aplicación restaurada y la aplicación original tienen datos independientes; los cambios en una no afectan a la otra.

Si no necesita una copia de los datos ni una fuente de datos compartida, puede omitir la copia de seguridad de datos de volumen. Los archivos YAML de PVC y PV aún se incluyen en la copia de seguridad de la aplicación de forma predeterminada. Asegúrese de que los recursos PVC y PV no estén en la lista de exclusión de copias de seguridad para que, durante la restauración, los volúmenes se desplieguen en el nuevo clúster a partir de su YAML original.

Cuándo utilizarla:

Se requiere recuperación ante desastres o registros de datos versionados.
La aplicación utiliza volúmenes de disco (los discos básicos solo pueden montarse en un único nodo).
Se requiere copia de seguridad y restauración entre regiones (la mayoría de los tipos de almacenamiento, excepto OSS, no admiten acceso entre regiones).
Se requiere aislamiento de datos entre la aplicación original y la restaurada.
Los plugins de almacenamiento o las versiones difieren significativamente entre los clústeres de respaldo y restauración, lo que hace impráctica la restauración directa mediante YAML.

Riesgos de no respaldar volúmenes para aplicaciones con estado:

Volúmenes con una política de reclamación Delete****: CSI crea un PV nuevo y vacío durante la restauración. Los volúmenes aprovisionados estáticamente sin una clase de almacenamiento coincidente permanecen en estado Pending hasta que cree manualmente un PV o una clase de almacenamiento.
Volúmenes con una política de reclamación Retain****: Los recursos se restauran en orden de prioridad PV primero. Para almacenamiento de montaje múltiple (NAS, OSS), se reutiliza el sistema de archivos o bucket original. Para discos, existe el riesgo de desconexión forzada del disco.

Para comprobar la política de reclamación de sus volúmenes:

kubectl get pv -o=custom-columns=CLAIM:.spec.claimRef.name,NAMESPACE:.spec.claimRef.namespace,NAME:.metadata.name,RECLAIMPOLICY:.spec.persistentVolumeReclaimPolicy

¿Cómo selecciono nodos para copias de seguridad de sistemas de archivos en protección de datos?

De forma predeterminada, los trabajos de Cloud Backup pueden ejecutarse en cualquier nodo, excepto en nodos virtuales. Solo se ejecuta un trabajo de copia de seguridad de volumen por nodo a la vez.

Hay tres políticas de programación de nodos disponibles:

Policy	Behavior
`exclude` (predeterminado)	Todos los nodos son elegibles. Agregue `csdr.alibabacloud.com/agent-excluded="true"` para excluir nodos específicos.
`include`	Solo los nodos etiquetados son elegibles. Agregue `csdr.alibabacloud.com/agent-included="true"` para habilitar nodos específicos.
`prefer`	Todos los nodos son elegibles. Se prefieren los nodos con `csdr.alibabacloud.com/agent-included="true"`; los nodos con `csdr.alibabacloud.com/agent-excluded="true"` se utilizan al final.

Para etiquetar un nodo:

# Exclude a node
kubectl label node <node-name> csdr.alibabacloud.com/agent-excluded="true"

# Include a node (for the include policy)
kubectl label node <node-name> csdr.alibabacloud.com/agent-included="true"

Para cambiar la política, edite el ConfigMap csdr-config:

kubectl -n csdr edit cm csdr-config

Agregue node_schedule_policy a la sección applicationBackup:

apiVersion: v1
data:
  applicationBackup: |
    backup_max_worker_num: 15
    restore_max_worker_num: 5
    delete_max_worker_num: 30
    schedule_max_worker_num: 20
    convert_max_worker_num: 15
    node_schedule_policy: include  # Valid values: include, exclude, prefer
  pvBackup: |
    batch_snapshot_max_num: 20
    enable_ecs_snapshot: "true"
kind: ConfigMap

Reinicie el controlador para que el cambio surta efecto:

kubectl -n csdr delete pod -lapp=csdr-controller

¿Cuáles son las diferencias entre la copia de seguridad de aplicaciones y la protección de datos?

La copia de seguridad de aplicaciones respalda cargas de trabajo de Kubernetes, incluidas aplicaciones, Services y archivos de configuración en namespaces. Opcionalmente, incluya datos de volumen para los volúmenes montados. Utilice la copia de seguridad de aplicaciones para migrar aplicaciones entre clústeres o restaurar aplicaciones para recuperación ante desastres.

La copia de seguridad de aplicaciones no respalda volúmenes que no están montados en pods. Para respaldar todos los volúmenes, cree trabajos de copia de seguridad de protección de datos.

La protección de datos respalda volúmenes de almacenamiento (PVC y PV) independientemente de las cargas de trabajo de la aplicación. Utilice la protección de datos para restaurar un PVC eliminado como una operación independiente, o para implementar replicación de datos y recuperación ante desastres en la capa de almacenamiento.

¿Cómo excluyo volúmenes persistentes específicos de la copia de seguridad y la recuperación?

Algunos volúmenes, como el almacenamiento de registros o el almacenamiento de alta disponibilidad (OSS), no necesitan ser respaldados. A continuación se presenta un flujo de trabajo para respaldar un namespace que contiene el Volumen A (no requiere copia de seguridad) y el Volumen B (requiere copia de seguridad):

Flujo de copia de seguridad:

Utilice protección de datos para respaldar el Volumen B; esto respalda tanto el YAML como los datos.
Utilice copia de seguridad de aplicaciones para seleccionar el namespace con Volume Backup establecido en Disable. Esto respalda los archivos YAML tanto del Volumen A como del Volumen B sin copiar datos.

Si no desea que el Volumen A se restaure en absoluto en el clúster de destino, agregue pvc, pv a Excluded Resources en la configuración avanzada.

Flujo de restauración:

Restaure la copia de seguridad de protección de datos en el clúster de destino. Esto restaura el YAML y los datos del Volumen B.
Restaure la copia de seguridad de la aplicación en el clúster de destino. Esto restaura el YAML del Volumen A y todos los demás recursos de la aplicación. Luego, CSI crea una nueva fuente de almacenamiento o reutiliza la existente según la política de reclamación del Volumen A.

Una vez completadas ambas restauraciones, la aplicación, el Volumen A y el Volumen B (con sus datos) estarán ejecutándose en el clúster de destino.

¿El centro de copias de seguridad admite el cifrado KMS para el bucket de OSS asociado?

El centro de copias de seguridad admite el cifrado del lado del servidor para buckets de OSS. Habilítelo en la consola de OSS. Consulte Cifrado del lado del servidor.

Si utiliza una CMK administrada por KMS (traiga su propia clave o BYOK) con un ID de CMK específico, otorgue al centro de copias de seguridad permisos para acceder a KMS:

Cree una política de permisos personalizada:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:List*",
        "kms:DescribeKey",
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": [
        "acs:kms:*:141661496593****:*"
      ]
    }
  ]
}

Esto otorga acceso a todas las claves KMS bajo la cuenta de Alibaba Cloud. Para un control de recursos más granular, consulte Información de autorización.

Adjunte la política:
- Para clústeres dedicados de ACK y clústeres registrados: adjúntela al usuario RAM utilizado durante la instalación. Consulte Otorgar permisos a un usuario RAM.
- Para otros clústeres: adjúntela al rol AliyunCSManagedBackupRestoreRole. Consulte Otorgar permisos a un rol RAM.

Si utiliza una clave KMS administrada por OSS o una clave totalmente administrada por OSS, no se necesitan permisos adicionales.

¿Cómo cambio las imágenes de contenedor utilizadas durante la restauración?

Cambiar la dirección del registro de imágenes:

Para despliegues en nube híbrida o migraciones de entornos locales a la nube, utilice el campo imageRegistryMapping para reasignar las direcciones del registro de imágenes. Por ejemplo, para cambiar docker.io/library/ a registry.cn-beijing.aliyuncs.com/my-registry/:

docker.io/library/: registry.cn-beijing.aliyuncs.com/my-registry/

Cambiar el repositorio o la versión de la imagen:

Cree un ConfigMap en el namespace csdr antes de ejecutar la restauración:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <configuration-name>
  namespace: csdr
  labels:
    velero.io/plugin-config: ""
    velero.io/change-image-name: RestoreItemAction
data:
  "case1": "app1:v1,app2:v2"
  # Change only the repository: "case1": "app1,app2"
  # Change only the version: "case1": "v1:v2"
  # Change a specific registry image: "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

Para múltiples cambios, agregue case2, case3, y así sucesivamente al campo data. Después de crear el ConfigMap, ejecute el trabajo de restauración dejando el campo imageRegistryMapping en blanco.

Estos cambios se aplican a todos los trabajos de restauración en el clúster. Utilice patrones específicos (como limitar a un registro en particular) para evitar cambios no deseados. Elimine el ConfigMap cuando ya no sea necesario.

¿Cómo ajusto los recursos disponibles para los subcomponentes en el namespace csdr?

La configuración de recursos predeterminada de csdr-controller es:

resources:
  limits:
    cpu: "1"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

La configuración de recursos predeterminada de csdr-velero es:

resources:
  limits:
    cpu: "1"
    memory: 2Gi
  requests:
    cpu: 500m
    memory: 128Mi

Las configuraciones de Deployment de csdr-controller y csdr-velero, incluidos sus recursos, son administradas por el componente migrate-controller en el namespace kube-system. Si se editan directamente, se restablecerán. Para cambiar la configuración de recursos, agregue los siguientes parámetros a los args del contenedor migrate-controller:

name: migrate-controller
args:
  - --velero-pod-cpu-limit=500m
  - --velero-pod-mem-limit=512Mi
  - --velero-pod-cpu-request=250m
  - --velero-pod-mem-request=256Mi
  - --csdr-pod-cpu-limit=500m
  - --csdr-pod-mem-limit=512Mi
  - --csdr-pod-cpu-request=250m
  - --csdr-pod-mem-request=256Mi

Cada parámetro es opcional. Los parámetros omitidos conservan sus valores predeterminados. Asegúrese de que cada límite sea mayor o igual a la solicitud correspondiente.

En clústeres grandes, reducir velero-pod-mem-limit puede provocar que csdr-velero se quede sin memoria durante la inicialización y la restauración. Considere configurar el parámetro disable-informer-cache en su lugar. Consulte Why is my job stuck in InProgress?

Comprender el estado del trabajo

Obtener detalles del error

Problemas de la consola

¿Por qué la consola muestra "The working component is abnormal" o "Failed to fetch current data"?

¿Por qué la consola muestra "The name has been used. Change the name and try again"?

¿Por qué no puedo seleccionar una copia de seguridad existente al restaurar entre clústeres?

¿Por qué la consola muestra "The service role required by the current component has not been authorized" (AddonRoleNotAuthorized)?

¿Por qué la consola muestra "The current account has not been granted the cluster RBAC permissions required for this operation" (APISERVER.403)?

¿Por qué falla la actualización o desinstalación del componente del centro de copias de seguridad y el namespace csdr permanece en Terminating?

Fallos generales de trabajos

¿Por qué mi trabajo falla con "internal error"?

¿Por qué mi trabajo falla con "create cluster resources timeout"?

¿Por qué mi trabajo falla con "addon status is abnormal"?

¿Por qué mi trabajo falla con "VaultError: xxx"?

¿Por qué mi trabajo falla con "HBRError: check HBR vault error"?

¿Por qué mi trabajo falla con "HBRError: ... code: 400, Illegal request. Please modify the parameters"?

¿Por qué mi trabajo falla con "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist"?

¿Por qué mi trabajo se queda atascado en InProgress?

Causa 1: Componentes anómalos en el namespace csdr

Si la causa es falta de memoria (OOM):

Si la causa es la falta de permisos de Cloud Backup:

Causa 2: Permisos de instantáneas de disco no configurados

Causa 3: Tipo de volumen que no es de disco

Fallos de copias de seguridad

¿Por qué mi copia de seguridad falla con "backup already exists in OSS bucket"?

¿Por qué mi copia de seguridad falla con "get target namespace failed"?

¿Por qué mi copia de seguridad falla con "velero backup process timeout"?

¿Por qué mi copia de seguridad falla con "HBR backup request failed"?

¿Por qué mi copia de seguridad falla con "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST"?

¿Por qué mi copia de seguridad falla con los mensajes "check backup files in OSS bucket failed", "upload backup files to OSS bucket failed" o "download backup files from OSS bucket failed"?

¿Por qué mi copia de seguridad muestra PartiallyFailed con el mensaje "PROCESS velero partially completed"?

¿Por qué mi copia de seguridad muestra PartiallyFailed con el mensaje "PROCESS hbr partially completed"?

Fallos en la conversión de StorageClass

¿Por qué falla la conversión de StorageClass con el mensaje "storageclass xxx not exists"?

¿Por qué falla la conversión de StorageClass con el mensaje "only support convert to storageclass with CSI diskplugin or nasplugin provisioner"?

¿Por qué falla la conversión de StorageClass con el mensaje "current cluster is multi-zoned"?

Fallos de restauración

¿Por qué falla mi restauración con el mensaje "multi-node writing is only supported for block volume"?

¿Por qué falla mi restauración con el mensaje "only disk type PVs support cross-region restore in current version"?

¿Por qué falla mi restauración con el mensaje "ECS snapshot cross region request failed"?

¿Por qué falla mi restauración con el mensaje "accessMode of PVC xxx is xxx"?

El estado de mi restauración es Completed, pero faltan algunos recursos. ¿Por qué?

Otras preguntas

El componente migrate-controller en un clúster FlexVolume no puede iniciarse

¿Puedo modificar una bóveda de copias de seguridad?

¿Puedo usar un bucket de OSS cuyo nombre no siga el formato cnfs-oss-*?

¿Cómo especifico la programación de copias de seguridad al crear un plan de respaldo?

¿Qué cambios realiza un trabajo de restauración en los recursos YAML respaldados?

¿Cómo consulto los recursos incluidos en una copia de seguridad?

¿Puedo respaldar desde una versión anterior de Kubernetes y restaurar en una versión más reciente?

¿El tráfico se cambia automáticamente a las instancias de SLB durante la restauración?

¿Por qué los recursos en csdr, ack-csi-fuse, kube-system, kube-public y kube-node-lease no se respaldan de forma predeterminada?

¿El centro de copias de seguridad utiliza instantáneas de disco de ECS para los volúmenes de disco? ¿Cuál es el tipo de instantánea predeterminado?

¿Por qué el período de validez de la instantánea de disco de ECS es diferente al que especifiqué en la configuración de copia de seguridad?

¿Qué es la copia de seguridad de datos de volumen y cuándo la necesito?

¿Cómo selecciono nodos para copias de seguridad de sistemas de archivos en protección de datos?

¿Cuáles son las diferencias entre la copia de seguridad de aplicaciones y la protección de datos?

¿Cómo excluyo volúmenes persistentes específicos de la copia de seguridad y la recuperación?

¿El centro de copias de seguridad admite el cifrado KMS para el bucket de OSS asociado?

¿Cómo cambio las imágenes de contenedor utilizadas durante la restauración?

¿Cómo ajusto los recursos disponibles para los subcomponentes en el namespace csdr?

¿Puedo usar un bucket de OSS cuyo nombre no siga el formato `cnfs-oss-*`?