Copia de seguridad y restauración de MongoDB (mongodump, mongorestore, snapshot)

Configura la rutina de copias de seguridad de un MongoDB instalado y describe, escenario por escenario, la restauración desde copia de seguridad. Copia de seguridad: mongodump de una sola collection, una base de datos o todo el deployment (--archive --gzip; en un replica set, punto consistente con --oplog y lectura desde un secondary), archivo de credenciales, copias programadas con periodo de retención mediante systemd timer/cron, restauración de prueba y snapshot opcional del sistema de archivos. Restauración: ensayo de restauración, restauración completa, una sola base de datos/collection, recuperación a un momento concreto con copia de seguridad + oplog, clonado a otro cluster y sharded cluster. Con cientos de GB de datos, cuando se necesita una recuperación rápida o en un sharded cluster, se prefiere un snapshot o una herramienta empresarial (PBM, Ops Manager) en lugar de mongodump; la elección se explica en los primeros pasos.

Topología: Servidor de copias de seguridad o un miembro + replica set / instancia única / sharded cluster (mongos)

Escenarios

• Configurar las copias de seguridad: mongodump, programación y restauración de prueba — Usuario de copia de seguridad, archivo de credenciales, mongodump manual y programado, restauración de prueba con otro nombre; snapshot y mongoexport opcionales. Si lo configura por primera vez, empiece aquí.
• ¿Se puede restaurar realmente la copia de seguridad? (--dryRun y ensayo en una instancia temporal) — Sin tocar los datos en producción: integridad del archivo, namespaces y oplog que contiene y, opcionalmente, restauración completa en un mongod temporal con recuento de documentos.
• Restaurar todos los datos desde la copia de seguridad (restauración completa, --drop) — Los datos se han perdido o dañado en gran parte y el deployment volverá al momento en que se tomó la copia de seguridad. Las escrituras posteriores a la copia se pierden; la aplicación queda detenida durante la restauración.
• Recuperar una sola base de datos o collection (--nsInclude, con otro nombre o en su lugar) — Se eliminó o dañó una collection/base de datos y el resto está intacto: solo ese namespace se trae de la copia de seguridad; el resto de los datos no se toca y la aplicación puede seguir en servicio.
• Volver a un momento concreto: copia de seguridad + oplog (drop accidental, update/delete erróneo) — La operación errónea ocurrió después de la copia de seguridad y también se necesitan las escrituras hasta ese momento: se restaura la última copia completa y se aplica el oplog en producción hasta justo antes de la operación errónea (--oplogReplay --oplogLimit). Solo replica set.
• Restaurar la copia de seguridad en otro cluster / servidor (clonado, entorno de pruebas, migración) — No se toca el deployment de origen: la copia de seguridad se restaura en otro replica set o instancia (copia para pruebas/informes, migración de servidor, cambio de versión); los usuarios se migran de forma opcional.
• Restaurar un sharded cluster: límites de mongodump y método correcto — La topología respaldada es un sharded cluster: restauración lógica a través de mongos (recreando las shard keys, balancer) o reconstrucción física de todo el cluster a partir de snapshots coordinados.

Antes de empezar

• El servidor del que se hace la copia usa un sistema operativo soportado; el reloj está sincronizado con NTP y la zona horaria es correcta (los nombres de los archivos de copia y la programación se basan en la hora local).
• Desde este servidor se resuelven los nombres y se accede a los puertos de ….… En un replica set, los nombres de la cadena de conexión deben coincidir con los nombres de los miembros en rs.conf(); el driver se conecta a esos nombres.…
• … está en un disco distinto del disco de datos o en un recurso compartido de red, y su espacio libre es al menos el tamaño de la copia comprimida (normalmente el 20–50 % de los datos) multiplicado por el periodo de retención. Una copia en el mismo disco se pierde junto con los datos si se pierde el disco.
• La autorización está activada y dispone del usuario … (root, o los roles userAdminAnyDatabase + clusterAdmin) y de su contraseña. El usuario de copia de seguridad se crea con este usuario.
• La ventana del oplog es claramente más larga que la duración de una copia completa (al menos varias horas). --oplog recoge las entradas del oplog generadas durante la copia; si la ventana es más corta que la copia, esta falla.… En la recuperación a un momento dado, la primera entrada del oplog en producción debe ser anterior al momento en que terminó la copia completa que se va a usar; de lo contrario, las operaciones intermedias no existen en ningún sitio.…
• Hay acceso HTTPS al repo de MongoDB (repo.mongodb.org) o hay definido un mirror interno; si las herramientas ya están instaladas en el servidor, se muestran sus versiones.
• dbPath (…) está en el LV … y el volume group tiene al menos … libres. El journal de WiredTiger (…/journal) debe estar en el mismo LV; si se ha movido a otro disco, es obligatorio un fsyncLock antes del snapshot.
• Dispone de privilegios de root o sudo. Si se va a hacer una restauración completa, se han obtenido una ventana de mantenimiento y la aprobación del equipo de la aplicación.… Antes de la restauración se ha registrado el incidente (cuándo, qué operación, quién); el equipo de la aplicación sabe qué datos se van a recuperar.…
• Las copias de seguridad están configuradas con el escenario "Configurar las copias de seguridad" de esta guía: las herramientas (mongorestore, mongosh) y el archivo de credenciales … (…: backup + restore) existen en este servidor. Si no es así, aplique primero las dos primeras fases del escenario Configurar las copias de seguridad.
• La restauración vuelve a escribir datos e índices: el disco de datos de los servidores de destino tiene un espacio libre de al menos 1,5 veces los datos (sin comprimir) que se van a restaurar.… En un replica set, los secondaries reciben las mismas escrituras por replicación; la ventana del oplog se acorta durante la restauración.…
• … tiene tanto espacio libre como el tamaño sin comprimir de los datos que se van a restaurar (copia completa + oplog). El mongod temporal escucha solo en 127.0.0.1, en el puerto …; el puerto debe estar libre.
• El destino (…) está instalado y en ejecución, la autorización está activada y dispone de la contraseña del usuario … (root). La versión de destino es igual o más reciente que la de origen (p. ej. 7.0 → 8.0); no se admite restaurar en una versión anterior.

