Docs Menu
Docs Home
/ /

Preparaciones de respaldo

Antes de realizar una copia de seguridad de su clúster o conjunto de réplicas, decida cómo y qué datos respaldará. Esta página describe los aspectos que debe considerar antes de iniciar una copia de seguridad.

Tip

Para saber cómo funciona la copia de seguridad, consulte Apoyo.

Los requisitos de copia de seguridad y recuperación de un sistema determinado varían para cumplir con los estándares de costo, rendimiento y protección de datos que establece el propietario del sistema.

Ops Manager Enterprise Backup and Recovery admite cinco arquitecturas de respaldo, cada una con sus propias ventajas y desventajas. Considere la arquitectura que cumpla con los requisitos de protección de datos de su implementación antes de configurarla e implementarla.

Ejemplo

Considere un sistema cuyos requisitos incluyen bajos costos operativos. Los propietarios del sistema podrían tener límites estrictos en cuanto a lo que pueden gastar en almacenamiento para su configuración de respaldo y recuperación. Como resultado, podrían aceptar un mayor tiempo de recuperación.

Por el contrario, considere un sistema cuyos requisitos incluyen un bajo Objetivo de tiempo de recuperación. Los propietarios del sistema toleran mayores costos de almacenamiento si esto resulta en una configuración de respaldo y recuperación que cumpla con los requisitos de recuperación.

Ops Manager Enterprise Backup and Recovery admite las siguientes arquitecturas de respaldo:

  • Un sistema de archivos en un SAN con funciones avanzadas para copias de seguridad del sistema de archivos, como alta disponibilidad, compresión o deduplicación

  • Un sistema de archivos en uno o más dispositivos NAS

  • Un S3-compatible blockstore

  • Almacén de bloques de MongoDB en una configuración de alta disponibilidad

  • MongoDB almacenamiento en bloques en una configuración autónomo

Ofrecemos recomendaciones de arquitectura de respaldo como guía para desarrollar sus propios enfoques de protección de datos. Nuestras recomendaciones no cubren ni representan todos los escenarios o implementaciones.

Función de respaldo del sistema
Sistema de archivos en SAN
Sistema de archivos en NAS
Almacén de bloques AWS S3
MongoDB HA Blockstore
Almacén de bloques de MongoDB

Tipos de instantáneas

Completo *

Completo *

Muchos parciales

Muchos parciales

Muchos parciales

Desduplicación de datos de respaldo

Si SAN lo admite

No

Compresión de datos de respaldo

No

Replicación de datos de respaldo

Si SAN lo admite

No

No

No

Costo de almacenamiento de copia de seguridad

Mayor

Intermedio

Inferior

Mayor

Inferior

Tiempo del personal para gestionar las copias de seguridad

Intermedio

Intermedio

Inferior

Mayor

Intermedio

RTO de copia de seguridad

Inferior

Intermedio

Inferior

Inferior

Intermedio

Para realizar una copia de seguridad incremental en un almacén del sistema de archivos, el agente de MongoDB segmenta cada archivo del motor de almacenamiento en la ruta especificada para la copia de seguridad en bloques de datos y transfiere solo los bloques modificados a Ops Manager. Ops Manager crea una nueva instantánea a partir de los bloques recibidos y copia los bloques restantes sin cambios de la instantánea de copia de seguridad completa anterior. Cada instantánea de copia de seguridad incremental almacenada en un sistema de archivos ahorra E/S de red. Cada instantánea de copia de seguridad contiene una copia completa de todos los archivos necesarios de una implementación de MongoDB respaldada y no desduplica los registros.

Nota

