Guía completa de copia de seguridad y restauración de bases de datos MongoDB

Introducción: ¿Por qué son importantes las copias de seguridad para MongoDB?

Cuando se utiliza MongoDB en producción, las copias de seguridad son esenciales: pueden significar la diferencia entre la recuperación de un incidente y la pérdida permanente de datos. Una base de datos como MongoDB que contiene información de usuarios, transacciones, información de productos o el estado de una aplicación es una base de datos en la que la integridad de los datos se traduce directamente en la continuidad del negocio. Los procesos de copia de seguridad y restauración de los datos de MongoDB son la base de esa integridad.

Un único fallo de hardware, un borrado involuntario o una infección por ransomware podrían provocar una pérdida significativa de datos. Tampoco existirían opciones de recuperación viables en esos casos si no se dispone de una estrategia de copia de seguridad sólida y fiable. La calidad de un plan de copias de seguridad de MongoDB desplegado hoy dictará la rapidez con la que los sistemas puedan volver a estar en línea después de que finalmente fallen, como ocurre con la mayoría de los sistemas, por desgracia.

¿Cuáles son los riesgos de no disponer de una estrategia de copias de seguridad fiable?

Existen tres categorías principales de riesgos al ejecutar un sistema MongoDB sin ninguna estrategia de copias de seguridad:

• Operativos
• Financieros
• Reputacional

Todas estas categorías tienen algún tipo de efecto que se acumulará con el tiempo y se hará mucho más difícil de solucionar tras los eventos de pérdida de datos.

El riesgo operativo es el más inmediato. Cuando falla un nodo primario, se cae una colección o falla una migración, el cluster queda en un estado inconsistente. Para empezar, la base de datos de copia de seguridad de MongoDB esperada no existe, por lo que el equipo tiene que realizar una recuperación forense a partir de registros de aplicaciones o exportaciones fragmentadas, si es que existen.

La exposición financiera le sigue de cerca. Las obligaciones de cumplimiento impuestas por normativas como GDPR, HIPAA y SOC 2 implican que un fallo en la copia de seguridad será un incidente de cumplimiento, no un mero fallo técnico. Las auditorías posteriores, las multas y las notificaciones de incumplimiento obligatorias pueden tener su origen en unas prácticas de copia de seguridad y restauración de MongoDB mal implementadas o inexistentes.

Los modos de fallo más comunes con los que se encuentran las organizaciones incluyen

• Bajas accidentales de colecciones – un desarrollador ejecuta db.collection.drop() en el entorno equivocado
• Migraciones de esquemas chapuceras – un script de transformación corrompe documentos a escala antes de que se detecte el error
• Ransomware y ataques a la infraestructura – los datos encriptados se vuelven inaccesibles sin una copia fuera de línea
• Fallo de hardware sin redundancia – un nodo autónomo se cae sin réplica ni instantánea reciente
• Corrupción silenciosa – los problemas de integridad de los datos pasan desapercibidos hasta que se necesita una copia de seguridad, momento en el que las copias de seguridad existentes también pueden estar dañadas

El daño a la reputación es más difícil de cuantificar, pero eso no lo hace menos real. Tanto los usuarios particulares como las empresas que confían sus datos a una plataforma esperan que dichos datos permanezcan seguros. Un evento de pérdida de datos ampliamente difundido -incluso si fue causado por un problema de infraestructura y no por una intención maliciosa- daña tanto la confianza de los usuarios que se tarda años en redimirla y reconstruirla.

¿Cómo afectan los tipos de despliegue de MongoDB a las necesidades de copia de seguridad (independiente, conjunto de réplicas, clúster fragmentado)?

La topología de despliegue de MongoDB actualmente en uso determina los posibles métodos de copia de seguridad disponibles, el nivel de complejidad y las garantías de consistencia disponibles. Las tres topologías principales que existen son standalone, replica set y sharded cluster, todas ellas con distintos requisitos de copia de seguridad.

Las implantaciones autónomas son las más sencillas para realizar copias de seguridad, pero conllevan el mayor riesgo inherente. Como no hay un sistema secundario al que conmutar por error mientras se ejecutan las copias de seguridad, cualquier proceso de copia de seguridad altamente intensivo en E/S competirá directamente con el tráfico de producción. Las instantáneas de sistemas de archivos con soporte de semántica de copia en escritura son las más apropiadas en esta situación, como LVM o ZFS (ambas son instantáneas y no disruptivas).

Los conjuntos de réplica introducen un alto grado de flexibilidad operativa. El proceso de copia de seguridad de MongoDB puede descargarse en un nodo secundario, manteniendo la carga de trabajo de copia de seguridad aislada de las primarias. Las copias de seguridad basadas en oplog también se hacen posibles en este caso, permitiendo la recuperación puntual a cualquier momento utilizando la ventana de retención de oplog, algo que las implantaciones independientes no pueden proporcionar.

Oplog es un registro con fecha y hora de cada operación de escritura en la base de datos, que MongoDB puede utilizar con fines de replicación reproduciéndolo para restaurar los datos a cualquier punto anterior en el tiempo.

Los clústeres fragmentados requieren la coordinación más cuidadosa. Cada fragmento se trata como un conjunto de réplicas independiente, por lo que es necesario capturar todos los fragmentos y el conjunto de réplicas del servidor de configuración en el mismo punto lógico en el tiempo para lograr una copia de seguridad coherente en todo el clúster. La función de equilibrado de fragmentos debe pausarse antes de que comience una copia de seguridad, y la coherencia entre fragmentos sería difícil de garantizar sin una coordinación explícita. MongoDB Atlas Backup (el servicio gestionado de base de datos en la nube de MongoDB) se encarga de la mayoría de estas tareas de forma automática, pero los clústeres fragmentados autogestionados siguen necesitando una orquestación manual o una herramienta de terceros.

¿Qué objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) debo tener en cuenta?

RTO y RPO son las dos métricas que definen lo que debe ofrecer una estrategia de copia de seguridad. El objetivo de tiempo de recuperación ( RTO ) es la duración máxima aceptable entre un evento de fallo y el restablecimiento del servicio normal. El Objetivo de Punto de Recuperación (RPO ) es la cantidad máxima aceptable de pérdida de datos, expresada como un punto en el tiempo. Ambos valores deben definirse antes incluso de intentar seleccionar las herramientas de copia de seguridad o los patrones de programación: son los requisitos a los que sirven todas las demás decisiones.

La mayoría de las organizaciones sólo consiguen definir su RTO y RPO después de experimentar una interrupción de un tamaño considerable, lo que les obliga a definir estos parámetros bajo presión. Por ejemplo, una aplicación orientada al cliente que procesa pedidos continuamente no puede tolerar ni cuatro horas de inactividad ni seis horas de pérdida de datos. Muchas configuraciones de copias de seguridad que nunca se han sometido a pruebas de estrés producirían exactamente esos resultados.

Utilice el siguiente marco para establecer objetivos de referencia:

Un pipeline de copia de seguridad y restauración de bases de datos MongoDB con RPO de cinco minutos será completamente diferente de un pipeline con RPO de 24 horas. La copia de seguridad continua basada en Oplog es necesaria para permitir puntos de recuperación inferiores a una hora porque captura cada operación de escritura casi en tiempo real. Las estrategias basadas únicamente en instantáneas (que capturan instantáneas a determinados intervalos) producen un punto de recuperación igual a la frecuencia de las instantáneas, lo que significa que un programa de instantáneas de cuatro horas produce un RPO de cuatro horas en el peor de los casos.