Fases de la guía

• Instalación de las herramientas — Añadir el repo de MongoDB … · Añadir el repo de MongoDB … · Instalar mongodump, mongorestore y mongosh · Preparar el directorio de copias de seguridad
• Usuario de copia de seguridad y archivo de credenciales — Crear el usuario de copia de seguridad · Escribir el archivo de credenciales (--config) · Probar la conexión
• Copia de seguridad manual (mongodump) — Comprobar el tamaño de los datos y la ventana del oplog · Detener el balancer · Hacer una copia de seguridad con mongodump · Reiniciar el balancer · Verificar la copia de seguridad (gzip y dryRun) · Copia de un subconjunto mediante consulta (--query)
• Restauración (mongorestore) — Restauración de prueba con otro nombre (--nsFrom/--nsTo) · Comparar el número de documentos · Eliminar la base de datos de prueba · Definir un rol para oplogReplay · Restauración completa en su lugar (--drop) · Revocar el privilegio temporal …
• mongoexport / mongoimport (traslado de datos, no es una copia de seguridad) — Exportar la collection (mongoexport) · Importar en una collection aparte (mongoimport) · Comparar los tipos y limpiar
• Snapshot del sistema de archivos — Tomar un LVM snapshot (con fsyncLock) · Archivar el snapshot en el directorio de copias de seguridad · Tomar una copia de archivos con fsyncLock
• Copia de seguridad de un sharded cluster: límites y vía empresarial — Elegir un método para una copia consistente de un sharded cluster
• Copia de seguridad programada y retención — Limitar el balancer para que funcione fuera de las horas de copia · Escribir el script de copia de seguridad · Hacer ejecutable el script · Preparar el acceso SSH al servidor remoto · Crear el service y el timer de systemd · Lanzar a mano la copia programada y verificarla …
• Monitorización y mantenimiento — Monitorizar la antigüedad de la última copia · Simulacros periódicos de recuperación
• 1. Diagnóstico: archivos de copia y herramientas — Listar los archivos de copia y las últimas copias por orden
• 2. Ensayo: lectura del archivo — Comprobar la integridad de la compresión (gzip -t) · Probar la restauración sin escribir datos (--dryRun) · ¿Contiene el archivo un oplog? (punto consistente)
• 3. Ensayo: restauración completa en una instancia temporal — Preparar mongod para la instancia temporal · Iniciar el mongod temporal · Restaurar la copia en la instancia temporal · Contar los datos restaurados · Detener y eliminar la instancia temporal
• 4. Después — Registrar el resultado del ensayo
• Sharded cluster: la restauración completa no se hace con este escenario — Pasar al escenario de sharded cluster
• 1. Diagnóstico: ¿es la restauración completa el escenario correcto? — Ver el estado actual y los datos afectados · Probar la restauración sin escribir datos (--dryRun)
• 2. Red de seguridad — Detener la aplicación y comprobar las conexiones · Hacer una copia del estado actual (punto de vuelta atrás)
• 3. Ejecución: restauración completa — Conceder un privilegio temporal para oplogReplay · Restaurar la copia en su lugar (--drop… --oplogReplay…) · Revocar el privilegio temporal · Limpiar las collections temporales de usuarios de la restauración
• 4. Verificación — Comprobar el número de documentos e índices · Comprobar que el replica set se ha sincronizado
• 5. Después — Hacer una nueva copia completa e iniciar la aplicación
• 1. Diagnóstico: estado actual del namespace y su estado en la copia — Ver el estado en producción · Probar la restauración sin escribir datos (--dryRun)
• 2. Red de seguridad — Hacer una copia del estado actual (punto de vuelta atrás)
• 2. Ejecución: restaurar con otro nombre — Restaurar la copia con otro nombre (--nsFrom/--nsTo) · Comparar los recuentos de la copia y de producción · Volver a añadir a producción los documentos eliminados ($merge) · Eliminar la copia temporal
• 3. Ejecución: restaurar en su lugar (--drop) — Conservar la shard key: volver a fragmentar la collection · Restaurar el namespace en su lugar
• Recuperación a un momento dado solo en un replica set — En este deployment no es posible la recuperación a un momento dado con el oplog
• 1. Diagnóstico: momento de la operación errónea y ventana del oplog — Localizar la operación errónea en el oplog · Verificar que la copia completa está dentro de la ventana del oplog
• 2. Red de seguridad: copiar el oplog en producción — Hacer una copia del oplog en producción · Hacer una copia del estado actual (punto de vuelta atrás)
• 3. Ejecución: volver a ese momento en una instancia temporal — Preparar mongod para la instancia temporal · Iniciar el mongod temporal · Restaurar la copia completa en la instancia temporal · Aplicar el oplog en producción hasta justo antes de la operación errónea · Comprobar los datos recuperados en la instancia temporal · Trasladar a producción los datos recuperados …
• 4. Después — Hacer una nueva copia completa y corregir la causa raíz
• 1. Diagnóstico: ¿es correcto y compatible el destino? — Verificar que el destino no es el origen y comprobar su versión · Probar la restauración sin escribir datos (--dryRun)
• 2. Red de seguridad y credenciales del destino — Escribir un archivo de credenciales temporal para el destino · Hacer una copia de los datos existentes en el destino