¿Cuándo utilizar un método de backup en particular?

  • Para ejecutar copias de seguridad con frecuencia en grandes cantidades de datos y restaurar a partir de las copias de seguridad, considere realizar una copia de seguridad en un sistema de archivos en una SAN, un almacén de3instantáneas de almacenamiento compatible con AWS S o un almacén de bloques MongoDB configurado como un conjunto de réplicas o un clúster fragmentado.

  • Para restaurar datos sin depender de la base de datos MongoDB, considere realizar una copia de seguridad en un almacén de3instantáneas de almacenamiento compatible con AWS S, uno o más dispositivos NAS o un sistema de archivos en una SAN con funciones avanzadas para copias de seguridad del sistema de archivos, como alta disponibilidad, compresión o deduplicación.

  • Para minimizar los costos de almacenamiento interno y mantenimiento, considere realizar una copia de seguridad en un almacén de instantáneas de almacenamiento compatible con AWS S3o en un almacén de bloques independiente de MongoDB.

    Un almacén de bloques independiente de MongoDB ofrece una resiliencia limitada. Si el disco se llena, este almacén de bloques podría quedar fuera de servicio. Solo se pueden recuperar instantáneas de copia de seguridad después de añadir almacenamiento adicional.

Al dimensionar la copia de seguridad de sus datos, mantenga el tamaño del conjunto de réplicas 2 en TB o menos de datos sin comprimir. Si su base de datos aumenta a 2 más de TB de datos sin comprimir:

  • Fragmentar la base de datos

  • Mantenga cada fragmento en 2 TB o menos de datos sin comprimir

Estas recomendaciones de tamaño son una práctica recomendada. No representan una limitación de la base de datos MongoDB ni de Ops Manager.

La copia de seguridad y la restauración pueden utilizar grandes cantidades de CPU, memoria, almacenamiento y ancho de banda de red.

Ejemplo

El rendimiento de red indicado, como 10 Gbps o 100 Gbps, es un máximo teórico. Este valor no considera la compartición ni la limitación del tráfico de red.

Consideremos el siguiente escenario:

  • Deseas hacer un respaldo de una base de datos de 2 TB.

  • Sus hosts admiten una conexión TCP de 10 Gbps desde Ops Manager a su almacenamiento de copia de seguridad.

  • La conexión de red tiene una pérdida de paquetes muy baja y un tiempo de retardo de ida y vuelta bajo.

Una copia de seguridad completa de sus datos tardaría más de horas en 30 completarse. []1

Esto no tiene en cuenta las velocidades de lectura y escritura del disco, que pueden ser, como máximo, de 3 Gbps de lectura y 1 Gbps de escritura para un dispositivo de almacenamiento NVMe único o reflejado.

El tiempo necesario para completar cada copia de seguridad incremental sucesiva depende de la carga de escritura.

Si fragmenta esta base de datos en 4 fragmentos, cada uno ejecuta su copia de seguridad por separado. Esto da como resultado una copia de seguridad que tarda menos de 8 horas en completarse.

[1] Estas cifras de rendimiento se calcularon utilizando métodos estándar de la industria para medir el rendimiento de la red y no suponen ninguna compresión de red adicional.

Por defecto, Ops Manager toma una instantánea base de tus datos cada 24 horas.

Si lo desean, los administradores pueden cambiar la frecuencia de las instantáneas base a 6, 8, 12 o 24 horas. Ops Manager crea instantáneas automáticamente según una programación. También pueden tomar instantáneas a demanda.

Ops Manager retiene los snapshots durante los períodos de tiempo listados en la siguiente tabla.

Si finaliza la copia de seguridad de una implementación, Ops Manager elimina inmediatamente las instantáneas que se encuentran dentro de las fechas de la política de retención actual.

Si detiene la copia de seguridad de una implementación, Ops Manager deja de tomar nuevas instantáneas, pero conserva las existentes hasta su fecha de vencimiento indicada.

Instantánea
Política de retención predeterminada
Política de retención máxima

Instantánea base

2 días

5 días (30 días si la frecuencia es de 24 horas)

Instantánea diaria

días de 0

año de 1

Instantánea semanal

semanas de 2

año de 1

Instantánea mensual

1 mes

7años

Nota

Las instantáneas mensuales son instantáneas completas de forma predeterminada, no instantáneas incrementales.

Puede cambiar la programación de una implementación respaldada a través de su Edit Snapshot Schedule Opción de menú, disponible en la Backup página. Los administradores pueden cambiar la frecuencia y la retención de las instantáneas mediante el recurso snapshotSchedule en la API.