Los RTO son igualmente sensibles a la hora de elegir una estrategia de copia de seguridad. Restaurar 2 TB de un archivo mongodump desde el almacenamiento de objetos llevaría varias horas. Mientras tanto, restaurar a partir de una instantánea de un sistema de archivos que reside en un almacenamiento de bloques adjunto sólo llevaría unos minutos. El propio proceso de restauración de MongoDB -no sólo el formato de la copia de seguridad- debe tenerse en cuenta en todos los cálculos de RTO. Los equipos que documentan y prueban regularmente sus marcos de restauración tienen más probabilidades de cumplir sus objetivos de RTO cuando importa.

¿Cómo encaja la copia de seguridad de MongoDB en una estrategia de protección de datos empresarial más amplia?

La copia de seguridad es sólo una faceta de una estrategia de protección; no es la totalidad. Aunque la copia de seguridad de MongoDB abarca los datos a nivel de base de datos (colecciones, índices, usuarios y ajustes de configuración), la resistencia de la empresa también requiere una cobertura adecuada del estado de la aplicación, la gestión de secretos y las dependencias entre servicios. La estrategia de copia de seguridad de MongoDB que una empresa decida aplicar debe definirse teniendo en cuenta este objetivo global.

¿Por qué la copia de seguridad a nivel de base de datos no es suficiente para la resiliencia de la empresa?

Una copia de seguridad completa de MongoDB captura todo el contenido del motor de la base de datos. No captura lo siguiente

• La configuración de la aplicación que indica a la base de datos cómo comportarse
• Certificados TLS que aseguran las conexiones a la base de datos
• Variables de entorno que almacenan credenciales
• Estado de la infraestructura que describe la topología de red dentro de la que se ejecuta

Recuperar una copia de seguridad de MongoDB en un entorno inestable o mal configurado va a crear una base de datos en funcionamiento a la que su aplicación no podrá conectarse o autenticarse. Para que las empresas sean resilientes, tendrán que tener en cuenta cada uno de los siguientes elementos:

1. Configuración y secretos de la aplicación – archivos de entorno, entradas Vault, cadenas de conexión y claves API de las que dependen los servicios
2. Estado de la infraestructura – definiciones de Terraform o CloudFormation que describen el entorno de red, computación y almacenamiento
3. Coherencia de datos entre servicios – registros relacionados en otras bases de datos o colas de mensajes que deben alinearse con el punto de restauración de MongoDB
4. La propia configuración de MongoDB – definiciones de conjuntos de réplica, roles de usuario e índices personalizados que no siempre son capturados por un mongodump básico

¿Cómo se integran las copias de seguridad de MongoDB con las plataformas de copia de seguridad empresariales?

No hay soporte «incorporado» para MongoDB en la mayoría de las soluciones de copia de seguridad empresariales.La integración se consigue normalmente a través de uno de tres mecanismos principales: ganchos de copia de seguridad pre/post que activan mongodump o una instantánea antes de que la plataforma capture el sistema de archivos, complementos basados en agentes que el proveedor de la plataforma proporciona o admite, u orquestación impulsada por API en la que la plataforma de copia de seguridad llama a un script externo que gestiona los pasos específicos de MongoDB.

Las plataformas con las que las organizaciones suelen integrar MongoDB incluyen:

• Bacula Enterprise. Integración basada en plugins con soporte de scripts previos al trabajo; muy adecuada para entornos regulados que requieren registros de auditoría.
• Veeam. Enfoque snapshot-first; la coherencia de MongoDB requiere un procesamiento que tenga en cuenta la aplicación o scripts de congelación previa
• Commvault. Integración de IntelliSnap para instantáneas a nivel de bloque; admite topologías de conjunto de réplica y clúster fragmentado
• NetBackup (Veritas). Basado en agente con programación de políticas; plugin de MongoDB disponible para niveles de licencias empresariales

¿Cómo reducen el riesgo operativo los sistemas de copia de seguridad centralizados?

Hacer que cada equipo sea responsable de gestionar su propio proceso de copia de seguridad de MongoDB dará lugar a programaciones variables, una retención incoherente y ninguna forma de saber si las copias de seguridad se han realizado correctamente en primer lugar. Los sistemas de copia de seguridad centralizados imponen la uniformidad de las políticas en todas las instancias de la base de datos, lo que elimina la clase de incidentes que surgen cuando el trabajo de copia de seguridad de un equipo se interrumpe silenciosamente durante semanas.

La ventaja operativa en este caso no es sólo la visibilidad, sino también la responsabilidad. Un sistema centralizado que realiza un seguimiento de cada trabajo de copia de seguridad, verifica cada instantánea finalizada y escala ante cualquier fallo crea un rastro claramente documentado que a menudo es necesario para fines de auditoría de cumplimiento. La gestión de copias de seguridad de MongoDB distribuida entre equipos tiende a producir lagunas que sólo se descubren cuando hay una necesidad urgente de restauración.

¿Qué estrategias de copia de seguridad de MongoDB existen?

La estrategia de copia de seguridad de bases de datos MongoDB adecuada dependerá de la topología de su despliegue, de la ventana tolerable de pérdida de datos y de la complejidad operativa. Las tres estrategias básicas de copia de seguridad que se describen a continuación -copia de seguridad lógica, copia de seguridad física y restauración puntual basada en oplog- tampoco son mutuamente excluyentes. En la mayoría de los entornos de producción se utilizan conjuntamente dos o las tres opciones.

¿Qué es una copia de seguridad lógica y cuándo debe utilizar mongodump/mongorestore?

La copia de seguridad lógica toma una instantánea de los datos de MongoDB como documentos BSON que son escritos en archivos por mongodump. Mongorestore es entonces capaz de restaurar estos datos en cualquier otra instancia MongoDB compatible. Este proceso es agnóstico a la topología, no necesita acceso a un sistema de archivos y genera una salida portátil que puede ser examinada, filtrada o restaurada en base a cada colección.

La copia de seguridad de MongoDB producida por mongodump captura documentos, índices, usuarios y roles. No captura el oplog ni las transacciones en curso, lo que significa que esta instantánea puntual sólo es tan consistente como el momento en que finaliza el volcado, mientras que el proceso en sí puede durar minutos o incluso horas (en conjuntos de datos de gran tamaño).

La copia de seguridad lógica es la elección correcta cuando:

• La portabilidad importa – mover datos entre versiones de MongoDB o proveedores de nube
• Se necesita una restauración selectiva – recuperar una sola colección sin tocar el resto de la base de datos
• El conjunto de datos es pequeño – menos de ~100GB, donde la duración del volcado no crea un riesgo de consistencia significativo
• No se dispone de acceso al sistema de archivos – entornos de alojamiento gestionados donde las API de instantáneas no están expuestas

Para implantaciones grandes y con mucha escritura, mongodump por sí solo rara vez es suficiente como estrategia primaria de copia de seguridad y restauración de MongoDB.

¿Qué es una copia de seguridad física y cuándo debe utilizar instantáneas del sistema de archivos?

La copia de seguridad física toma una copia de los archivos de datos en bruto que MongoDB escribe en el sistema de archivos (los archivos del motor de almacenamiento WiredTiger, el diario y los índices) a nivel de sistema de archivos/bloque. Entre las herramientas adecuadas para conseguirlo se incluyen las instantáneas LVM en Linux, las instantáneas AWS EBS y la función de envío/recepción ZFS.

Dado que la copia de seguridad es instantánea y se produce fuera del proceso de mongoDB – las copias de seguridad son mucho más rápidas de crear que mongodump en grandes conjuntos de datos y la propia base de datos es casi totalmente inconsciente de que la copia de seguridad está en curso, en términos de rendimiento.

