La recuperación ante desastres (DR por sus siglas en inglés) es una estrategia de resiliencia que utiliza procedimientos manuales para recuperar tu implementación cuando la conmutación por falla automática no es eficaz. A diferencia de la alta disponibilidad, que proporciona una autorrecuperación automática ante fallos en la infraestructura, la recuperación ante desastres requiere la intervención humana para restaurar desde las copias de seguridad.
Nota
El Modelo de Responsabilidad Compartida de MongoDB Atlas define los deberes complementarios de MongoDB y sus clientes en el mantenimiento de un entorno de datos seguro y resiliente. Bajo este marco, MongoDB gestiona la seguridad y la integridad operativa de la plataforma subyacente, mientras que los clientes son responsables de la configuración, gestión y políticas de datos de sus implementaciones específicas. Para obtener un desglose detallado de la propiedad en materia de seguridad y excelencia operativa, consulta el Modelo de Responsabilidad Compartida.
Cuándo utilizar la recuperación ante desastres
Importante
Prefiera tener alta disponibilidad siempre que sea posible. Utiliza la recuperación ante desastres como tu estrategia principal de resiliencia únicamente cuando la alta disponibilidad no sea posible.
La recuperación ante desastres es apropiada como su principal estrategia de resiliencia en las siguientes situaciones:
- Restricciones geográficas
- No puedes implementar en varias regiones con zonas de disponibilidad suficientes. Por ejemplo, si debes implementar en Canadá, solo 2 regiones están disponibles, lo que impide los requisitos automáticos de cuórum para la conmutación por error.
- Cost Optimization
- Su presupuesto requiere minimizar los costos de infraestructura. Las implementaciones de alta disponibilidad en multiregión o multinube cuestan más que las implementaciones en una sola región con copias de seguridad.
- Tolerancia para la recuperación manual
- Tu aplicación puede tolerar el tiempo necesario para la intervención manual y la restauración de copias de seguridad (RTO en minutos u horas en lugar de segundos).
Nota
Incluso si utilizas alta disponibilidad, es posible que te beneficie de los procedimientos de recuperación ante desastres para escenarios que la conmutación por error automática no puede abordar, como la corrupción de datos o la eliminación accidental. Para aprender más sobre cómo combinar ambos enfoques, vea Orientación para la planificación de continuidad del negocio Atlas.
Cómo las copias de seguridad respaldan la recuperación ante desastres
Las copias de seguridad son la herramienta principal para implementar la recuperación ante desastres. Atlas proporciona copias de seguridad completamente gestionadas y personalizables que permiten la recuperación manual cuando la conmutación por error automática no es útil.
Copia de seguridad en la nube
Cuando habilitas copias de seguridad en la nube para tu clúster, Atlas utiliza las capacidades nativas de snapshot de tu proveedor de nube para crear copias de seguridad incrementales que son inmutables por defecto con tiempos de restauración rápidos.
Cómo apoya la DR:
Configure la frecuencia de las snapshot (cada hora, diaria, semanal, mensual, anual) para cumplir con sus requisitos de RPO.
Configura los periodos de retención de snapshot para cumplir con las necesidades de cumplimiento y recuperación.
Restea las instantáneas para recuperarlas de la corrupción de datos o la eliminación.
Cuándo usarlo: Escenarios estándar de recuperación ante desastres donde se puede tolerar la pérdida de datos igual a la frecuencia de las instantáneas. Por ejemplo, los snapshots horarios pueden provocar hasta 1 horas de pérdida de datos.
Recuperación puntual con copia de seguridad continua en la nube
Cuando habilitas la copia de seguridad continua en la nube además de las copias de seguridad en la nube, Atlas almacena los datos del oplog junto con tus snapshots de copias de seguridad en la nube, lo que permite a Atlas la restauración de tu clúster a un momento específico dentro de una ventana de restauración configurable de Punto en el tiempo (PIT).
Cómo apoya la DR:
Restaurar en cualquier momento dentro de una ventana de restauración PIT configurable. Atlas conserva los datos de oplog durante hasta la longitud de la ventana de restauración y reproduce las entradas de oplog sobre la instantánea de Cloud Backup más cercana para restaurar en el momento preciso que especifiques.
Logre un RPO de tan solo 1 minuto.
Apunta con precisión al momento anterior a la corrupción o eliminación de los datos.
Cuándo usar: Cuando necesitas una pérdida mínima de datos (bajo RPO) o una recuperación precisa a una marca de tiempo específica.
Distribución de snapshot multirregional
Cuando habilitas Cloud Backup con una política de copia de snapshot, puedes configurar Atlas para distribuir automáticamente copias de tus snapshots y oplogs a regiones adicionales de proveedor de nube en otras geografías.
Cómo apoya la DR:
Cumple con los requisitos de cumplimiento para copias de seguridad distribuidas geográficamente.
Garantiza que las copias de seguridad sigan siendo accesibles incluso si la región primaria falla por completo.
Para un clúster multirregión, habilitar la opción Automatically Sync Copy Regions with Cluster Regions en la política de copia de snapshots permite que Atlas distribuya automáticamente snapshots en todas las regiones donde tu clúster esté implementado y mantenga la política de copia de snapshots sincronizada a medida que agregas o remueves regiones. Esto permite que Atlas utilice restauraciones más rápidas y de conexión directa para restaurar las regiones del clúster utilizando copias locales de snapshots después de una interrupción regional, en lugar de restauraciones de transmisión entre regiones más lentas.
Cuándo usar: Cuando necesites protección contra una pérdida regional completa o interrupciones del servicio del proveedor que superen tu configuración de alta disponibilidad (HA).
Compromisos entre RTO/RPO en la estrategia de copias de seguridad
Las estrategias de copia de seguridad protegen contra fallos de integridad de los datos que la conmutación por error automática no puede abordar, como la corrupción de datos, la eliminación accidental y la pérdida total de la implementación. Todas las estrategias de copia de seguridad implican cierta pérdida de datos (RPO > 0) y tiempos de recuperación más largos (RTO en minutos a horas). Las compensaciones radican en cuánto datos podrías perder y la complejidad operativa de cada enfoque.
Estrategia de copia de seguridad | Casos de uso principales | RTO típico | RPO | Consideraciones operativas | Consideraciones de costos |
|---|---|---|---|---|---|
Capturas periódicas | Corrupción de datos, eliminación accidental, pérdida total de implementación. | Minutos a horas. | > 0 (hasta el intervalo de snapshot). | Definir cronograma/retención. Pruebe periódicamente los procedimientos de restauración. | El almacenamiento aumenta con la frecuencia y la retención. La restauración incurre en costos de cómputo / egreso. |
Copia de seguridad continua con restauración a un punto específico del tiempo | Corrupción o eliminación de datos donde se conoce la marca de tiempo "incorrecta". | Minutos a horas. | > 0 (casi cero, hasta segundos). | Configure ventanas de restauración Point in Time (PIT). Supervise las fallas. | Mayor costo de almacenamiento y copia de seguridad que únicamente snapshots. |
Distribución de snapshot multirregional | Pérdida de región o proveedor que también afecta a las copias de seguridad locales. | Minutos a horas (puede ser más lento entre regiones). | > 0 (vinculado al cronograma de instantáneas). | Planifique y pruebe restauraciones entre regiones. Administrar la política de retención. | Almacenamiento adicional en varias regiones. Salida entre regiones en la restauración. |
Todas las recomendaciones paradigmáticas de implementación
Las siguientes recomendaciones se aplican a todos los paradigmas de implementación.
Esta sección cubre los siguientes procedimientos de recuperación ante desastres:
Interrupción del servicio de Nodo Único
Si un solo nodo en su conjunto de réplicas falla debido a una interrupción regional parcial, su implementación debería seguir estando disponible, suponiendo que haya seguido las mejores prácticas. Si está leyendo desde secundarios, podría experimentar un rendimiento degradado o posibles interrupciones del servicio en el evento de que un secundario falle, debido a la mayor carga en el clúster que queda sub-provisionado.
Puedes probar una interrupción del servicio del nodo primario en Atlas usando la funcionalidad Prueba de conmutación por error primaria de la interfaz de usuario de Atlas o el endpoint Prueba de conmutación por error de la API de administración de Atlas.
Interrupción del servicio regional
En caso de un evento regional, los clústeres multiregionales automáticamente celebran una elección e identifican un nuevo nodo primario si es necesario. Este cambio de topología se comunica automáticamente a la aplicación, lo que le permite tomar cualquier acción correctiva necesaria. Para mantener el tiempo de actividad de la aplicación en caso de una interrupción regional, tu aplicación también debe implementarse con una topología multiregión. Este requisito se extiende para incluir cualquier servicio de terceros con el que su aplicación pueda integrarse. Para obtener más información, consulte Paradigma de implementación multiregión.
Si una interrupción del servicio de una sola región o una interrupción del servicio multiregión degrada el estado del clúster, sigue estos pasos:
Determinar qué regiones es poco probable que se vean afectadas por la Interrupción del servicio actual
Dependiendo de la causa de la interrupción del servicio, es posible que en un futuro próximo haya otras regiones que también sufran interrupciones del servicio no programadas. Por ejemplo, si las interrupciones del servicio se debieron a una catástrofe natural en la costa este de Estados Unidos, evita regiones de esa zona por si hay problemas adicionales.
Agrega nodos a las regiones que identificaste
Agregue la cantidad necesaria de nodos para un estado normal en regiones que probablemente no se vean afectadas por la causa de la Interrupción del servicio.
Para reconfigurar un set de réplicas durante una interrupción del servicio añadiendo regiones o nodos, consulta Reconfigurar un set de réplicas durante una interrupción del servicio regional.
se puede probar una interrupción del servicio de región en Atlas utilizando la funcionalidad Simular Interrupción del servicio de la Interfaz de Usuario de Atlas o el endpoint de la API de administración de Atlas Iniciar una simulación de Interrupción del servicio.
Interrupción del servicio del proveedor de nube
Con clústeres multicloud, puedes seleccionar nodos elegibles en diferentes proveedores de nube para mantener una alta disponibilidad. Si el proveedor en el que se encuentra desplegado tu nodo primario se vuelve inaccesible, Atlas elige automáticamente nuevos nodos primarios para garantizar una operación continua. Por ejemplo, puedes crear nodos elegibles en AWS, Google Cloud y Microsoft Azure para garantizar que, si un proveedor de nube experimenta una interrupción del servicio, un nodo elegible en un proveedor distinto pueda asumir automáticamente el rol de nodo primario de tu clúster. Para obtener más información, consulte Paradigma de implementación multi-nube.
La mayoría de los clústeres de Atlas multiregión se recuperarán automáticamente de una interrupción del servicio de una sola región. Para aprender más, consulta Orientación para la alta disponibilidad Atlas y Paradigma de multiregión implementación. En caso de que los cortes regionales hayan dejado fuera de línea a la mayoría de los nodos, debes determinar cuántos nodos adicionales necesitas agregar para que la mayoría de los nodos estén en buen estado.
En el muy improbable evento de que un proveedor de nube completo no esté disponible, sigue estos pasos para restaurar tu implementación en linea:
Identifica el proveedor de nube alternativo en el que te gustaría implementar tu nuevo clúster
Para obtener una lista de proveedores de nube e información, consulta Proveedores de nube.
Si almacena copias de seguridad en varios proveedores de la nube, como una interrupción del servicio del proveedor de la nube implica que cualquier copia de seguridad almacenada en el proveedor de nube primario es necesariamente inaccesible, encuentre la snapshot más reciente disponible tomada del clúster antes de que comenzara la interrupción del servicio
Para aprender a ver tus imágenes de copia de seguridad, consulta Ver M10+ imágenes de copia de seguridad.
Crear un nuevo clúster con el proveedor de nube alternativo
Tu nuevo clúster debe tener una topología idéntica al clúster original.
Alternativamente, en lugar de crear un clúster completamente nuevo, también puedes agregar nuevos nodos alojados por un proveedor de nube alternativo al clúster existente.
Restaura la snapshot más reciente del paso anterior en el nuevo clúster
Para aprender a restaurar tu snapshot, consulta Restaurar tu clúster.
Transfiere cualquier aplicación que se conecte al clúster antiguo al clúster recién creado
Para encontrar la nueva cadena de conexión, consulta Conectar a través de Librerías de clientes. Revisa tu pila de aplicaciones, ya que probablemente necesites volver a implementarla en el nuevo proveedor de nube.
Interrupción del servicio de Atlas
En el evento altamente improbable de que el plano de control de Atlas y la Interfaz de Usuario de Atlas no estén disponibles, tu clúster seguirá estando disponible y accesible. Para aprender más, consulta Fiabilidad de la plataforma. Abre un ticket de soporte de alta prioridad para investigar esto más a fondo.
Problemas de capacidad de recursos
Los problemas de capacidad de recursos computacionales (como espacio en disco, RAM o CPU) pueden deberse a una mala planificación o a tráfico inesperado en la base de datos. Este comportamiento podría no ser el resultado de un desastre.
Si un recurso computacional alcanza la cantidad máxima asignada y causa un desastre, siga estos pasos:
Identifica qué recurso computacional está al máximo utilizando el Panel de rendimiento en tiempo real o las métricas de Atlas
Para ver la utilización de recursos en la interfaz de usuario de Atlas, consulta Supervisar el rendimiento en tiempo real
Para ver las métricas con la API de administración de Atlas, consulta Supervisión y registros.
Asigna los recursos necesarios
Ten en cuenta que Atlas realizará este cambio de forma paulatina, por lo que no debería tener ningún impacto importante en tus aplicaciones.
Para aprender a asignar más recursos, consulta Edita un clúster.
Fallo de recurso
Importante
Esta es una solución temporal destinada a acortar el tiempo de inactividad general del sistema. Una vez que el problema subyacente se resuelva, fusione los datos del clúster recién creado en el clúster original y dirija todas las aplicaciones de nuevo al clúster original.
Si un recurso computacional falla y causa que el clúster se vuelva inaccesible, sigue estos pasos:
Abre un ticket de soportede alta prioridad
Restaura la copia de seguridad más reciente en el clúster recién creado
Para aprender a restaurar tu snapshot, consulta Restaurar tu clúster.
Eliminación de datos de producción
Es posible que los datos de producción se borren accidentalmente debido a un error humano o a un fallo en la aplicación compilada sobre la base de datos. Si se eliminó accidentalmente el propio clúster, Atlas podría retener el volumen temporalmente.
Si el contenido de una colección o base de datos ha sido eliminado, sigue estos pasos para restaurar tus datos:
Cree una copia del estado actual de la colección o base de datos, si contiene algún dato
Puedes usar mongoexport para crear una copia.
Restaurar tus datos
Si la eliminación ocurrió en las últimas 72 horas y configuraste la copia de seguridad continua, utiliza la restauración Point-in-Time (PIT) para restaurar desde el punto en el tiempo justo antes de que ocurriera la eliminación.
Si la eliminación no ocurrió en las últimas 72 horas, restaurar la copia de seguridad más reciente de antes de que ocurriera la eliminación en el clúster.
Para obtener más información, consulta Restaurar tu clúster.
Si creaste una copia de tus datos, importa los nuevos datos que exportaste
Puedes usar mongoimport con modo inserción para importar tus datos y asegurarte de que cualquier dato modificado o agregado se refleje correctamente en la colección o base de datos.
Error del controlador
Si un driver falla, se deben seguir estos pasos:
Identifique la versión de controlador adecuada para resolver el problema
Si está utilizando un controlador obsoleto, compruebe si la actualización a una versión más reciente resuelve el problema. La mayoría de los problemas de los controladores se solucionan en versiones más recientes.
Si has actualizado recientemente tu driver y sospechas que la nueva versión introdujo el problema, considera volver a la versión anterior que funcionaba.
Corrupción de datos
Importante
Esta es una solución temporal destinada a acortar el tiempo de inactividad general del sistema. Una vez que el problema subyacente se resuelva, fusione los datos del clúster recién creado en el clúster original y dirija todas las aplicaciones de nuevo al clúster original.
Si los datos subyacentes se corrompen, siga estos pasos:
Abre un ticket de soportede alta prioridad
Restaura la copia de seguridad más reciente en el clúster recién creado
Para aprender a restaurar tu snapshot, consulta Restaurar tu clúster.