Al cambiar la hora de referencia, se modifica la hora de la siguiente instantánea programada. No se puede programar una instantánea antes de la hora actual de la siguiente instantánea. La hora actual de la siguiente instantánea es la hora de referencia actual más el intervalo entre instantáneas.

Para determinar la hora de la próxima instantánea, compare la hora de la próxima instantánea actual con la nueva hora de referencia:

  • Si la nueva hora de referencia es anterior a la hora actual de la siguiente instantánea, esta se producirá después de dicha hora. La instantánea se produce en la nueva hora de referencia más los intervalos necesarios para superarla. Si esta hora ya ha transcurrido al realizar el cambio, Ops Manager toma la siguiente instantánea cuando vuelva a ocurrir la nueva hora de referencia. Consulte las dos primeras filas de la siguiente tabla para ver ejemplos.

  • Si la nueva hora de referencia es posterior a la hora de la siguiente instantánea, Ops Manager toma la siguiente instantánea cuando vuelva a aparecer la nueva hora de referencia. Consulte la tercera y la cuarta fila de la siguiente tabla para ver ejemplos.

Tiempo de cambio
Tiempo de referencia actual
Intervalo entre instantáneas
Hora actual de la siguiente instantánea
Nueva hora de referencia
Hora de la próxima instantánea

08:00 UTC

12:00 UTC

6 horas

12:00 UTC

10:00 UTC

16:00 UTC de hoy

23:00 UTC

12:00 UTC

6 horas

00:00 UTC

10:00 UTC

04:00 UTC mañana

08:00 UTC

12:00 UTC

6 horas

12:00 UTC

19:00 UTC

19:00 UTC de hoy

20:00 UTC

12:00 UTC

6 horas

00:00 UTC

19:00 UTC

01:00 UTC mañana

Si modifica la programación para guardar menos instantáneas, Ops Manager no eliminará las existentes para adaptarse a la nueva programación. Para eliminar las instantáneas innecesarias, consulte Eliminar una instantánea.

  • Ops Manager no realiza copias de seguridad de las implementaciones en las que el número total de recopilaciones en la implementación iguala o supera 100,000.

  • Ops Manager no replica las opciones de recopilación de índices.

Ops Manager puede cifrar cualquier trabajo de copia de seguridad. Utilice cursores de copia de seguridad en lugar de bases de datos principales para cifrar trabajos de copia de seguridad. Para obtener más información, consulte el Servicio Daemon de Copia de Seguridad.

Ops Manager mantiene la coherencia causal al tomar db.[collection].count()instantáneas, excepto las estadísticas de tamaño reportadas por collStats y.db.[collection].count() Estas estadísticas pueden ser inexactas. Ops Manager coordina la hora en todos los fragmentos de los clústeres fragmentados. Esto garantiza que las instantáneas incluyan todos los documentos escritos en cada fragmento y nodo a la hora programada.

Importante

Los clústeres fragmentados y los sets de réplicas son los únicos tipos de implementación de los que puedes hacer copias de seguridad si tus bases de datos ejecutan compatibilidad de características entre versiones 4.2 y anteriores de MongoDB. Para hacer una copia de seguridad de un proceso mongod autónomo que ejecute compatibilidad de características entre versiones 4.2 o anteriores de MongoDB, debes convertirlo en un set de réplicas de un solo nodo.

Característica
Bases de datos que ejecutan FCV 4.2 y versiones posteriores
Bases de datos que ejecutan FCV 4.0 y versiones anteriores

Realiza copias de seguridad de datos mediante instantáneas de WiredTiger

Realiza la copia de seguridad de los datos utilizando el daemon de copias de seguridad.

Hace copias de seguridad de sets de réplicas

Realiza copias de seguridad de Clústeres Particionados

¿Puede filtrarse mediante espacios de nombres?[]2

Puede especificar la base de datos de origen de sincronización

Puede restaurar datos a un punto específico en el tiempo []3

Puede realizar copias de seguridad incrementales []4

Soporta snapshots que utilizan el cifrado KMIP [5]

Admite snapshots que usan cifrado de clave local [6]

Admite guardar en almacenamiento de instantáneas de blockstore