El requisito previo clave para la copia de seguridad física es la consistencia del sistema de archivos. MongoDB tiene que estar en un estado limpio de checkpoints o debe tener el journaling activado (una medida por defecto con WiredTiger) para que la instantánea represente un estado recuperable. Intentar crear una instantánea sin tener esto en cuenta daría como resultado una copia de seguridad que podría incluso no iniciarse durante un procedimiento de recuperación de desastres de MongoDB.

La copia de seguridad física es la elección correcta cuando

• El tamaño del conjunto de datos es grande – donde la duración del mongodump crearía una brecha de consistencia inaceptablemente amplia
• El RTO es ajustado – las restauraciones a nivel de bloque son más rápidas que la reimportación a nivel de documento
• La infraestructura admite instantáneas atómicas – entornos EBS, LVM o ZFS en los que se dispone de instantáneas de copia en escritura
• La restauración completa del clúster es el escenario esperado – en lugar de la recuperación selectiva a nivel de colección

¿Cómo funcionan las copias de seguridad puntuales y los métodos basados en oplog?

La recuperación puntual funciona emparejando una instantánea base con una réplica de oplog para recuperar una implementación de MongoDB a cualquier punto específico dentro de la ventana de retención de oplog. Los nodos secundarios utilizan oplog con fines de replicación, mientras que las copias de seguridad lo utilizan para rellenar el hueco entre la instantánea base y el punto de recuperación objetivo.

El proceso funciona de la siguiente manera: se toma una instantánea base en el tiempo T, capturando el estado completo de la base de datos. A continuación, se captura el oplog de forma continua o a intervalos desde el momento T en adelante. En la restauración, primero se utiliza la instantánea base y luego se reproducen las entradas del oplog hasta la marca de tiempo objetivo, creando un estado de la base de datos que es exacto a ese momento exacto.

Existen dos limitaciones prácticas que rigen este enfoque. La primera es el hecho de que el oplog tiene un límite, ya que las entradas más antiguas se sobrescriben una vez que se producen las nuevas, por lo que la ventana de recuperación siempre va a estar limitada por el tamaño del oplog y el volumen de escritura. La segunda restricción tiene que ver con el hecho de que la recuperación puntual requiere un conjunto de réplicas – ya que las implantaciones autónomas no tienen oplog y no pueden soportar este método sin Atlas o una solución de terceros.

¿Cuándo debe utilizar la copia de seguridad incremental de MongoDB frente a la copia de seguridad completa?

Una copia de seguridad completa copia todo el conjunto de datos en cada ejecución. Una copia de seguridad increment al copia únicamente las modificaciones realizadas desde la última copia de seguridad, ya sea mediante oplog tailing o mediante el seguimiento de cambios a nivel de bloque. La mejor opción para cada organización varía drásticamente en función del tamaño del conjunto de datos, la frecuencia de las copias de seguridad y el coste del almacenamiento.

Una estrategia típica de copia de seguridad consiste en utilizar una copia de seguridad completa semanal con copias de seguridad incrementales diarias o cada hora, lo que ofrece un compromiso entre la necesidad de espacio y la complejidad de la restauración. Cada copia de seguridad completa reinicializa la cadena incremental y limita la antigüedad del incremento, reduciendo hasta cierto punto el alcance de la corrupción.

¿Qué herramientas y servicios soportan la copia de seguridad y restauración de bases de datos MongoDB?

El ecosistema de copia de seguridad y restauración de MongoDB abarca un gran número de elementos segregados en grupos: servicios gestionados en la nube, utilidades nativas de línea de comandos, herramientas a nivel del sistema de archivos y plataformas empresariales de terceros. Cada una de estas opciones tiene una posición distinta en el espectro «simplicidad operativa – control».

¿Cuáles son los pros y los contras de MongoDB Atlas Backup?

MongoDB Atlas Backup es un servicio de copia de seguridad totalmente gestionado que viene con los clústeres Atlas. El servicio se ejecuta de forma continua, no requiere ninguna configuración tras habilitarlo e incluso admite la recuperación basada en marcas de tiempo en cualquier segundo del periodo de retención. Es la forma con menos fricciones de implantar un plan de copias de seguridad de MongoDB listo para producción para los equipos que ya utilizan MongoDB Atlas.

Las capacidades más destacables de Atlas Backup se resumen en la siguiente tabla.

La portabilidad es la mayor limitación de Atlas Backup. Si una solución se configuró para un clúster, no se transfiere a un despliegue autogestionado, y todas las restauraciones tienen que realizarse a través de la interfaz de Atlas o de la API (inaccesible a través de las herramientas estándar de mongorestore). Esa única limitación puede ser un obstáculo para las organizaciones que trabajan con mandatos de múltiples nubes o con requisitos normativos centrados en la residencia de los datos.

¿Cómo funciona MongoDB Atlas Backup to S3 y cuándo debería utilizarlo?

La copia de seguridad de Atlas de MongoDB a S3 es una función de exportación de instantáneas, no un flujo de replicación continua. Puede invocarse de forma manual o programada. Una vez desencadenado, Atlas toma una instantánea consistente del clúster, escribiéndola en un bucket S3 especificado en un formato que hace posible restaurar dichos datos posteriormente con herramientas MongoDB estándar. La instantánea exportada producida como resultado está desacoplada del propio Atlas, lo que la hace apropiada para el archivado a largo plazo, la copia entre regiones o como parte de los requisitos de retención de conformidad.

También es importante tener claro qué es y qué no es esta función. Atlas Backup no proporciona transmisión en tiempo real de los cambios de oplog a S3. La exportación se realiza en un momento determinado, y el intervalo entre dichas exportaciones es el RPO efectivo para cualquier cosa que dependa exclusivamente de las copias en S3. Los equipos que necesiten puntos de recuperación inferiores a una hora tienen que tratar estas exportaciones a S3 como una capa de archivo secundaria, no como un mecanismo principal de recuperación de datos.

Las copias de seguridad de Atlas deben emplearse cuando exista una necesidad de retención a largo plazo o de portabilidad fuera de Atlas. No confíe en él como único método de copia de seguridad de MongoDB en producción, especialmente cuando los RPO ya son lo suficientemente estrictos.

¿Cómo se comparan mongodump/mongorestore con mongorestore con oplog replay?

El mongodump normal toma una única instantánea lógica consistente de la base de datos. Al restaurarla mediante mongorestore se reproduce la instantánea tal cual, creando una base de datos que vuelve a su estado exacto en el momento en que se completó el volcado, sin opción de recuperación a ningún otro punto.

mongorestore with oplog replay amplía el resultado anterior aplicando las operaciones en el oplog contra la instantánea restaurada, devolviendo la base de datos a una marca de tiempo deseada. Esta funcionalidad crítica es la que hace posible la recuperación a un punto en el tiempo para las implantaciones autogestionadas.

La bandera de repetición de oplog(–oplogReplay) obliga a mongorestore a aplicar directamente cualquier entrada de oplog incluida en el volcado una vez finalizado el proceso de restauración del documento. Esta opción es posible gracias al uso de una bandera específica(–oplog) para capturar el propio oplog junto con mongodump.

¿Cómo pueden utilizarse de forma segura las instantáneas a nivel de sistema de archivos (LVM, EBS, ZFS) con MongoDB?

El requisito de consistencia para que una copia de seguridad física de MongoDB sea válida es que los archivos de datos representen un punto de control WiredTiger limpio. La razón por la que está bien utilizar WiredTiger es que escribe datos en segundo plano y mantiene un diario. Si tomara una instantánea de los archivos de datos mientras el motor está funcionando, la instantánea sería recuperable siempre que el registro en el diario esté activado (como siempre lo está por defecto). No tiene por qué ser necesariamente una instantánea de los datos mientras Mongo está parado, pero sí tiene que ser una instantánea que sea atómica a nivel del sistema de archivos.

