Realiza una copia de seguridad de una implementación autogestionada con snapshots 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 correspondientes estrategias de restauración. Para obtener información sobre clústeres particionados, consulta Realiza una copia de seguridad de un clúster particionado autogestionado con snapshots del sistema de archivos.
Estas snapshots 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 contienen los archivos de datos de MongoDB. Estos métodos se completan rápidamente y funcionan de manera confiable, pero requieren una configuración adicional del sistema fuera de MongoDB.
Tip
Resumen de snapshots
Las snapshots funcionan creando pointers entre los datos en vivo y un volumen de snapshot especial. Estos punteros son teóricamente equivalentes a "hard links" (enlaces duros). A medida que los datos de trabajo se desvían de la snapshot, el proceso de la snapshot utiliza una estrategia de copia en escritura. Como resultado, la snapshot 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
- Si restauras desde archivos tomados a través de una copia de seguridad en caliente mientras el
mongodse está ejecutando, MongoDB detecta claves "sucias" al arrancar y rota automáticamente la clave de la base de datos para evitar la reutilización de IV (Initialization Vector).
- Restauración desde una copia de seguridad en frío
Sin embargo, si se restaura desde archivos obtenidos mediante una copia de seguridad "en frío" mientras
mongodno se está ejecutando, MongoDB no detecta claves "sucias" al iniciarse, y la reutilización del IV anula las garantías de confidencialidad e integridad.Para evitar la reutilización de las claves después de restaurar desde una snapshot fría del sistema de archivos, MongoDB añade 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 sale.
Base de datos válida en el momento de la snapshot
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.
Alternativamente, almacene todos los archivos de datos de MongoDB en un dispositivo dedicado para que pueda realizar copias de seguridad sin duplicar datos innecesarios.
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. Aunque diferentes métodos de snapshots ofrecen diferentes funcionalidades, el método LVM que se describe a continuación no ofrece ninguna capacidad para la captura de backups incrementales.
Snapshots en Linux
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:
Vacíe todos los registros en disco y cree un bloqueo de escritura para garantizar un estado coherente durante el proceso de copia de seguridad.
Si eliges esta opción, consulta Realice copias de seguridad de las instancias con archivos de diario en un volumen separado o sin registrar en la bitácora.
Configura LVM para ejecutar y almacenar tus archivos de datos de MongoDB sobre el RAID dentro de tu sistema.
Si eliges esta opción, realiza la operación de copia de seguridad LVM descrita en Crear una snapshot.
Respaldo y restauración con 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
A efectos de la copia de seguridad a nivel de volumen de instancias de MongoDB utilizando WiredTiger, los archivos de datos y el registro ya no se requiere que 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 snapshots son excelentes para crear copias de seguridad de alta calidad de forma rápida, no son ideales como formato para almacenar datos de copias de seguridad. Las instantáneas suelen depender y residir en la misma infraestructura de almacenamiento que las imágenes de disco originales. Por lo tanto, es crucial que archive estas instantáneas y las almacene en otro lugar.
Archivar una snapshot
Después de crear una snapshot, monta la snapshot y copia los datos a un almacenamiento separado. Es posible que tu sistema intente comprimir las imágenes de copia de seguridad a medida que las trasladas fuera de línea. Como alternativa, realice una copia a nivel de bloque de la imagen snapshot, 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 snapshot 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 snapshot restaurada tendrá un archivo mongod.lock obsoleto. Si no remueves este archivo de la snapshot, MongoDB podría considerar que el archivo de bloqueo obsoleto indica un cierre incorrecto. Si utilizas db.fsyncLock(), deberás remover el archivo mongod.lock.
Restaurar directamente desde una snapshot
Para restaurar una copia de seguridad sin escribir en un archivo comprimido gz, utiliza 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 la copia de seguridad a nivel de volumen de las instancias de MongoDB utilizando WiredTiger, ya no se requiere que los archivos de datos y el journal residan en un solo volumen. Sin embargo, la base de datos debe estar bloqueada y todas las escrituras en la base de datos deben suspenderse durante el proceso de copia de seguridad para garantizar la coherencia de la copia de seguridad.
Si la instancia mongod tiene los archivos de la bitácora en un volumen independiente, se deben volcar todas las escrituras a disco y bloquear la base de datos para impedir escrituras durante el proceso de copia de seguridad. Si hay una configuración del set de réplicas, para la copia de seguridad se debe usar 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();