Admite guardar en almacenamiento compatible con S3Almacenamiento de instantáneas

Admite guardar en el almacenamiento del sistema de archivos []7

Admite bases de datos que ejecutan MongoDB Enterprise

Admite bases de datos que ejecutan MongoDB Community

Requiere un agente MongoDB con copia de seguridad habilitada en cada mongod nodo del clúster

[2] El filtrado de espacios de nombres solo es compatible con las versiones 6.0.8 y posteriores de Ops Manager. Sus implementaciones de MongoDB deben tener valores featureCompatibilityVersion de 4.0 y anteriores, o 6.0.1 y posteriores.
[3] Para realizar una restauración PIT se requiere Ops Manager 4.2.13 o posterior.
[4] Ops Manager requiere una copia de seguridad completa para la primera copia de seguridad, después de eliminar una instantánea y si se ha modificado el tamaño del bloque del almacén de bloques. Las copias de seguridad incrementales reducen los costes de transferencia y almacenamiento de red. Esta función funciona con:
  • MongoDB 4.0 y anteriores.
  • MongoDB 4.2.6 o posterior si se ejecuta FCV 4.2 o posterior.
[5] Para consultar una instantánea cifrada se requiere MongoDB Enterprise 4.2.9 y posterior o 4.4.0 y posterior.
[6] Las copias de seguridadFCV y 4.2 posteriores no admiten el cifrado de clave local.
[7] File System Store Gzip Compression LevelLas copias de seguridad de una4.2 base de datos FCV o posterior en un almacén del sistema de archivos ignoran.

Para ejecutar copias de seguridad y restauraciones si está ejecutando MongoDB 4.2 o posterior con FCV 4.2 o posterior, debe:

  • Debe ejecutar MongoDB Enterprise.

  • Debe tener en cuenta el cambio en el tamaño de bloque del almacén de bloques. Si no configuró el tamaño de bloque y usó el predeterminado, este cambiará de 64 KB a 1 MB. Esto puede afectar el uso del almacenamiento.

  • Debe asegurarse de que los nombres de host en la configuración del conjunto de réplicas coincidan con los que usa el Agente de MongoDB, o que sus asignaciones de host contengan los nombres de host correctos. Puede usar rs.conf() para verificar la configuración del conjunto de réplicas.

  • Se pueden usar listas de filtros de espacios de nombres para definir los espacios de nombres incluidos en una copia de seguridad solo si se ejecuta MongoDB 6.0 o posterior. Las instantáneas tomadas en las versiones MongoDB 4.2 a 5.0 siempre incluyen todos los espacios de nombres.

  • No es necesario sincronizar una base de datos fuente. Al tomar una snapshot, el Ops Manager selecciona el miembro del set de réplicas con menor impacto sobre el rendimiento y la mayor duplicación de datos de snapshot a nivel de almacenamiento.

  • Debe implementar un agente MongoDB con cada nodo del mongod clúster.

Nota

Si Ops Manager no administra su clúster:

  • Otorgue los backup roles y al usuario de MongoDB que ejecuta copias de seguridad.clusterAdmin

  • Asegúrese de que el usuario del sistema operativo que ejecuta el Agente MongoDB tenga permiso de lectura para todos los archivos de datos (incluidos los archivos de diario) de la implementación.

Ops Manager crea identificadores para cada archivo de la base de datos durante las copias de seguridad incrementales. Asegúrese de que el límite de archivos abiertos sea mayor que el número de archivos antes de realizar una copia de seguridad incremental. Como alternativa, realice una copia de seguridad completa en lugar de una incremental.

Si configura Ops Manager para usar varios servidores de aplicaciones de Ops Manager tras un balanceador de carga HTTP o HTTPS y usa instantáneas del sistema de archivos, lastareas de instantáneas 4 de2 copia de seguridad de FCV. o posteriores se ejecutan en paralelo en uno o más servidores. Asegúrese de tener un sistema de archivos compartido montado en cada servidor de Ops Manager. El servidor de aplicaciones de Ops Manager podría abrir y escribir diferentes desplazamientos de los mismos archivos. Asegúrese de que el sistema de archivos compartido lo permita. De lo contrario, se producirán errores de acceso.