Cómo se consigue este nivel de atomicidad depende de la herramienta:

• Instantáneas LVM – instantáneas de copia sobre escritura de un volumen lógico; instantáneas y consistentes si los datos de MongoDB y el diario residen en el mismo volumen. Dividirlos entre volúmenes requiere realizar instantáneas de ambos simultáneamente.
• Instantáneas de Amazon EBS – instantáneas a nivel de bloque activadas a través de la API de AWS; adecuadas para MongoDB alojado en la nube con datos en volúmenes EBS. La coherencia multivolumen requiere el uso de grupos de instantáneas multivolumen de EBS.
• Envío/recepción ZFS: las instantáneas ZFS son atómicas por diseño y capturan el conjunto de datos completo en un estado coherente. Muy adecuadas para implantaciones locales en las que ZFS es el sistema de archivos subyacente.

El único escenario que puede considerarse inseguro en estas circunstancias es cuando MongoDB se utiliza sin registro en el diario en un sistema de archivos que no sea ZFS. Afortunadamente, ese tipo de configuración es poco frecuente en las implantaciones actuales, pero aún así merece la pena volver a comprobarlo antes de confiar en las copias de seguridad de MongoDB basadas en instantáneas durante la producción.

¿Existen herramientas de copia de seguridad de terceros y qué características ofrecen?

Varias soluciones de terceros complementan o proporcionan una alternativa a las funciones integradas de copia de seguridad de MongoDB, especialmente en entornos empresariales autogestionados en los que no se utiliza Atlas:

• Percona Backup for MongoDB (PBM) – de código abierto, admite copias de seguridad lógicas y físicas, recuperación de repeticiones oplog y coordinación de clústeres fragmentados. La alternativa autoalojada más capaz a Atlas Backup.
• Bacula Enterprise – plataforma de copia de seguridad para empresas con integración de MongoDB mediante scripts pre/post job y compatibilidad con plugins; sólidas funciones de registro de auditoría y cumplimiento de normativas para entornos regulados.
• Ops Manager (MongoDB) – plataforma de gestión local propia de MongoDB que incluye copias de seguridad continuas con restauración puntual basada en oplog; requiere una implantación independiente de Ops Manager.
• Dbvisit Replicate – herramienta de captura de datos de cambios que puede cumplir una función de copia de seguridad para MongoDB transmitiendo los cambios a un destino secundario.
• Servicios de instantáneas nativos de la nube: AWS Backup, Azure Backup y Google Cloud Backup admiten instantáneas a nivel de volumen que pueden incluir directorios de datos de MongoDB cuando se configuran correctamente.

Un punto de partida común para la mayoría de los despliegues autogestionados que no cuentan con una plataforma de copia de seguridad empresarial existente es Percona Backup for MongoDB. Es de uso gratuito, se desarrolla activamente y cuenta con las funciones básicas necesarias para el flujo de trabajo completo de copia de seguridad y restauración de bases de datos MongoDB.

¿Cómo se puede integrar la copia de seguridad de MongoDB con Bacula Enterprise para la protección de la empresa?

Bacula Enterprise es una solución integral de copia de seguridad que permite a las organizaciones centralizar la protección de datos en entornos heterogéneos compuestos por servidores físicos, máquinas virtuales, instancias en la nube y bases de datos.

La integración de la copia de seguridad de MongoDB con Bacula se consigue mediante scripts previos y posteriores al trabajo. Bacula inicia un mongodump o una instantánea del sistema de archivos antes de realizar la copia de seguridad de los archivos generados y, a continuación, realiza acciones de retención de datos, cifrado y transferencia remota de acuerdo con la política preconfigurada.

Lo que Bacula aporta a una estrategia de protección de datos MongoDB que las herramientas nativas no proporcionan:

• Programación y aplicación de políticas centralizadas – los trabajos de copia de seguridad de MongoDB se ejecutan en el mismo marco de programación y retención que cualquier otra carga de trabajo del entorno, lo que elimina la incoherencia que se deriva de los trabajos cron gestionados por equipos.
• Registros de auditoría e informes de cumplimiento – cada trabajo de copia de seguridad se registra con marcas de tiempo, estado de éxito y volumen de datos, produciendo el registro verificable que requieren las industrias reguladas
• Almacenamiento y transporte cifrados – los datos se cifran por defecto en reposo y en tránsito, y la gestión de claves se realiza a nivel de plataforma en lugar de por base de datos.
• Alertas y escalado de fallos – los trabajos de copia de seguridad de MongoDB fallidos salen a la superficie a través de la misma canalización de alertas que los fallos de la infraestructura, en lugar de pasar desapercibidos en un registro de secuencias de comandos.
• Compatibilidad con copias en varios sitios y en el aire – Bacula admite cintas, almacenamiento de objetos y objetivos en sitios remotos, lo que resulta valioso para las organizaciones que requieren copias de seguridad de MongoDB fuera de línea o en el aire como parte de su postura de protección frente al ransomware.

También es una transición sin problemas para las organizaciones que ya confían en Bacula Enterprise para sus necesidades de copia de seguridad. En lugar de construir otra infraestructura de copia de seguridad independiente, el proceso de copia de seguridad de MongoDB se integra fácilmente en el sistema existente, lo que se traduce en una reducción significativa de la proliferación de herramientas y de la complejidad de la gestión.

¿Cómo realizar una copia de seguridad segura para diferentes topologías de MongoDB?

Un método de copia de seguridad de MongoDB adecuado para un único servidor no garantiza necesariamente la integridad y la ausencia de interrupciones del servicio cuando se aplica a un conjunto de réplicas o a un clúster fragmentado sin adaptar. Una de las principales razones para ello es un gran número de factores que cambian en función de la topología MongoDB elegida .

¿Cómo hacer una copia de seguridad de un conjunto de réplicas sin afectar a la disponibilidad?

La copia de seguridad de su conjunto de réplicas se basa en un único principio fundamental: nunca realice una copia de seguridad que consuma muchos recursos contra el primario cuando pueda evitarlo. El primario recibe todo el tráfico de escritura, y un proceso de copia de seguridad que lucha por su E/S es la fuente de latencia que sienten todos los usuarios de la aplicación. La mejor opción es un secundario dedicado -configurado como miembro oculto, idealmente, para que no reciba tráfico y sólo exista para tareas operativas como la copia de seguridad.

El proceso seguro de copia de seguridad del conjunto de réplica sigue este orden

1. Verifique el retardo de replicación en el secundario de destino antes de comenzar. Un secundario rezagado produce una copia de seguridad que no refleja el estado actual de los datos – compruebe rs.printSecondaryReplicationInfo() y confirme que el rezago está dentro de límites aceptables.
2. Seleccione un secundario oculto o de baja prioridad como destino de la copia de seguridad para evitar tirar de la capacidad de lectura de los miembros que sirven a la aplicación.
3. Inicie la copia de seguridad – ya sea mongodump o una instantánea del sistema de archivos- contra el directorio de datos o el punto final de conexión del secundario.
4. Capture el oplog junto con la copia de seguridad si se requiere una recuperación puntual. Utilice –oplog con mongodump, o registre el rango de marcas de tiempo de oplog que corresponda a la ventana de la instantánea.
5. Verifique la copia de seguridad antes de eliminar las copias antiguas. Una copia de seguridad que nunca se ha comprobado no es una copia de seguridad, es una suposición.

También hay un caso límite interesante que merece la pena señalar: si todos los secundarios se retrasan debido a un pico en el tráfico de escritura, puede ser mejor retrasar la copia de seguridad por completo en lugar de arriesgarse a crear una instantánea incoherente.

