La recuperación ante desastres (DR) es una estrategia de resiliencia que utiliza procedimientos manuales para recuperar su implementación cuando la conmutación por error automática no puede ayudar. A diferencia de La alta disponibilidad proporciona una autorreparación automática ante fallos de infraestructura, mientras que la recuperación ante desastres requiere la intervención humana para restaurar a partir de 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 Modelo de responsabilidad compartida.
Cuándo utilizar la recuperación ante desastres
Importante
Priorice la alta disponibilidad siempre que sea posible. Utilice la recuperación ante desastres como estrategia principal de resiliencia solo cuando la alta disponibilidad no sea factible.
La recuperación ante desastres es apropiada como estrategia principal de resiliencia en las siguientes situaciones:
- Restricciones geográficas
- No es posible realizar implementaciones en varias regiones con suficientes zonas de disponibilidad. Por ejemplo, si debe realizar la implementación en Canadá, solo están disponibles las regiones 2, lo que impide cumplir con los requisitos de quórum de conmutación por error automática.
- Cost Optimization
- Su presupuesto exige minimizar los costos de infraestructura. Las implementaciones de alta disponibilidad en múltiples regiones o nubes cuestan más que las implementaciones en una sola región con copias de seguridad.
- Tolerancia para la recuperación manual
- Su 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
Aunque utilice alta disponibilidad, podría beneficiarse de procedimientos de recuperación ante desastres para situaciones que la conmutación por error automática no puede solucionar, como la corrupción o la eliminación accidental de datos. Para obtener más información sobre cómo combinar ambos enfoques, consulte la Guía para la planificación de la continuidad del negocio de Atlas.
Cómo las copias de seguridad ayudan a la recuperación ante desastres
Las copias de seguridad son la herramienta principal para la recuperación ante desastres. Atlas ofrece copias de seguridad totalmente gestionadas y personalizables que permiten la recuperación manual cuando la conmutación por error automática no es suficiente.
Copia de seguridad en la nube
Cuando habilitas la copia de seguridad en la nube para tu clúster, Atlas utiliza las capacidades de instantáneas nativas de tu proveedor de nube para crear copias de seguridad incrementales que son inmutables de forma predeterminada y con tiempos de restauración rápidos.
Cómo apoya la DR:
Configure la frecuencia de las instantáneas (por hora, diaria, semanal, mensual, anual) para cumplir con sus requisitos de RPO.
Establezca períodos de retención de instantáneas para cumplir con los requisitos de cumplimiento y recuperación.
Restaure instantáneas para recuperarse de la corrupción o eliminación de datos.
Cuándo usarlo: Escenarios estándar de recuperación ante desastres donde se puede tolerar una pérdida de datos equivalente a la frecuencia de las instantáneas. Por ejemplo, las instantáneas horarias resultan en una 1 pérdida de datos de hasta horas.
Recuperación a un punto en el tiempo con copia de seguridad continua en la nube.
Al habilitar la copia de seguridad continua en la nube además de la copia de seguridad en la nube, Atlas almacena los datos del registro de operaciones junto con las instantáneas de la copia de seguridad en la nube, lo que permite a Atlas restaurar el 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:
Restaure a cualquier momento dentro de una ventana de restauración PIT configurable. Atlas conserva los datos del oplog durante el tiempo que dure la ventana de restauración y reproduce las entradas del oplog sobre la instantánea de Cloud Backup más cercana para restaurar al momento exacto que especifique.
Lograr :abbr:RPO (Objetivo de Punto de Recuperación) tan bajos como 1 minutos.
Apuntar con precisión al momento previo a que se produzca la corrupción o eliminación de datos.
Cuándo usarlo: Cuando necesite una pérdida de datos mínima (RPO bajo) o una recuperación precisa a una marca de tiempo específica.
Distribución de instantáneas multirregionales
Al habilitar la copia de seguridad en la nube con una política de copia de instantáneas, puede configurar Atlas para que distribuya automáticamente copias de sus instantáneas y registros de operaciones a regiones adicionales del proveedor de la nube en otras zonas geográficas.
Cómo apoya la DR:
Cumple con los requisitos de conformidad para copias de seguridad distribuidas geográficamente.
Garantiza que las copias de seguridad permanezcan accesibles incluso si la región principal falla por completo.
Para un clúster multirregional, habilitar la Automatically Sync Copy Regions with Cluster Regions La opción en su política de copia de instantáneas permite que Atlas distribuya automáticamente las instantáneas a todas las regiones donde está implementado su clúster y mantiene sincronizada dicha política a medida que agrega o elimina regiones. Esto permite que Atlas utilice restauraciones de conexión directa más rápidas para restaurar las regiones del clúster mediante copias de instantáneas locales tras una interrupción regional, en lugar de las restauraciones de transmisión entre regiones, que son más lentas.
Cuándo usarlo: Cuando necesite protección contra la pérdida regional total o interrupciones del proveedor que superen su configuración de alta disponibilidad.
Compromisos entre RTO y RPO en la estrategia de respaldo
Las estrategias de respaldo protegen contra fallas en la integridad de los datos que la conmutación por error automática no puede solucionar, como la corrupción de datos, la eliminación accidental y la pérdida total de la implementación. Todas las estrategias de respaldo implican cierta pérdida de datos (RPO > 0) y tiempos de recuperación más prolongados (RTO de minutos a horas). Las ventajas y desventajas radican en la cantidad de datos que se pueden perder y la complejidad operativa de cada enfoque.
Estrategia de respaldo | Casos de uso principales | RTO típico | RPO | Consideraciones operativas | Consideraciones de costos |
|---|---|---|---|---|---|
Instantáneas periódicas | Corrupción de datos, eliminación accidental, pérdida total de la implementación. | De minutos a horas. | > 0 (hasta el intervalo de instantánea). | Defina el cronograma/retención. Pruebe periódicamente los procedimientos de restauración. | El almacenamiento aumenta con la frecuencia y la retención. La restauración genera costos de procesamiento y de salida de datos. |
Copia de seguridad continua con restauración a un punto en el tiempo | Corrupción o eliminación de datos cuando se conoce una marca de tiempo "incorrecta". | De minutos a horas. | > 0 (cerca de cero, hasta segundos). | Configure las ventanas de restauración de punto en el tiempo (PIT). Supervise los fallos. | Mayor coste de almacenamiento y copia de seguridad que con las instantáneas por sí solas. |
Distribución instantánea multirregional | Pérdida de región o proveedor que también afecta a las copias de seguridad locales. | De minutos a horas (puede ser más lento en otras regiones). | > 0 (vinculado al cronograma de instantáneas). | Planificar y probar restauraciones entre regiones. Gestionar la política de retención. | Almacenamiento adicional en múltiples regiones. Salida entre regiones al restaurar. |
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 una interrupción regional, los clústeres multirregionales realizan automáticamente una elección e identifican un nuevo nodo principal si es necesario. Este cambio de topología se comunica automáticamente a la aplicación, lo que le permite tomar las medidas correctivas necesarias. Para mantener la disponibilidad de la aplicación en caso de una interrupción regional, esta también debe implementarse con una topología multirregional. Este requisito se extiende a cualquier servicio de terceros con el que su aplicación pueda estar integrada. Para obtener más información, consulte el Paradigma de implementación multirregional.
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 Atlas multirregión se recuperan automáticamente de una interrupción en una sola región. Para obtener más información, consulte la Guía para la alta disponibilidad de Atlas y el paradigma de implementación multirregión. En caso de que las interrupciones regionales hayan dejado fuera de servicio a la mayoría de los nodos, deberá determinar cuántos nodos adicionales necesita agregar para que la mayoría de los nodos estén operativos.
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.