Ops Manager gestiona las instantáneas caducadas mediante tareas de limpieza. Estas tareas funcionan de forma diferente según el almacén de instantáneas que las contenga:

Tienda de instantáneas
Cómo funcionan los trabajos de novio

Almacén de bloques de MongoDB

Utiliza espacio de disco adicional hasta la cantidad de bloques activos para cada trabajo.

Almacenamientos de snapshot

Elimina instantáneas caducadas

Almacenes de instantáneas S3

Puede usar espacio de disco adicional si Ops Manager crea una instantánea mientras se ejecuta el trabajo de limpieza. Ops Manager puede ejecutar trabajos de limpieza simultáneos en almacenes de instantáneas S3.

Nota

Los trabajos de snapshot y los de limpieza no pueden ejecutarse simultáneamente. Si inicia una tarea de limpieza mientras se está ejecutando una tarea de snapshot, la tarea de limpieza fallará; Ops Manager registrará un registro de error y reintentará automáticamente la tarea de limpieza después de que la tarea de snapshot finalice. Si inicias una tarea de snapshot mientras se ejecuta una tarea de limpieza, la tarea de snapshot fallará, y Ops Manager registrará un error y la reintentará una vez finalizada la tarea de limpieza.

Para obtener más información sobre trabajos de novios, consulte Trabajos de novios.

El filtro de espacios de nombres permite especificar las bases de datos y colecciones que se respaldarán. Puede aplicar un filtro de espacios de nombres a cualquier base de datos, excepto admin y local, y a cualquier colección que no empiece por system.

Tip

Si aplica filtros de espacio de nombres a una instantánea, no podrá consultar esa instantánea.

Crea Deny List colecciones para excluir o Allow List colecciones para incluir. Selecciona tus selecciones al iniciar una copia de seguridad y luego puedes editarlas según sea necesario.

Utilice la lista de denegación para evitar la copia de seguridad de colecciones que contengan datos de registro, cachés u otros datos efímeros. Excluir este tipo de bases de datos y colecciones le permitirá reducir el tiempo y los costes de las copias de seguridad. Usar una lista de denegación suele ser preferible a una lista de permitidos, ya que esta última requiere que se active intencionalmente cada espacio de nombres que desee respaldar.

Nota

El filtrado de espacios de nombres solo es compatible con las versiones 6.0.8 y posteriores de Ops Manager. Sus implementaciones de MongoDB deben tener valores featureCompatibilityVersion de 4.0 y anteriores, o 6.0.1 y posteriores.

Para realizar copias de seguridad de clústeres MongoDB, utilice el motor de almacenamiento WiredTiger.

Si sus bases de datos de respaldo actuales utilizan MMAPv1, actualice a WiredTiger:

Con WiredTiger, Ops Manager limita las copias de seguridad a las implementaciones con menos de 100,000 archivos. Los archivos incluyen colecciones e índices.

MongoDB 4.2 elimina el1 almacenamiento MMAPv. Para obtener más información sobre los motores de almacenamiento, consulte Almacenamiento en el manual de MongoDB.

En clústeres fragmentados, si la copia de seguridad no puede acceder a un proceso mongod, ya sea un servidor de fragmentos o de configuración, el agente no puede insertar un token de registro de operaciones de sincronización. En estos casos, Ops Manager no crea la instantánea y muestra un mensaje de advertencia.

Para habilitar la copia de seguridad regional, debe asociar al menos uno de los siguientes con la región de implementación a la que se dirige un conjunto de réplicas o un fragmento:

Además, debe asociar uno de cada uno de los siguientes elementos con una región de implementación:

Si añades una partición a un clúster después de habilitar la copia de seguridad regional para ese clúster, debes asignar una región de implementación a la nueva partición para continuar las tareas de copia de seguridad de las particiones existentes. Hasta que asignes una región de implementación al nuevo shard, toda la tarea de copia de seguridad del clúster tendrá un estado Misconfigured y no generará nuevos snapshots. Un clúster shardeado con un estado Misconfigured sigue generando entradas de Oplog.

Volver

Overview

En esta página