¿Cómo se hace una copia de seguridad de un clúster fragmentado y se coordina la coherencia a nivel de clúster?

La copia de seguridad de un clúster fragmentado es el escenario de copia de seguridad de MongoDB más complicado de gestionar. Esto se debe a que necesita alcanzar un punto consistente en el tiempo a través de múltiples conjuntos de réplicas que se ejecutan en diferentes momentos independientemente unas de otras. Cada shard tiene su propio oplog y su propio estado, y el conjunto de réplica del servidor de configuración es donde se almacenan los metadatos del cluster que mapean los chunks a los shards. Una copia de seguridad que consiga capturar shards en diferentes momentos es inútil por defecto, ya que crea una imagen de clúster incoherente.

El proceso de coordinación en este caso requiere los siguientes pasos:

• Detenga el equilibrador de fragmentos utilizando sh.stopBalancer() antes de que comience cualquier actividad de copia de seguridad. Un equilibrador activo migra chunks entre shards durante la copia de seguridad, lo que produce un estado en el que el mismo documento podría aparecer en dos instantáneas de shard o en ninguna.
• Desactive cualquier migración de fragmentos programada mientras dure la ventana de copia de seguridad para evitar que el reequilibrio automático se reanude a mitad de la captura.
• Realice primero la copia de seguridad del conjunto de réplicas del servidor config. El servidor de configuración contiene el mapa de trozos autorizado – capturarlo antes que los fragmentos garantiza que los metadatos reflejen el estado del clúster previo a la copia de seguridad.
• Capture cada conjunto de réplicas de fragmentos utilizando el mismo proceso de primero secundario descrito anteriormente, tan cerca en el tiempo como sea operacionalmente posible.
• Registre la marca de tiempo oplog de cada shard en el punto de captura. Estas marcas de tiempo son necesarias si la restauración puntual necesita alinear los estados de los fragmentos durante la recuperación.
• Vuelva a habilitar el equilibrador una vez que se confirme que todas las copias de seguridad de los fragmentos se han completado.

MongoDB Atlas realiza todo esto para los clústeres sharded alojados en Atlas de forma automática. En cuanto a los entornos autogestionados, Percona Backup for MongoDB tiene la opción de realizar una copia de seguridad coordinada del clúster fragmentado sin necesidad de gestionar manualmente el equilibrador.

¿Cómo se garantiza la coherencia de las copias de seguridad cuando se utiliza journaling y WiredTiger?

El motor WiredTiger (motor de almacenamiento por defecto para MongoDB) escribe los datos mediante una combinación de checkpoint y journaling. Al menos una vez cada 60 segundos (o siempre que el diario alcance un determinado umbral de tamaño), WiredTiger escribe un punto de control consistente en el disco. Todas las escrituras en disco se registran en el diario entre los puntos de control. De este modo, los archivos de datos + el diario contendrán siempre todo el estado recuperable del sistema.

Para las copias de seguridad de MongoDB basadas en instantáneas, esto significa que una instantánea del sistema de archivos tomada en cualquier punto mientras el registro en el diario está activado puede restaurarse de forma segura a partir de ella. La instantánea puede aterrizar entre dos puntos de control, pero WiredTiger reproducirá el diario automáticamente al arrancar para alcanzar la consistencia.

El único requisito aquí es que tanto el diario como el directorio de datos deben estar en la misma operación de instantánea. No está bien tomar una instantánea separada del directorio de datos y otra instantánea del directorio del diario – esto rompe la garantía de recuperación.

¿Cuáles son los pasos para restaurar MongoDB a partir de copias de seguridad?

Una estrategia de copia de seguridad de la que nunca se ha restaurado no está probada por definición. El proceso de restauración merece el mismo nivel de documentación y práctica que el proceso de copia de seguridad, ya que todos los momentos en los que se necesita nunca son tranquilos.

¿Cómo se restaura una base de datos de copia de seguridad de MongoDB y se conservan los usuarios y los roles?

La información sobre usuarios y roles en MongoDB está contenida en la base de datos de administración , y no con las colecciones que gobiernan. Una operación mongorestore contra una base de datos específica no restaurará los usuarios y roles de esa base de datos. Una restauración completa (que también reescribe la base de datos admin ) puede eliminar usuarios existentes o duplicar otros conflictivos sin saberlo.

El proceso de restauración más seguro con preservación de usuarios y roles consiste en:

1. Detenga todas las conexiones de aplicaciones a la instancia de destino antes de iniciar la restauración. Las conexiones activas durante una restauración crean condiciones de carrera entre las escrituras entrantes y el proceso de restauración.
2. Restaure primero la base de datos de destino, excluyendo la base de datos admin : mongorestore –db <nombre_de_base_de_datos> –drop <dump_path>/<nombre_de_base_de_datos>.
3. Inspeccione la base de datos admin volcada antes de restaurarla -en concreto las colecciones system.users y system.roles- para confirmar que no existen conflictos con los usuarios existentes en la instancia de destino.
4. Restaure los usuarios y roles de forma selectiva utilizando mongorestore –db admin –collection system.users y system.roles en lugar de restaurar toda la base de datos admin de una sola vez.
5. Verifique las asignaciones de roles tras la restauración ejecutando db.getUsers() y confirmando que las cuentas del servicio de aplicaciones tienen los privilegios esperados.
6. Vuelva a habilitar las conexiones de la aplicación sólo después de completar la verificación.

Se recomienda utilizar el indicador –drop (eliminar cada colección antes de la restauración) cuando realice una restauración completa. Sin embargo, debe utilizarse con precaución cuando restaure en una instancia que ya contiene los datos que desea conservar.

¿Cómo se restaura una instantánea física y se devuelven los miembros a un conjunto de réplica?

Hay dos pasos separados en la restauración de una instantánea física: primero hay que restaurar los archivos de datos y después hay que volver a añadir el nodo al conjunto de réplica.

Considerar esto como un único proceso suele ser la causa de muchos problemas.

Fase 1 – Restauración de la instantánea:

1. Detenga completamente el proceso mongod en el nodo de destino antes de tocar ningún archivo de datos.
2. Borre el directorio de datos existente para evitar que WiredTiger encuentre archivos de almacenamiento conflictivos al iniciarse.
3. Monte o copie la instantánea en el directorio de datos, asegurándose de que tanto los archivos de datos como el directorio del diario están presentes e intactos.
4. Inicie mongod en modo autónomo – sin el indicador –replSet – para permitir que WiredTiger complete su pasada de recuperación y alcance un punto de control limpio antes de que se reanuden las operaciones de replica set.

Fase 2 – Reintegración en el conjunto de réplica:

1. Apague el mongod autónomo una vez que el pase de recuperación se complete limpiamente.
2. Reinicie mongod con el indicador–replSet restaurado a su nombre de conjunto de réplica original.
3. Añada de nuevo el miembro utilizando rs.add() desde el primario si fue eliminado, o permita que se reincorpore automáticamente si sólo estaba temporalmente desconectado.
4. Supervise el progreso de la sincronización inicial: si la instantánea es lo suficientemente reciente, el miembro aplicará sólo las entradas del oplog que haya omitido en lugar de realizar una sincronización inicial completa desde cero.

Nota importante: una instantánea más antigua que la ventana de retención del oplog va a desencadenar un proceso de sincronización inicial completo independientemente de otras circunstancias, lo que puede ser un proceso interminable cuando se trata de conjuntos de datos grandes y complejos.

¿Cómo se realiza una restauración puntual utilizando copias de seguridad oplog o en la nube?

