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.
Advertencia
Ops Manager ya no admite la creación de instantáneas de clúster desde implementaciones de bases de datos que utilizan cifrado de clave local. Si cifra una implementación de base de datos con cifrado de clave local, la instantánea falla. Para cifrar instantáneas, utilice Cifrado basado enKMIP con sus implementaciones de bases de datos.
Opciones de configuración de copia de seguridad
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 Objetivo de Tiempo de Recuperación bajo. 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 una 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 AWS S3 blockstore
Almacén de bloques de MongoDB en una configuración de alta disponibilidad
MongoDB almacenamiento en bloques en una configuración autónomo
Importante
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.
Características del método de respaldo
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 | Sí | Sí | Sí |
Compresión de datos de respaldo | Sí | No | Sí | Sí | Sí |
Replicación de datos de respaldo | Si SAN lo admite | No | No | Sí | 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.
Recomendación de tamaño de copia de seguridad
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. |
Política de frecuencia y retención de instantáneas
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; no se 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 |
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.
Límites
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.
Encriptación
Ops Manager puede cifrar cualquier trabajo de respaldo almacenado en una base de datos principal que ejecute MongoDB Enterprise entre FCV. 3 4 4y.0 con el motor de almacenamiento WiredTiger.
FCV 4.2 y posteriormente usar cursores de respaldo en lugar de bases de datos principales. Para más información, consulte el Servicio Daemon de Respaldo.
Consideraciones sobre copias de seguridad
Coherencia e instantáneas
Para clústeres que ejecutan MongoDB versión 4.2 o posterior:
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.
Para clústeres que ejecutan MongoDB versión 4.0 y anteriores:
Ops Manager mantiene instantáneas consistentes ante fallos.
Ops Manager toma instantáneas de cada uno de los fragmentos de los clústeres fragmentados y de los conjuntos de réplicas del servidor de configuración aproximadamente al mismo tiempo.
Bases de datos que ejecutan FCV 4.2 y versiones posteriores
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.
Funciones de copia de seguridad admitidas actualmente
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 |
| [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:
|
| [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. |
Requisitos y limitaciones
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
mongodclúster.
Nota
Si Ops Manager no administra su clúster:
Otorgue los
backuproles y al usuario de MongoDB que ejecuta copias de seguridad.clusterAdminAsegú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.
Sistema de archivos compartidos
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.
Bases de datos que ejecutan FCV 4.0 y versiones anteriores
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.
Las siguientes consideraciones se aplican cuando sus bases de datos ejecutan cualquier versión de MongoDB 4.0 o anterior o cuando ejecutan MongoDB 4.2 con
"featureCompatibilityVersion" : 4.0
Recolección de basura de instantáneas caducadas
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.
Filtro de espacios de nombres
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.
Crea Blacklist de los que quieres excluir o Whitelist de los que quieres incluir. Selecciona tus selecciones al iniciar una copia de seguridad y luego puedes editarlas según sea necesario. Si cambias el filtro de forma que se añadan datos a la copia de seguridad, será necesario resincronizar.
Utilice la lista negra 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 negra suele ser preferible a una lista blanca, ya que esta última requiere que se active intencionalmente cada espacio de nombres del que desee realizar una copia de seguridad.
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.
Motor de almacenamiento
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.
Resincronización de implementaciones de producción
Para implementaciones de producción, sincronice periódicamente todos los conjuntos de réplicas respaldados, por ejemplo, una vez al año. Al resincronizar, los datos se leen desde una réplica secundaria en cada conjunto de réplicas. Durante la resincronización, no se generan nuevas instantáneas.
También es posible que desees volver a sincronizar tu copia de seguridad si:
Reducir el tamaño de los datos, de modo que también se reduzca el tamaño de la copia de los datos de Ops Manager en el disco.
Crea un índice TTL, que elimina periódicamente documentos.
Eliminar una colección (solo MMAPv).1
Ejecute un clúster fragmentado y mueva fragmentos de un fragmento en particular.
Cambie los motores de almacenamiento si desea que Ops Manager proporcione instantáneas en el nuevo formato del motor de almacenamiento.
Construya un índice en un conjunto de réplicas de manera continua.
Puntos de control
Importante
Puede usar puntos de control para clústeres que ejecutan MongoDB con la versión de compatibilidad de funciones 4.0 o anterior. Se eliminaron los puntos de control de las instancias de MongoDB con la versión de compatibilidad de funciones 4.2 o posterior.
En clústeres fragmentados, los puntos de control proporcionan puntos de restauración adicionales entre instantáneas. Con los puntos de control habilitados, Ops Manager crea puntos de restauración a intervalos configurables 15 de, 30 o 60 minutos entre instantáneas. Para habilitar los puntos de control, consulte Habilitar puntos de control.
Para crear un punto de control, Ops Manager detiene el balanceador e inserta un token en el registro de operaciones de cada fragmento y servidor de configuración del clúster. Estos tokens de punto de control son ligeros y no afectan el rendimiento ni el uso del disco.
La copia de seguridad no requiere puntos de control y están desactivados por defecto.
La restauración desde un punto de control requiere que Ops Manager aplique el registro de operaciones de cada fragmento y servidor de configuración a la última instantánea capturada antes del punto de control. La restauración desde un punto de control tarda más que la restauración desde una instantánea.
Instantáneas cuando el agente no puede detener el balanceador
En clústeres fragmentados que se ejecutan con FCV 4.0 o versiones anteriores, Ops Manager deshabilita el balanceador antes de tomar una instantánea del clúster. En ciertas situaciones, como una migración prolongada o la ausencia de mongos en ejecución, Ops Manager intenta deshabilitar el balanceador, pero no puede. En tales casos, Ops Manager continúa tomando instantáneas del clúster, pero marca las instantáneas que pueden contener datos incompletos o inconsistentes. Las instantáneas del clúster tomadas durante una operación de balanceo activa corren el riesgo de perder datos o quedar huérfanas.
Instantáneas cuando el agente no puede contactar a un mongod
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.