Docs Menu
Docs Home
/ /

Solucionar problemas de fallos de copia de seguridad y restauración

Las operaciones de respaldo y restauración para las implementaciones gestionadas por Ops Manager pueden fallar por diversas razones, como problemas de conectividad del agente, limitaciones de espacio en disco o inconsistencias en el registro Oplog.

Esta página describe cómo confirmar los fallos de copia de seguridad y restauración, describe las causas y resoluciones habituales, y proporciona orientación sobre qué recopilar antes de contactar con soporte. Si el problema persiste después de completar los siguientes pasos, contacta Soporte técnico.

Antes de investigar la causa raíz de una falla de copia de seguridad o restauración, confirmar que se haya producido una falla revisando los indicadores de estado relevantes en la Interfaz de Usuario o API de Ops Manager.

Utiliza los siguientes métodos para confirmar que una tarea de copia de seguridad o un snapshot ha fallado.

Para confirmar si una snapshot falló:

1
  1. Haga clic Admin.

  2. Haga clic en Backups.

  3. Haga clic en Snapshots.

2
3

La columna muestra si el snapshot tuvo éxito, está en ejecución o falló.

También puede hacer clic en JSON junto a una instantánea para ver campos adicionales, que incluyen:

  • status

  • createdDate

  • completedDate

  • totalDuration

  • transferSpeed

Estos campos ayudan a confirmar si la copia de seguridad se completó correctamente.

Para obtener una descripción de todos los estados de snapshot, consulte Resumen de la copia de seguridad.

Para comprobar problemas con las tareas de copia de seguridad en curso:

1
  1. Haga clic en Admin.

  2. Haga clic en Backup.

  3. Haga clic en Jobs.

2
3

Campos como Last Snapshot, Last Oplog o Head Time pueden aparecer resaltados cuando se retrasa, lo que indica un problema con el proceso de copia de seguridad.

Para obtener más información, consulta Trabajos.

Para revisar mensajes de errores de tarea de copia de seguridad:

1
  1. Haga clic en Admin.

  2. Haga clic en Logs.

2

Los registros muestran mensajes de error agrupados por tiempo, lo que puede ayudar a diagnosticar por qué falló una tarea de copia de seguridad.

Ops Manager genera alertas que indican fallos o problemas con las tareas de copia de seguridad, incluyendo:

  • "La copia de seguridad ha alcanzado un alto número de reintentos"

  • "La copia de seguridad está en un estado inesperado"

  • "El set de réplicas tiene una snapshot tardía"

Para obtener una lista completa de condiciones de alerta relacionadas con las copias de seguridad, consulte Condiciones de alerta.

Para recuperar instantáneas que no se han completado, consulta la API de Ops Manager utilizando el parámetro de query completed=false:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Accept: application/json" \
"https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/snapshots?completed=false"

La respuesta incluye un arreglo results en la que cada objeto representa una instantánea. El campo complete indica si la snapshot finalizó correctamente.

Nota

La API de snapshots no proporciona un estado de falla nombrado. Es posible que una snapshot con complete: false aún esté en progreso o haya fallado.

Para obtener más información, consulta Obtener todas las instantáneas de un clúster.

Utiliza los siguientes métodos para confirmar que una tarea de restauración ha fallado.

Para ver el estado de los trabajos de restauración en la interfaz de usuario de Ops Manager:

1
2
3
4

La página Restores muestra una tabla de las últimas 300 tareas de restauración. Verifica la columna Status para identificar las tareas con los siguientes estados:

  • FAILED

  • CANCELED

  • IN_PROGRESS

  • FINISHED

Haz clic en una fila para ver más detalles sobre esa operación de restauración específica.

Para obtener más información, consulta Restauraciones.

Para recuperar tareas de restauración programáticamente, query la API de Ops Manager:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Accept: application/json" \
"https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/restoreJobs"

La respuesta incluye un results arreglo donde cada objeto representa una tarea de restauración. El campo statusName indica el estado de la tarea. Los valores posibles incluyen:

  • FINISHED

  • IN_PROGRESS

  • BROKEN

  • KILLED

Restaurar tareas con un statusName de BROKEN o KILLED se consideran fallidos.

Para filtrar tareas fallidas usando jq:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Accept: application/json" \
"https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/restoreJobs" \
| jq '.results[] | select(.statusName=="BROKEN" or .statusName=="KILLED")'

Para obtener más información, consulta Obtener todos los trabajos de restauración para un clúster.

Las siguientes secciones describen las causas comunes de los fallos en la copia de seguridad y restauración, así como la manera de resolverlos.

Las siguientes secciones describen las causas comunes de los fallos de copia de seguridad y cómo resolverlos.

La falta de espacio libre en disco en los nodos miembros del conjunto de réplicas puede hacer que el clúster entre en un estado no saludable, provocando fallos en la copia de seguridad.