La restauración puntual es un proceso en dos etapas, independientemente de si se realiza mediante la reproducción de oplog en un clúster autogestionado o a través de la interfaz Atlas. El primer paso prepara el escenario, tomando una instantánea completa del estado del clúster antes del punto de recuperación. El segundo paso toma esa instantánea y la hace avanzar reproduciendo sólo las operaciones entre la instantánea y la marca de tiempo objetivo.

Para la recuperación autogestionada basada en oplog, mongorestore acepta la bandera –oplogReplay junto a un volcado que se capturó con –oplog. La bandera –oplogLimit especifica el techo de la marca de tiempo -en segundos desde la época- más allá del cual las entradas oplog ya no se aplican. Identificar la marca de tiempo correcta requiere inspeccionar los registros oplog o de aplicación para localizar la última operación «buena» antes del evento que desencadenó la restauración.

En el caso de la restauración puntual de Atlas, todo el proceso se lleva a cabo mediante la interfaz de usuario o la API de Atlas. Se selecciona una marca de tiempo de destino dentro de la ventana de retención, Atlas construye la restauración internamente y el clúster recuperado se aprovisiona como una instancia nueva. El clúster original no se sobrescribe por defecto, preservando su capacidad de comparar estados antes de comprometerse con el punto de recuperación.

En ambos escenarios, el único paso que todos los equipos tienden a saltarse cuando están bajo presión es la verificación del estado recuperado, antes de dar de baja la máquina de producción. Este paso es también el que descubre índices omitidos, permisos de usuario incorrectos y recuperaciones incompletas antes de llegar a producción.

¿Cómo se gestionan los desajustes de versión entre la copia de seguridad y las versiones de MongoDB de destino?

Existe un peligro real al restaurar una copia de seguridad de MongoDB de un rango de versiones a otro. El formato de almacenamiento de WiredTiger puede cambiar, al igual que el esquema oplog y los indicadores de compatibilidad de funciones, lo que puede provocar que la copia de seguridad no se complete o que la base de datos se inicie pero no funcione correctamente.

Algunos de los ejemplos más comunes de escenarios de restauración son:

El indicador de versión de compatibilidad de características (FCV ) es el mecanismo que utiliza MongoDB para restringir el acceso a características específicas de una versión. Una base de datos restaurada a partir de una copia de seguridad 6.0 en una instancia 7.0 comenzará con FCV establecido en 6.0, restringiendo el acceso a características exclusivas de 7.0 hasta que se ejecute explícitamente setFeatureCompatibilityVersion .

No actualice FCV hasta que la base de datos restaurada haya sido validada – no se puede volver atrás una vez establecida.

Siempre que el desajuste de versiones sea inevitable, es mejor restaurar los datos en un sistema con la misma versión que la fuente de la copia de seguridad, validar los datos y, a continuación, realizar una actualización estándar in situ.

¿Cómo automatizar y programar las copias de seguridad de MongoDB de forma fiable?

Una copia de seguridad de MongoDB que requiere que alguien la ponga en marcha no es una estrategia. Es un hábito, y los hábitos sobre los procesos manuales de copia de seguridad suelen olvidarse durante las emergencias. La automatización elimina el elemento humano de esta ecuación, pero sólo puede ser útil si sobrevive a las situaciones que hacen necesarias las copias de seguridad: un servidor muy cargado, una red poco fiable o un problema de infraestructura.

¿Qué patrones de programación minimizan la carga y cumplen su RTO/RPO?

La programación de las copias de seguridad es siempre un compromiso entre frecuencia e impacto. Ejecutar un mongodump en un primario con mucha escritura cada hora ayuda a cumplir los agresivos RPO, pero también hace que las copias de seguridad compitan con el tráfico de producción por el mismo rendimiento de E/S. La solución aquí no es realizar menos copias de seguridad, sino enfocarlas de una forma más inteligente.

La regla número uno es realizar las copias de seguridad durante las horas no punta. En la mayoría de los casos, esto significa a última hora de la noche o a primera hora de la mañana en la zona horaria de los usuarios principales. Sin embargo, hay ciertas excepciones que pueden no tener un «periodo tranquilo» en absoluto, como las plataformas analíticas, las aplicaciones financieras o las aplicaciones distribuidas globalmente. Para estas situaciones, descargar las copias de seguridad a un secundario replicado es un paso esencial en lugar de ser opcional.

La regla número dos es alinear los tipos de copias de seguridad y su frecuencia. Ejecutar copias de seguridad completas es caro: realizarlas diaria o semanalmente es más que suficiente en la mayoría de los casos. Las copias de seguridad incrementales de MongoDB o los procesos de archivado oplog rellenan los huecos entre las copias de seguridad completas – normalmente se realizan cada hora o incluso de forma continua sin ningún impacto notable en el rendimiento.

Teniendo esto en cuenta, podemos formar una breve tabla con las sugerencias para las diferentes opciones de frecuencia de las copias de seguridad:

¿Cómo pueden hacerse resilientes e idempotentes las herramientas de orquestación, los scripts o los cron jobs?

La condición de fallo más frecuentemente observada en un proceso de automatización de copias de seguridad y restauración de MongoDB de cosecha propia es un script que falla silenciosamente. Un cron job que existe con un código distinto de cero, no escribe ningún dato en el destino y no alerta puede pasar desapercibido durante días o incluso semanas. El primer indicio de un trabajo de este tipo suele ser el fallo de una operación de restauración que no encuentra los datos que debe restaurar.

La capacidad de recuperación comienza con la gestión explícita de los fallos. Cada script de copia de seguridad debe comprobar que la salida que produjo no está vacía y dentro de un rango de tamaño esperado antes de salir con éxito. Un mongodump que se complete pero escriba un archivo casi vacío -lo que ocurre cuando los problemas de conexión interrumpen la exportación a mitad de camino- debe tratarse como un fallo, no como un éxito. Los códigos de salida por sí solos no son suficientes.

La idempotencia importa cuando las copias de seguridad forman parte de una cadena de orquestación más amplia. Un trabajo de copia de seguridad que es seguro ejecutar dos veces sin preocuparse de producir un duplicado o artefactos conflictivos es mucho más fácil de recuperar si un planificador lo dispara dos veces debido a un solapamiento temporal o a la lógica de reintento. Esto crea la necesidad de tener una salida de escritura a destinos con nombres únicos – nombres de archivo con marca de tiempo o claves de almacenamiento de objetos – mientras se utilizan operaciones atómicas de movimiento en lugar de escribir directamente en la ruta final. Una copia de seguridad parcialmente escrita que se encuentra en la ruta de destino (indistinguible de una completa) es uno de los modos de fallo más insidiosos en toda la canalización de copia de seguridad y restauración de MongoDB.

Cuando se trata de equipos con herramientas de infraestructura existentes, herramientas como Ansible, Kubernetes CronJobs y Airflow pueden ofrecer entornos de ejecución mucho más observables y controlables en comparación con cron en bruto. Ofrecen una lógica de reintento integrada, un historial de ejecución y ganchos de alerta que el cron básico simplemente no tiene.

¿Cómo se supervisan los trabajos de copia de seguridad y se alerta de los fallos?

La supervisión de un proceso de copia de seguridad de MongoDB no sólo se limita a comprobar si el trabajo se ha ejecutado. Un trabajo que se ejecuta pero genera una copia de seguridad corrupta o incompleta es mucho peor que un trabajo que falla estrepitosamente, porque sólo la primera situación crea una sensación de falsa confianza. Las métricas que merece la pena seguir en estas situaciones son:

• Los trabajos de copia de seguridad informan de su éxito pero el tamaño del archivo de salida ha disminuido significativamente en comparación con la ejecución anterior – un signo de captura parcial o de interrupción de la conexión a mitad del volcado.
• La duración de la copia de seguridad ha aumentado sustancialmente sin un aumento correspondiente en el volumen de datos – a menudo un indicador temprano de contención de E/S o retraso de replicación en el secundario de origen.
• La ubicación de almacenamiento de destino no ha recibido una nueva copia de seguridad dentro de la ventana esperada – capta los casos en los que el propio programador ha fallado o el trabajo se ha omitido silenciosamente.
• Los resultados de las pruebas de restauración, que deben ejecutarse contra una copia de seguridad de muestra con una cadencia regular, muestran errores o producen una base de datos que no supera las comprobaciones de validación a nivel de aplicación.

Las alertas para estas condiciones deben enviarse a la misma canalización de guardia que las alertas de infraestructura, no a una bandeja de entrada separada que sólo se comprueba esporádicamente.

¿Cómo afectan la seguridad y el cumplimiento a las prácticas de copia de seguridad de MongoDB?

Una copia de seguridad es un duplicado de los datos críticos que se almacena en una ubicación fuera de los límites de seguridad de la base de datos de producción. Todos y cada uno de los controles de acceso, niveles de encriptación y auditoría deben ser al menos tan seguros -si no más- como la base de datos de producción.

¿Cómo deben cifrarse las copias de seguridad en reposo y en tránsito?

El cifrado en reposo garantiza que los archivos de copia de seguridad almacenados en disco, cinta o almacenamiento de objetos sean ilegibles sin la clave de descifrado correspondiente.

Para los archivos de copia de seguridad de MongoDB escritos en el almacenamiento de objetos, esto significa activar el cifrado del lado del servidor en el bucket de destino – AES-256 a través de AWS S3, Google Cloud Storage o Azure Blob Storage – o cifrar el archivo de copia de seguridad antes de que abandone el sistema de origen (con una herramienta como GPG). La clave de cifrado debe almacenarse por separado de la propia copia de seguridad; una clave almacenada junto a los datos que protege no ofrece ninguna protección significativa.

El cifrado en tránsito garantiza que los datos de la copia de seguridad que se mueven entre la instancia de MongoDB, el agente de copia de seguridad y el destino de almacenamiento no puedan ser interceptados.

TLS debe aplicarse en todas las conexiones mongodump utilizando la bandera –tls y la configuración del certificado correspondiente. En el caso de las soluciones de copia de seguridad gestionadas por la plataforma, como Atlas Backup o Bacula Enterprise, el cifrado del transporte lo gestiona la plataforma, pero aun así merece la pena comprobar que la configuración impone TLS en lugar de simplemente admitirlo como opción.

¿Cómo controlar el acceso a las copias de seguridad y aplicar el mínimo privilegio?

Los archivos de copia de seguridad de MongoDB deberían tener los mismos controles de acceso que la base de datos de producción. Es importante intentar restringir al máximo el número de usuarios y aplicaciones que pueden leer/escribir o borrar los archivos de copia de seguridad utilizando las siguientes medidas:

• Los cubos o volúmenes de almacenamiento de las copias de seguridad deberían denegar el acceso público por defecto, concediendo acceso únicamente a las cuentas de servicio y roles IAM específicos que requiera la canalización de las copias de seguridad.
• El acceso humano a los archivos de copia de seguridad debería requerir una aprobación explícita y quedar registrado: las pruebas de restauración rutinarias deberían utilizar una cuenta de restauración dedicada con menos privilegios en lugar de credenciales administrativas.
• Los permisos de escritura y borrado en los destinos de las copias de seguridad deben estar separados – el sistema que crea las copias de seguridad no debe tener la capacidad de borrarlas, lo que limita el radio de explosión de un agente de copias de seguridad comprometido.
• Los registros de acceso a las copias de seguridad deben conservarse independientemente de los propios archivos de copia de seguridad, de modo que el historial de acceso sobreviva aunque se borren las copias de seguridad.
• Siempre que sea posible, debe utilizarse el almacenamiento cruzado entre cuentas o proyectos, para garantizar que un entorno de producción comprometido no conceda automáticamente acceso a los datos de las copias de seguridad.

¿Cómo afectan las políticas de retención y los requisitos de eliminación de datos a la estrategia de copia de seguridad?

La política de retención en las copias de seguridad tira en dos direcciones opuestas. El aspecto operativo sugiere una preferencia hacia un periodo de retención de copias de seguridad muy largo: cuanto más atrás se pueda restaurar, más opciones de copia de seguridad habrá. El aspecto de cumplimiento (GDPR, CCPA, HIPAA) sugiere una preferencia por el borrado – si un usuario solicita que se borren datos del sistema en vivo, entonces deben borrarse también de las copias de seguridad.

Esto crea una auténtica tensión para la estrategia de copia de seguridad de MongoDB. Una copia de seguridad inmutable que no pueda modificarse ni borrarse satisface los requisitos de protección contra ransomware pero entra en conflicto con el derecho de borrado.

La resolución práctica es un modelo de retención por niveles: copias de seguridad a corto plazo que son mutables y están sujetas a solicitudes de borrado, y copias de seguridad de archivo a largo plazo que contienen datos anonimizados o seudonimizados en los que los registros individuales han sido depurados antes de ser archivados. Implementar esto requiere que la canalización de copias de seguridad sea consciente de la clasificación de los datos -qué colecciones contienen datos personales y cuáles no- en lugar de tratar toda la salida de copias de seguridad de MongoDB como equivalente.

¿Cómo se aplican las copias de seguridad inmutables y la protección contra ransomware a MongoDB?

Los ransomware que tienen como objetivo la infraestructura de copias de seguridad se centran en destruir las opciones de recuperación antes del despliegue de la carga útil del ransomware. Si el atacante tiene la capacidad de borrar o cifrar los archivos de las copias de seguridad, se destruye la principal defensa contra el pago de un rescate. Las copias de seguridad inmutables (archivos que no pueden modificarse ni borrarse durante un tiempo determinado) son una de las varias opciones a la hora de eliminar esa posibilidad.

Los mecanismos que hacen cumplir la inmutabilidad en la capa de almacenamiento incluyen:

• El bloqueo de objetos S3 en modo de cumplimiento impide la eliminación o sobrescritura de objetos de copia de seguridad durante el periodo de retención configurado, incluso por parte del propietario de la cuenta o de usuarios administrativos.
• El almacenamiento WORM (Write Once Read Many) en los sistemas locales proporciona una protección equivalente para la infraestructura de copia de seguridad basada en cinta y disco.
• Las cuentas en la nube o unidades organizativas separadas para el almacenamiento de copias de seguridad garantizan que las credenciales comprometidas en el entorno de producción no concedan acceso a la cuenta de copias de seguridad.

¿Cómo pueden las copias de seguridad air-gapped u offline reducir el impacto de las brechas?

Una copia de seguridad air-gapped está física o lógicamente desconectada de cualquier red a la que un atacante pudiera acceder desde el entorno de producción.

Para las copias de seguridad de MongoDB, esto suele significar la exportación periódica a cinta, disco sin conexión o un entorno en la nube sin acceso programático desde los sistemas de producción. El punto de recuperación de una copia de seguridad en el aire está limitado por la frecuencia con la que se cruza la brecha para escribir nuevos datos -las transferencias diarias o semanales son habituales-, lo que hace que las copias en el aire sean las más apropiadas para actuar como capa de recuperación de último recurso en lugar de ser el motor principal del flujo de trabajo de recuperación de la base de datos.

La compensación aquí también es deliberada: una copia de seguridad más lenta y menos frecuente que sobrevive a un compromiso total de la infraestructura es más valiosa en el peor de los casos que una copia de seguridad continua que se encripta junto a todo lo demás.

