Realizar copias de seguridad y restaurar una implementación autogestionada con instantáneas del sistema de archivos
Este documento describe un procedimiento para crear copias de seguridad de servidores autónomos y set de réplicas de MongoDB utilizando herramientas a nivel de sistema, tales como LVM o dispositivo de almacenamiento, así como las estrategias de restauración correspondientes. Para obtener información sobre clústeres fragmentados, consulte "Realizar una copia de seguridad de un clúster fragmentado autoadministrado con instantáneas del sistema de archivos".
Estas instantáneas del sistema de archivos, o métodos de copia de seguridad a nivel de bloque, utilizan herramientas a nivel de sistema para crear copias del dispositivo que contiene los archivos de datos de MongoDB. Estos métodos se completan rápidamente y funcionan de forma fiable, pero requieren una configuración adicional del sistema fuera de MongoDB.
Tip
Descripción general de las instantáneas
Las instantáneas funcionan creando enlaces entre los datos en vivo y un volumen de instantáneas especial. Estos enlaces son, en teoría, equivalentes a "enlaces físicos". A medida que los datos de trabajo se separan de la instantánea, el proceso de instantáneas utiliza una estrategia de copia en escritura. Como resultado, la instantánea solo almacena los datos modificados.
Después de crear la instantánea, monta la imagen de la instantánea en tu sistema de archivos y copia los datos de la instantánea. La copia de seguridad resultante contiene una copia completa de todos los datos.
Considerations
Motor de almacenamiento WiredTiger
MongoDB admite copias de seguridad a nivel de volumen utilizando el motor de almacenamiento WiredTiger cuando los archivos de datos y los archivos de registro de la instancia de MongoDB residen en volúmenes separados. Sin embargo, para crear una copia de seguridad coherente, la base de datos debe estar bloqueada y todas las operaciones de guardar a la base de datos deben suspenderse durante el proceso de copia de seguridad.
Motor de almacenamiento cifrado (solo MongoDB Enterprise)
Para motores de almacenamiento cifrados que usan AES256-GCM El modo de cifrado, AES256-GCM requiere que cada proceso use un valor único de bloque contador con la clave.
Para el motor de almacenamiento cifrado configurado con el cifrado AES256-GCM:
- Restauración desde una copia de seguridad en caliente
- A partir de la versión 4.2, si restaura desde archivos obtenidos mediante una copia de seguridad "en caliente" (es decir, mientras
mongodestá en ejecución), MongoDB puede detectar claves "sucias" en el inicio y cambiar automáticamente la clave de la base de datos para evitar la reutilización del IV (vector de inicialización).
- Restauración desde una copia de seguridad en frío
Sin embargo, si restaura desde archivos obtenidos mediante una copia de seguridad "en frío" (es decir,
mongodno está en ejecución), MongoDB no puede detectar las claves "sucias" en el inicio, y la reutilización de IV invalida las garantías de confidencialidad e integridad.A partir de la versión 4.2, para evitar la reutilización de las claves después de restaurar desde un snapshot del sistema de archivos en frío, MongoDB agrega una nueva opción de línea de comandos
--eseDatabaseKeyRollover. Al iniciarse con la opción--eseDatabaseKeyRollover, la instanciamongodcambia las claves de la base de datos configuradas con el cifradoAES256-GCMy se cierra.
Base de datos válida en el momento de la instantánea
La base de datos debe ser válida cuando se produce la snapshot. Esto significa que todas las escrituras aceptadas por la base de datos deben guardarse completamente en disco: ya sea en el diario o en los archivos de datos.
Si hay escrituras que no están en el disco cuando ocurre la copia de seguridad, la copia de seguridad no reflejará estos cambios.
Para el motor de almacenamiento WiredTiger, los archivos de datos reflejan un estado coherente a partir del último punto de control. Los puntos de control se producen cada 2 GB de datos o cada minuto.
Stale Data
Las copias de seguridad proporcionan una snapshot del estado actual de la base de datos. Cuando restauras a partir de una copia de seguridad, la base de datos restaurada no incluye ningún cambio realizado después de que se haya hecho la copia de seguridad, lo que puede provocar pérdida de datos.
Imagen completa de discos
Las instantáneas crean una imagen de un disco completo. A menos que necesites respaldar todo tu sistema, considera aislar tus archivos de datos de MongoDB, el registro (si corresponde) y la configuración en un disco lógico que no contenga ningún otro dato.
Como alternativa, almacene todos los archivos de datos de MongoDB en un dispositivo dedicado para poder realizar copias de seguridad sin duplicar datos extraños.
Precaución Ante Fallos del Sitio
Asegúrese de copiar los datos de los snapshots en otros sistemas. Esto garantiza que los datos estén seguros ante fallas del sitio.
No hay copias de seguridad incrementales
Este tutorial no incluye procedimientos para copias de seguridad incrementales. Si bien los distintos métodos de instantáneas ofrecen distintas funciones, el método LVM descrito a continuación no permite realizar copias de seguridad incrementales.
Snapshots con registrar en la bitácora
Si su instancia tiene habilitado el registro en diario, entonces puede usar cualquier tipo de herramienta de instantáneas de nivel de volumen/bloque o de sistema de archivos para crear copias de mongod seguridad.
Si gestionas tu propia infraestructura en un sistema basado en Linux, configura tu sistema con LVM para proporcionar tus paquetes de disco y proporcionar capacidad de snapshot. También puedes usar configuraciones basadas en LVM dentro de un entorno en la nube/virtualizado.
Nota
La ejecución de LVM proporciona flexibilidad adicional y permite la posibilidad de usar snapshots para respaldar MongoDB.
Snapshots con Amazon EBS en una configuración RAID 10
Si tu implementación depende del almacenamiento en bloque elástico (EBS) de Amazon con RAID configurado dentro de la instancia, es imposible obtener un estado coherente en todos los discos utilizando la herramienta de snapshot de la plataforma. Como alternativa, se puede realizar una de las siguientes acciones:
Limpia todas las escrituras en el disco y crea un bloqueo de escritura para garantizar un estado consistente durante el proceso de copia de seguridad.
Si eliges esta opción, consulta Respalda instancias con archivos de registro en un volumen separado o sin registro.
Configure LVM para ejecutar y almacenar sus archivos de datos MongoDB sobre el RAID dentro de su sistema.
Si elige esta opción, realice la operación de copia de seguridad de LVM descrita en Crear una instantánea.
Realizar copias de seguridad y restaurar mediante LVM en Linux
Esta sección proporciona una descripción general de un proceso sencillo de copia de seguridad usando LVM en un sistema Linux. Si bien las herramientas, los comandos y las rutas pueden ser (ligeramente) diferentes en su sistema, los siguientes pasos proporcionan una visión general de alto nivel de la operación de copia de seguridad.
Nota
Solo use el siguiente procedimiento como guía para un sistema de copia de seguridad e infraestructura. Los sistemas de copia de seguridad de producción deben considerar una serie de requisitos de aplicaciones y factores específicos de entornos particulares.
Para obtener información sobre clústeres, consulta Respaldar un clúster autogestionado con snapshots del sistema de archivos.
Crear una snapshot
Para realizar copias de seguridad a nivel de volumen de instancias de MongoDB mediante WiredTiger, ya no es necesario que los archivos de datos y el diario residan en un solo volumen.
Para crear una snapshot con LVM, emite un comando como root en el siguiente formato:
lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb
Este comando crea una snapshot LVM (con la opción --snapshot) llamada mdb-snap01 del volumen mongodb en el grupo de volúmenes vg0.
Este ejemplo crea una snapshot llamada mdb-snap01 ubicada en /dev/vg0/mdb-snap01. La ubicación y las rutas a los grupos de volúmenes y dispositivos de tus sistemas pueden variar ligeramente según la configuración de LVM del sistema operativo.
La snapshot tiene un límite de 100 megabytes, debido al parámetro --size 100M. Este tamaño no refleja la cantidad total de datos en el disco, sino la cantidad de diferencias entre el estado actual de /dev/vg0/mongodb y la creación del snapshot (es decir, /dev/vg0/mdb-snap01.)
Advertencia
Asegúrate de crear instantáneas con suficiente espacio para considerar el crecimiento de datos, especialmente durante el período que tarda en copiar los datos fuera del sistema o a una imagen temporal.
Si tu snapshot se queda sin espacio, la imagen del snapshot se vuelve inutilizable. Descartar este volumen lógico y crear otro.
El snapshot existirá cuando el comando se devuelva. Puedes restaurar directamente desde el snapshot en cualquier momento o crear un nuevo volumen lógico y restaurar desde ese snapshot a la imagen alternativa.
Si bien las instantáneas son excelentes para crear copias de seguridad de alta calidad rápidamente, no son el formato ideal para almacenar datos de respaldo. Normalmente, dependen y residen en la misma infraestructura de almacenamiento que las imágenes de disco originales. Por lo tanto, es crucial archivarlas y almacenarlas en otro lugar.
Archivar una instantánea
Tras crear una instantánea, móntela y copie los datos en un almacenamiento independiente. Es posible que el sistema intente comprimir las imágenes de copia de seguridad al desconectarlas. Como alternativa, realice una copia a nivel de bloque de la instantánea, como con el siguiente procedimiento:
umount /dev/vg0/mdb-snap01 dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz
La secuencia de comandos anterior realiza lo siguiente:
Asegura que el dispositivo
/dev/vg0/mdb-snap01no esté montado. Nunca tomes una copia a nivel de bloque de un sistema de archivos o snapshot de sistema de archivos que esté montado.Realiza una copia a nivel de bloque de toda la imagen de snapshot utilizando el comando
ddy comprime el resultado en un archivo gzipped en el directorio de trabajo actual.Advertencia
Este comando creará un archivo
gzgrande en el directorio de trabajo actual. Asegúrate de ejecutar este comando en un sistema de archivos que disponga de suficiente espacio libre.
Restaurar una instantánea
Para restaurar una instantánea creada con LVM, emita la siguiente secuencia de comandos:
lvcreate --size 1G --name mdb-new vg0 gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
La secuencia anterior realiza lo siguiente:
Crea un nuevo volumen lógico llamado
mdb-new, en el grupo de volúmenes/dev/vg0. La ruta al nuevo dispositivo será/dev/vg0/mdb-new.Advertencia
Este volumen tendrá un tamaño máximo de 1 gigabyte. El sistema de archivos original debe haber tenido un tamaño total de 1 gigabyte o menor, de lo contrario, la restauración fallará.
Cambia
1Gal tamaño de volumen que desees.Descomprime y desarchiva el
mdb-snap01.gzen la imagen de discomdb-new.Monta la imagen de disco
mdb-newen el directorio/srv/mongodb. Modificar el punto de montaje para que corresponda a la ubicación de tu archivo de datos de MongoDB, u otra ubicación según sea necesario.
Nota
La instancia restaurada tendrá un archivo mongod.lock obsoleto. Si no remueves este archivo de la snapshot, es posible que MongoDB asuma que el archivo de bloqueo obsoleto indica un cierre incorrecto. Si estás utilizando storage.journal.enabled activado, y no utilizas db.fsyncLock(), no necesitas remover el archivo mongod.lock. Si utilizas db.fsyncLock(), tendrás que remover el bloqueo.
Restaurar directamente desde una snapshot
Para restaurar una copia de seguridad sin escribir en un archivo comprimido gz, utilice la siguiente secuencia de comandos:
umount /dev/vg0/mdb-snap01 lvcreate --size 1G --name mdb-new vg0 dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
Nota
Todas las colecciones de MongoDB tienen UUIDs por defecto. Cuando MongoDB restaura colecciones, las colecciones restauradas conservan sus UUID originales. Al restaurar una colección en la que no había UUID, MongoDB genera un UUID para la colección restaurada.
Para obtener más información sobre los UUID de colecciones, consulte las Colecciones.
Almacenamiento remoto de copias de seguridad
Puede implementar copias de seguridad fuera del sistema utilizando el proceso combinado y SSH.
Esta secuencia es idéntica a los procedimientos explicados anteriormente, excepto que archiva y comprime la copia de seguridad en un sistema remoto usando SSH.
Considera el siguiente procedimiento:
umount /dev/vg0/mdb-snap01 dd if=/dev/vg0/mdb-snap01 | ssh username@example.com gzip > /opt/backup/mdb-snap01.gz lvcreate --size 1G --name mdb-new vg0 ssh username@example.com gzip -d -c /opt/backup/mdb-snap01.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
Respalde instancias con archivos de diario en un volumen independiente o sin registro
Para realizar copias de seguridad a nivel de volumen de instancias de MongoDB con WiredTiger, ya no es necesario que los archivos de datos y el diario residan en un solo volumen. Sin embargo, la base de datos debe bloquearse y todas las escrituras en ella deben suspenderse durante el proceso de copia de seguridad para garantizar su consistencia.
Si tu instancia de mongod está ejecutándose sin registro de transacciones o si los archivos de registro están en un volumen independiente, debes vaciar todas las escrituras al disco y bloquear la base de datos para evitar escrituras durante el proceso de copia de seguridad. Si tienes una configuración de set de réplicas, para tu copia de seguridad utiliza un secundario que no esté recibiendo lecturas (es decir, miembro oculto).
Descarga las escrituras al disco y bloquea la base de datos para evitar nuevas escrituras.
Para volcar las escrituras al disco y "bloquear" la base de datos, emite el método db.fsyncLock() en mongosh:
db.fsyncLock();
Realiza la operación de copia de seguridad descrita en Crear una snapshot.
Después de crear la snapshot, desbloquea la base de datos.
Para desbloquear la base de datos después de crear el snapshot, use el siguiente comando en mongosh:
db.fsyncUnlock();