Docs Menu
Docs Home
/ /

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 independientes y conjuntos de réplicas de MongoDB mediante herramientas a nivel de sistema, 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

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.

Tras crear la instantánea, monte la imagen en su sistema de archivos y copie los datos. La copia de seguridad resultante contiene una copia completa de todos los datos.

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.

Para motores de almacenamiento cifrado que utilizan AES256-GCM modo de cifrado, AES256-GCM requiere que cada proceso utilice un valor de bloque de contador único 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 mongod está 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, mongod no 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 instancia mongod cambia las claves de la base de datos configuradas con el cifrado AES256-GCM y se cierra.

La base de datos debe ser válida al crear la instantánea. Esto significa que todas las escrituras que acepte deben escribirse completamente en el disco, ya sea en el diario o en los archivos de datos.

Si hay escrituras que no están en el disco cuando se realiza 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 consistente desde el último punto de control. Los puntos de control se producen cada 2 GB de datos o cada minuto.

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.

Las instantáneas crean una imagen de un disco completo. A menos que necesite hacer una copia de seguridad de todo el sistema, considere aislar los archivos de datos de MongoDB, el diario (si corresponde) y la configuración en un disco lógico que no contenga otros datos.

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.

Asegúrese de copiar los datos de las instantáneas a otros sistemas. Esto garantiza la seguridad de los datos ante fallos del sitio.

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.

Si administra su propia infraestructura en un sistema Linux, configure su sistema con LVM para proporcionar sus paquetes de discos y la capacidad de crear instantáneas. También puede usar configuraciones basadas en LVM en un entorno virtualizado o en la nube.

Nota

La ejecución de LVM proporciona flexibilidad adicional y permite la posibilidad de utilizar instantáneas para realizar copias de seguridad de MongoDB.

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 ver 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.

Esta sección ofrece una descripción general de un proceso de copia de seguridad sencillo con LVM en un sistema Linux. Si bien las herramientas, los comandos y las rutas pueden ser ligeramente diferentes en su sistema, los siguientes pasos ofrecen una descripción general de la operación de copia de seguridad.

Nota

Utilice el siguiente procedimiento únicamente como guía para un sistema e infraestructura de respaldo. Los sistemas de respaldo de producción deben considerar diversos requisitos específicos de la aplicación y factores propios de cada entorno.

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.

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 instantánea con LVM, emita 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 instantánea llamada mdb-snap01 ubicada /dev/vg0/mdb-snap01 en. La ubicación y las rutas a los grupos de volúmenes y dispositivos de su sistema pueden variar ligeramente según la configuración LVM de su sistema operativo.

La instantánea 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 de la instantánea (es decir, /dev/vg0/mdb-snap01).

Advertencia

Asegúrese de crear instantáneas con suficiente espacio para tener en cuenta el crecimiento de los datos, en particular durante el período de tiempo que lleva copiar datos fuera del sistema o a una imagen temporal.

Si la instantánea se queda sin espacio, la imagen quedará inutilizable. Deseche este volumen lógico y cree 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.

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 hace 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 instantánea utilizando el comando dd y comprime el resultado en un archivo comprimido en el directorio de trabajo actual.

    Advertencia

    Este comando creará un archivo gz grande en su directorio de trabajo actual. Asegúrese de ejecutarlo en un sistema de archivos con suficiente espacio libre.

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 hace 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 gigabytes. El sistema de archivos original debe tener un tamaño total de 1 gigabytes o menos; de lo contrario, la restauración fallará.

    Cambie 1G por el tamaño de volumen deseado.

  • 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. Modifica el punto de montaje para que coincida con la ubicación del archivo de datos de MongoDB o con 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.

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 UUID predeterminados. Al restaurar colecciones, MongoDB conserva sus UUID originales. Al restaurar una colección sin UUID, MongoDB genera un UUID para la colección restaurada.

Para obtener más información sobre los UUID de colecciones, consulte las Colecciones.

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 mediante SSH.

Considere 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

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).

1

Para vaciar las escrituras en el disco y "bloquear" la base de datos, emita el db.fsyncLock() método mongosh en:

db.fsyncLock();
2
3

Para desbloquear la base de datos después de crear la instantánea, use el siguiente comando mongosh en:

db.fsyncUnlock();

Volver

Copia de seguridad y restauración

En esta página