¿Cuáles son las mejores prácticas para las copias de seguridad de MongoDB en producción?

Las secciones anteriores cubren estrategias, herramientas y procedimientos individuales de forma aislada. Las mejores prácticas son las que los mantienen unidos en un entorno de producción: las normas mínimas, los requisitos de documentación y las métricas de salud que garantizan que una arquitectura de copias de seguridad de MongoDB siga siendo fiable a lo largo del tiempo en lugar de degradarse silenciosamente a medida que la infraestructura y los equipos cambian y evolucionan.

¿Qué políticas mínimas debería tener todo despliegue de producción?

La política mínima aceptable de copias de seguridad de MongoDB depende de la criticidad del despliegue. Un entorno de desarrollo y una base de datos de producción regulada no requieren los mismos controles, pero ambos requieren algo deliberado y probado. La siguiente tabla define los requisitos básicos por nivel de despliegue:

Hay dos requisitos que se aplican universalmente, independientemente del nivel. En primer lugar, toda copia de seguridad debe almacenarse en una ubicación separada de la instancia que protege: una copia de seguridad que vive en el mismo disco que la base de datos de la que hace copia no es una copia de seguridad, sino una copia. En segundo lugar, toda estrategia de copia de seguridad debe incluir al menos una restauración probada antes de considerarse operativa. Una configuración que nunca se ha restaurado con éxito es una suposición, no una política.

¿Cómo se documentan los procedimientos de copia de seguridad y restauración para los equipos de guardia?

La documentación de las copias de seguridad que sólo existe en la cabeza del ingeniero que las creó fracasa en el momento en que ese ingeniero se vuelve ilocalizable, que suele ser el momento exacto en que más se les necesita. Los runbooks deben escribirse para el ingeniero que nunca ha tocado este sistema antes – ya que es completamente posible que sea éste el que ejecute una restauración a las 2 de la mañana después de un incidente.

Una documentación eficaz de copia de seguridad y restauración de la base de datos MongoDB incluye:

• La ubicación de cada destino de la copia de seguridad: nombres de los buckets de almacenamiento, rutas y métodos de acceso, con instrucciones sobre cómo autenticarse contra ellos desde un entorno limpio.
• Los comandos exactos necesarios para iniciar una restauración , incluidos los indicadores, las cadenas de conexión y cualquier variable de entorno que deba establecerse antes de que comience la restauración
• Los resultados esperados de una restauración correcta: qué aspecto tiene un inicio de mongod en buen estado, qué colecciones hay que comprobar y cómo validar que las cuentas de usuario y los índices están intactos.
• Modos de fallo conocidos y sus resoluciones – errores de desajuste de versión, síntomas de restauración parcial y qué hacer si la copia de seguridad más reciente está dañada
• Contactos de escalada – a quién llamar si el procedimiento documentado no resuelve el incidente, incluidos los contactos de soporte del proveedor para Atlas, Bacula o cualquier plataforma que se esté utilizando

La documentación debe estar en un lugar accesible durante una interrupción de la infraestructura – no exclusivamente en un wiki que funcione en la misma plataforma que acaba de caerse.

¿Qué métricas y SLA deben seguirse para la salud de las copias de seguridad?

La salud de las copias de seguridad se mide utilizando múltiples métricas operativas. Un canal de copias de seguridad que técnicamente funciona pero produce resultados degradados -archivos más pequeños de lo esperado, duración creciente, ventanas perdidas- está fallando lentamente, y ese fallo sólo se hará visible en el peor momento posible. Las siguientes métricas proporcionan una alerta temprana:

Estas métricas deben rastrearse en la misma plataforma de observabilidad utilizada para la supervisión de la infraestructura, no en una hoja de cálculo ni revisarse manualmente. Las alertas automatizadas sobre el incumplimiento de los umbrales garantizan que una canalización de copias de seguridad de MongoDB que se esté degradando se trate con la misma urgencia que un servicio de producción que se esté degradando, en lugar de descubrirse a posteriori.

Puntos clave

• Su topología de despliegue en MongoDB (independiente, conjunto de réplicas o clúster fragmentado) determina qué métodos de copia de seguridad tiene a su disposición.
• Defina su RTO y RPO antes de seleccionar cualquier herramienta: son los requisitos a los que debe servir cualquier otra decisión.
• MongoDB Atlas Backup es la opción gestionada más sencilla; Percona Backup for MongoDB (PBM) es la mejor alternativa autoalojada.
• El almacenamiento de las copias de seguridad debe estar cifrado, tener el acceso controlado y ser inmutable: trátelo con el mismo rigor de seguridad que la producción.
• Supervise los trabajos de copia de seguridad en función de su tamaño y duración, no sólo de si se han completado.
• Una copia de seguridad que nunca se ha restaurado es una suposición – pruebe y documente sus procedimientos de restauración con regularidad.

Conclusión

La copia de seguridad y restauración de MongoDB no es un proceso que pueda activarse una vez y olvidarse inmediatamente – es una disciplina operativa continua que abarca la selección de herramientas, la programación, la seguridad, la documentación y las pruebas regulares. La estrategia correcta para una instancia de desarrollo independiente no se parece en nada a la estrategia correcta para un clúster de producción fragmentado que sirve datos regulados, y la brecha entre esos dos contextos es de donde proceden la mayoría de los fallos en las copias de seguridad.

Las organizaciones que se recuperan limpiamente de los eventos de pérdida de datos no son las que tienen las herramientas de copia de seguridad más sofisticadas – son las que probaron sus procedimientos de restauración antes de necesitarlos, documentaron esos procedimientos para las personas que no estaban en la sala cuando se construyó el sistema, y trataron la salud de la copia de seguridad como una métrica operativa de primera clase en lugar de una idea tardía.

Preguntas frecuentes

¿Las copias de seguridad de MongoDB pueden ser consistentes a través de arquitecturas de microservicios?

Lograr una copia de seguridad consistente a través de microservicios que mantienen cada uno su propia base de datos MongoDB requiere coordinar las marcas de tiempo de las instantáneas a través de todos los servicios simultáneamente – un problema de orquestación no trivial. En la práctica, la mayoría de los equipos aceptan la consistencia eventual entre las copias de seguridad a nivel de servicio y confían en la lógica de reconciliación a nivel de aplicación para manejar las lagunas, en lugar de intentar una única copia de seguridad atómica entre servicios.

¿Cómo realizar copias de seguridad de despliegues MongoDB multi-tenant de forma segura?

Las implantaciones multiinquilino que aíslan a los inquilinos por base de datos pueden respaldarse selectivamente utilizando el indicador –db de mongodump, lo que permite la restauración por inquilino sin tocar los datos de otros inquilinos. Los despliegues que ubican los datos de los inquilinos en colecciones compartidas requieren una lógica de exportación a nivel de aplicación para lograr el mismo aislamiento, ya que mongodump opera a nivel de colección y no puede filtrar por campo de inquilino de forma nativa.

¿Cómo cambian las implantaciones de MongoDB en contenedores y basadas en Kubernetes la estrategia de copia de seguridad?

Los despliegues de MongoDB basados en Kubernetes -que suelen gestionarse a través del Operador Kubernetes de MongoDB o un StatefulSet- introducen una infraestructura efímera que hace que las suposiciones de instantáneas del sistema de archivos no sean fiables. El enfoque recomendado es utilizar copias de seguridad lógicas a través de mongodump activadas como Kubernetes CronJobs, o desplegar Percona Backup for MongoDB junto al clúster, que está diseñado para operar de forma nativa en entornos en contenedores con soporte de volúmenes persistentes.