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 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
Si restauras desde archivos tomados a través de una copia de seguridad en caliente mientras el mongod se 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 mongod no 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 tras restaurar desde una instantánea del sistema de archivos, MongoDB añade la opción en la --eseDatabaseKeyRollover línea de comandos. Al iniciarse con la --eseDatabaseKeyRollover opción, la mongod instancia reutiliza las claves de la base de datos configuradas con el AES256-GCM cifrado y finaliza.

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.

En el motor de almacenamiento de WiredTiger, los archivos de datos reflejan un estado consistente desde el último punto de control. Los puntos de control se generan 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 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:

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 Realizar copias de seguridad de instancias con archivos de diario en un volumen separado o sin registro en diario.
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-snap01 no 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 dd y comprime el resultado en un archivo gzipped en el directorio de trabajo actual.
Advertencia
Este comando creará un archivo gz grande 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 1G al tamaño de volumen que desees.
Descomprime y desarchiva el mdb-snap01.gz en la imagen de disco mdb-new .
Monta la imagen de disco mdb-new en 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 instantánea restaurada tendrá un archivo mongod.lock obsoleto. Si no elimina este archivo de la instantánea, MongoDB podría asumir que el archivo de bloqueo obsoleto indica un apagado incorrecto. Si usa,db.fsyncLock() deberá eliminar el mongod.lock archivo.

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 su instancia tiene los archivos de diario en un volumen separado, debe vaciar todas las escrituras en el disco mongod y bloquear la base de datos para evitar escrituras durante el proceso de copia de seguridad. Si tiene una configuración de conjunto de réplicas, utilice para la copia de seguridad un secundario que no reciba lecturas (es decir, un 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();

Volver

Copia de seguridad y restauración

Realiza copias de seguridad y restauraciones con las herramientas de MongoDB