Antes de realizar una copia de seguridad del clúster o set de réplicas, decide cómo respaldar los datos y qué datos respaldar. Esta página describe los elementos que se deben considerar antes de iniciar una copia de seguridad.
Tip
Para aprender cómo funciona la copia de seguridad, revisa Apoyo.
Opciones de configuración de copia de seguridad
Los requisitos de copia de seguridad y recuperación de un sistema dado varían para satisfacer los estándares de costos, rendimiento y protección de datos que establece el propietario del sistema.
Ops Manager Enterprise Copia de seguridad and Recovery admite cinco arquitecturas de copia de seguridad, cada una con sus propias fortalezas y compensaciones. Considera la arquitectura que satisfaga los requisitos de protección de datos para tu implementación antes de configurar e implementar tu arquitectura de copia de seguridad.
Ejemplo
Considere un sistema cuyos requisitos incluyan bajos costos operativos. Los propietarios del sistema pueden tener límites estrictos sobre lo que pueden gastar en almacenamiento para su configuración de copia de seguridad y recuperación. Como resultado, pueden aceptar un tiempo de recuperación más largo.
Por el contrario, considere un sistema cuyos requisitos incluyen un bajo objetivo de tiempo de recuperación. Los propietarios del sistema toleran costos de almacenamiento más altos si eso resulta en una configuración de copia de seguridad y recuperación que cumpla con los requisitos de recuperación.
Ops Manager Enterprise Backup y recuperación soporta las siguientes arquitecturas de copia de seguridad:
Un sistema de archivos en un SAN con funcionalidades avanzadas para copias de seguridad de sistemas de archivos, como alta disponibilidad, compresión o deduplicación
Un sistema de archivos en uno o más dispositivos NAS
Almacenamiento en bloques de MongoDB en una configuración altamente disponible
MongoDB almacenamiento en bloques en una configuración autónomo
Proporcionamos recomendaciones sobre la arquitectura de copia de seguridad como orientación para desarrollar tus propios enfoques de protección de datos. Nuestras recomendaciones no cubren ni representan cada escenario o implementación.
Características del método de respaldo
Funcionalidad del sistema de copia de seguridad | Sistema de archivos en SAN | Sistema de archivos en NAS | AWS S3 almacenamiento en bloques | MongoDB HA Blockstore | Almacén de bloques de MongoDB |
|---|---|---|---|---|---|
Tipos de instantáneas | Completa * | Completa * | Muchos parciales | Muchos parciales | Muchos parciales |
Copia de seguridad Deduplicación de datos | Si la SAN permite. | No | Sí | Sí | Sí |
Compresión de datos de copia de seguridad | Sí | No | Sí | Sí | Sí |
Replicación de datos de copia de seguridad | Si la SAN permite. | 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 File System Store, el MongoDB Agent divide cada archivo de motor de almacenamiento ubicado en la ruta especificada para la copia de seguridad en bloque(s) de datos y transfiere únicamente el/los bloque(s) modificado(s) a Ops Manager. Ops Manager crea una nueva snapshot de los bloques recibidos y copia el/los bloque(s) restantes que no se hayan modificado de la copia de seguridad completa anterior. Cada instantánea incremental de copia de seguridad almacenada en un sistema de archivos ahorra E/S de red. Cada una de estas snapshot de copia de seguridad contiene una copia completa de todos los archivos necesarios de una implementación respaldada de MongoDB y no deduplica los registros.
Nota
¿Cuándo utilizar un método de backup en particular?
Para ejecutar copias de seguridad frecuentemente en grandes cantidades de datos y restauración desde copias de seguridad, considere hacer copias de seguridad en un sistema de archivos en un SAN, un almacenamiento de snapshot compatible con AWS S3, o un almacenamiento en bloques de MongoDB configurado como un set de réplicas o un clúster.
Para restaurar datos sin depender de la base de datos MongoDB, considere realizar una copia de seguridad en un almacén de instantáneas de almacenamiento compatible con AWS S3, 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 S3 o en un almacén de bloques independiente de MongoDB.
Un almacenamiento en bloques autónomo de MongoDB ofrece una resiliencia limitada. Si el disco se llena, este almacenamiento en bloques puede desconectarse. Puedes recuperar instantáneas de copia de seguridad únicamente después de agregar almacenamiento adicional.
Recomendación de tamaño de copia de seguridad
Al dimensionar la copia de seguridad de tus datos, mantén el tamaño del set de réplicas en 2 TB o menos de datos sin comprimir. Si su base de datos aumenta más allá de 2 TB de datos sin comprimir:
Fragmenta la base de datos
Mantén cada partición 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 30 horas en completarse. [1]
Esto no tiene en cuenta las velocidades de lectura y escritura del disco, que pueden ser, como máximo, 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 depende de la carga de escritura.
Si crea particiones en esta base de datos en 4 particiones, cada partición ejecutará su copia de seguridad por separado. Esto resulta en una copia de seguridad que tarda menos de 8 horas en completarse.
| [1] | Estas cifras de rendimiento se calcularon utilizando los métodos estándar de la industria para medir el rendimiento de red y suponen que no hay compresión de red adicional. |
frecuencia de snapshot y política de retención
Por defecto, Ops Manager toma una instantánea base de tus datos cada 24 horas.
Si se desea, 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 un cronograma; no se pueden tomar instantáneas on-demand.
Ops Manager retiene los snapshots durante los períodos de tiempo listados en la siguiente tabla.
Si terminas la copia de seguridad de una implementación, Ops Manager borra inmediatamente las snapshots que se encuentran dentro de las fechas de la política de retención actual.
Si se detiene la copia de seguridad de una implementación, Ops Manager deja de tomar nuevas snapshots, pero conserva las snapshots existentes hasta la fecha de caducidad listada.
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) |
Daily snapshot | 0 días | 1 año |
snapshot semanal | 2 semanas | 1 año |
Snapshot mensual | 1 mes | 7 años |
Nota
Las instantáneas mensuales son instantáneas completas de forma predeterminada, no instantáneas incrementales.
Puedes cambiar el cronograma de una implementación respaldada a través de su Edit Snapshot Schedule opción de menú, disponible en la página Backup. Los administradores pueden cambiar la frecuencia y retención de snapshots a través de recurso snapshotSchedule en la API.
Cambiar la hora de referencia cambia la hora de la próxima instantánea programada. No se puede hacer que la siguiente snapshot programada ocurra antes de la hora de la siguiente snapshot. La hora de la siguiente instantánea actual corresponde a la hora de referencia actual más el intervalo entre instantáneas.
Para determinar la hora del próximo snapshot, compare la hora actual del próximo snapshot 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 | Hora de referencia actual | Intervalo entre snapshot | Hora de la siguiente snapshot actual | Nueva hora de referencia | Hora de la próxima snapshot |
|---|---|---|---|---|---|
08:00 UTC | 12:00 UTC | 6 horas | 12:00 UTC | 10:00 UTC | 16:00 UTC 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 tarea de copia de seguridad almacenada en una base de datos principal que ejecute MongoDB Enterprise entre compatibilidad de características entre versiones 3.4 y 4.0 con el motor de almacenamiento WiredTiger.
compatibilidad de características entre versiones 4.2 y luego use cursores de copia de seguridad en lugar de bases de datos principales. Para obtener más información, consulte Servicio Daemon de copia de seguridad.
Consideraciones sobre copias de seguridad
Coherencia y snapshots
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 entre todas las particiones de los clústeres particionados. Esto garantiza que los snapshots incluyan todos los documentos recopilados en cada partición y nodo en el momento programado para el snapshot.
Para clústeres que ejecutan MongoDB versión 4.0 y anteriores:
Ops Manager mantiene snapshots coherentes 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 compatibilidad de características entre versiones 4.2 y 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.
Funcionalidades de copia de seguridad admitidas actualmente
funcionalidad | Bases de datos corriendo compatibilidad de características entre versiones 4.2 y versiones posteriores | Bases de datos que ejecutan compatibilidad de características entre versiones 4.0 y versiones anteriores |
|---|---|---|
Realiza copias de seguridad de datos usando snapshots 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 la 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 el almacenamiento de instantáneas del almacenamiento en bloques | ||
Admite guardar en Almacenamiento de instantáneas compatible con S3 | ||
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 de MongoDB con copia de seguridad habilitada en cada |
| [2] | El filtrado de namespace solo se admite para las versiones 6.0.8 y posteriores de Ops Manager. Las 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 tu primera copia de seguridad, después de que se haya borrado una snapshot y si se ha cambiado el tamaño de bloque del almacenamiento en bloques. Las copias de seguridad incrementales reducen la transferencia de red y los costos de almacenamiento. Esta funcionalidad funciona con:
|
| [5] | Consultar una snapshot cifrada requiere MongoDB Enterprise 4.2.9 o posterior o 4.4.0 o posterior. |
| [6] | compatibilidad de características entre versiones 4.2 y las copias de seguridad posteriores no son compatibles con 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 límites
Para ejecutar copias de seguridad y restauraciones si ejecutas MongoDB 4.2 o posterior con compatibilidad de características entre versiones 4.2 o posterior, debes:
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.
Puede utilizar las listas de filtros de namespaces para definir los namespaces incluidos en una copia de seguridad solo si utiliza sistemas MongoDB 6.0 o más recientes. Las instantáneas tomadas en las versiones de MongoDB 4.2 a la 5.0 siempre incluyen todos los nombres de espacio.
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 gestiona tu 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 MongoDB Agent 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 compatibilidad de características entre versiones 4.0 o anterior
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
Colección de basura de snapshots expiradas
Ops Manager gestiona las instantáneas caducadas utilizando trabajos de limpieza. Estas tareas de limpieza actúan de manera diferente dependiendo de en qué almacenamiento de snapshot se encuentren los snapshots:
almacenamiento de snapshot | Cómo funcionan los trabajos de limpieza |
|---|---|
Almacén de bloques de MongoDB | Utiliza espacio adicional en disco hasta la cantidad de bloques activos para cada tarea. |
Almacenamientos de snapshot | Elimina snapshots caducadas |
Almacenes de instantáneas de S3 | Puede usar espacio adicional en disco si Ops Manager crea una snapshot mientras se ejecuta la tarea de limpieza. Ops Manager puede ejecutar tareas de limpieza concurrentes en los almacenes de snapshots de 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 namespace
El filtro de namespaces te permite especificar qué base de datos y colecciones respaldar. Puedes aplicar un filtro de namespace a cualquier base de datos, excepto admin y local, y cualquier colección que no comience con system.
Tip
Si aplica filtros de espacio de nombres a una instantánea, no podrá consultar esa instantánea.
Puede crear un Deny List con las colecciones a excluir o un Allow List con las colecciones a incluir. Puede hacer sus selecciones al comenzar una copia de seguridad y luego editarlas según sea necesario.
Utiliza la lista de denegación para impedir la copia de seguridad de las colecciones que contienen datos de registro, cachés u otros datos temporales. Excluir esta clase de bases de datos y colecciones te permitirá reducir el tiempo y los costos de las copias de seguridad. Utilizar una lista de denegación suele ser preferible a utilizar una lista de permitidos, ya que una lista de permitidos requiere que optes intencionadamente por cada namespace que desees respaldar.
Nota
El filtrado de namespace sólo es compatible con versiones de Ops Manager 6.0.8 y posteriores. Tus implementaciones de MongoDB deben tener featureCompatibilityVersion valores 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 tus bases de datos de respaldo actuales utilizan MMAPv1, actualiza a WiredTiger:
Con WiredTiger, Ops Manager limita las copias de seguridad a despliegues 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, resincroniza todos los sets de réplicas respaldados periódicamente, por ejemplo, una vez al año. Cuando vuelvas a sincronizar, los datos se leerán desde un secundario en cada set de réplicas. Durante la resincronización, no se generan nuevas instantáneas.
También puede querer resincronizar su copia de seguridad si:
Reducir el tamaño de los datos, de tal manera que el tamaño de la copia de los datos en disco de Ops Manager también se reduzca.
Crea un índice TTL, que elimina periódicamente documentos.
Descartar una colección (únicamente MMAPv1).
Ejecuta un clúster particionado y transfiere fragmentos de una partición específica.
Cambie los motores de almacenamiento si desea que Ops Manager proporcione instantáneas en el nuevo formato del motor de almacenamiento.
Compilar un índice en un set de réplicas de manera progresiva.
Puntos de control
Importante
Puedes utilizar puntos de control para clústeres que ejecuten MongoDB con la compatibilidad de características entre versiones del 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con una compatibilidad de características entre versiones de 4.2 o superior.
Para clústeres fragmentados, los puntos de control brindan puntos de restauración adicionales entre instantáneas. Con los puntos de control activados, Ops Manager crea puntos de restauración a intervalos configurables de cada 15, 30 o 60 minutos entre snapshot. Para activar los puntos de control, consulte active los puntos de control.
Para crear un punto de control, Ops Manager detiene el balanceador e inserta un token en el oplog de cada partición y servidor de configuración en el clúster. Estos tokens de punto de control son livianos 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.
Restaurar desde un punto de control requiere que el Ops Manager aplique el oplog de cada partición y el servidor de configuración a la última snapshot capturada antes del punto de control. La restauración desde un punto de control lleva más tiempo que restaurar desde un snapshot.
Instantáneas cuando el agente no puede detener el equilibrador
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
Para clústeres particionados, si la copia de seguridad no puede alcanzar un proceso de mongod, ya sea una partición o el servidor de configuración, entonces el agente no puede insertar un oplog de sincronización. En estos casos, Ops Manager no crea la snapshot y muestra un mensaje de advertencia.
Consideraciones sobre copias de seguridad regionales
Para habilitar Copia de seguridad regional, debes asociar al menos uno de los siguientes elementos con la región de implementación que un set de réplicas o partición selecciona como objetivo:
Gestione el almacenamiento de snapshots de almacenamiento en bloques
Administrar el almacenamiento de instantáneas compatible con S3
Gestionar el almacenamiento de snapshot del sistema de archivos
Además, debe asociar uno de cada uno de los siguientes elementos con una región de implementación:
almacén de sincronización (a menos que ajustes
mms.backup.noSyncStateentrue)
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.