Para resolver este problema, aumenta la capacidad de almacenamiento disponible en el dbPath de los nodos afectados. Supervise el uso del disco regularmente para evitar recurrencias.

El proceso de copia de seguridad depende de que el MongoDB Agent esté funcionando de forma continua. Si el agente se detiene o sigue reiniciando, las copias de seguridad fallan.

Los síntomas incluyen:

  • Alertas como “copia de seguridad oplog is behind”

  • No se recibieron "slices" de Oplog durante una hora

Para resolver este problema:

1
2

Los registros del agente suelen estar ubicados en:

/var/log/mongodb-mms-automation/backup-agent.log
3

Para más información, consulta Solucionar problemas con la copia de seguridad del Oplog.

El agente de copias de seguridad debe mantener una conexión con el set de réplicas. Pueden producirse fallos debido a problemas de conectividad de red, un nodo de MongoDB no disponible o un fallo de autenticación.

Los síntomas en los registros del agente incluyen:

  • server selection timeout

  • Authentication failed

Para resolver este problema:

1
mongosh "mongodb://host:port"
2

Confirme lo siguiente:

  • Acceso a la red entre el host del agente y los miembros del set de réplicas

  • Disponibilidad del set de réplicas

  • Guardar credenciales de usuario de copia de seguridad y roles requeridos

Para más información, consulta Solucionar problemas con la copia de seguridad del Oplog.

Si el oplog es demasiado pequeño o el agente de copias de seguridad no puede mantener el ritmo de las actividades de escritura, la copia de seguridad se retrasará y finalmente fallará.

Los síntomas incluyen las siguientes alertas:

  • "La copia de seguridad requiere una resincronización"

  • "Oplog de copia de seguridad está retrasado"

Para resolver este problema:

  • Aumenta el tamaño del oplog para que la oplog window cubra suficiente historial (se recomienda un mínimo de 24 horas).

  • Si la copia de seguridad se ha quedado demasiado atrás, vuelve a sincronizar la copia de seguridad.

Una tarea de copia de seguridad requiere un daemon de copias de seguridad con suficiente espacio para almacenar una copia local del set de réplicas respaldado. Si ningún demonio tiene el espacio suficiente, la tarea no logra vincularse. Para resolver este problema, añade un daemon de copias de seguridad adicional para aumentar la capacidad.

Este problema también puede ocurrir cuando no se detecta un primario en el set de réplicas. Para resolver esto, asegúrese de que el set de réplicas esté en buen estado y tenga un primario antes de volver a intentar la copia de seguridad.

Para obtener más información, consulte la Preguntas frecuentes sobre copias de seguridad.

Las siguientes secciones describen las causas comunes de fallas en la restauración y cómo resolverlas.

Al restaurar un clúster particionado, debes restaurar todas las particiones. El proceso de restauración falla si intentas restaurar una partición única de forma aislada.

Para obtener más información, vea Limitaciones de restauración.

Una restauración automatizada puede fallar cuando ciertos ajustes de almacenamiento de la copia de seguridad de origen y la base de datos de destino no coinciden. Si un intento de restauración falla, Ops Manager muestra cualquier configuración que no coincida.

Para obtener una lista de configuraciones que deben coincidir, consulta Posibles causas de falla en la restauración automatizada.

Las restauraciones a un punto específico del tiempo requieren un historial de registro de operaciones (oplog) continuo. Si hay una brecha en el oplog, la restauración falla.

Las causas comunes de huecos en el Oplog incluyen:

  • El agente de copias de seguridad dejó de monitorizar el oplog.

  • El oplog se reinició antes de que el agente lo procesara.

  • Se produjeron cambios en la topología del clúster.

  • Ocurrió un cambio de compatibilidad de características entre versiones (FCV).

  • Se intentó una restauración durante cambios de versión de MongoDB.

Para resolver este problema:

  • Restaure a partir de la última instantánea válida tomada antes de la brecha de oplog, o

  • Espera hasta que se cree una nueva snapshot y luego realiza la restauración nuevamente.

Para obtener más información, consulte Restaurar desde un punto específico en el tiempo.

Si el host de destino no tiene suficiente almacenamiento para los archivos de snapshot y la base de datos restaurada, la restauración falla.

Para resolver este problema:

1
db.stats()
2

Verifique que el dbPath tenga suficiente espacio libre en disco para acomodar los datos restaurados antes de proceder.

Para obtener más información sobre el comando dbStats, consulta dbStats.

Si el problema persiste, recopila la siguiente información antes de contactar al Soporte Técnico:

  • Mensajes de error completos desde la Interfaz de Usuario o API de Ops Manager

  • Archivos de registro del agente de copias de seguridad

  • Versión del servidor de MongoDB

  • Versión de Ops Manager

  • Logs relevantes del servidor MongoDB

  • Salida de la página Restauraciones o de la query de tarea de restauración de la API

Volver

Recuperación de una instancia autónoma después de un apagado inesperado

En esta página