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.
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 supports five backup architectures, each with its own strengths and trade-offs. Consider the architecture that meets the data protection requirements for your deployment before configuring and deploying your backup architecture.
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.
Conversely, consider a system whose requirements include a low Recovery Time Objective. The system's owners tolerate greater storage costs if it results in a backup and recovery configuration that fulfills the recovery requirements.
Ops Manager Enterprise Backup and Recovery admite las siguientes arquitecturas de respaldo:
A file system on a SAN with advanced features for filesystem backups, such as high availability, compression, or deduplication
A file system on one or more NAS devices
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.
Características del método de respaldo
Función de respaldo del sistema | File System on SAN | Sistema de archivos en NAS | Almacén de bloques de AWS S3 | MongoDB HA Blockstore | Almacén de bloques de MongoDB |
|---|---|---|---|---|---|
Tipos de instantáneas | Complete * | Complete * | 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?
To run backups frequently on large amounts of data and restore from backups, consider backing up to a file system on a SAN, an AWS S3-compatible storage snapshot store, or a MongoDB blockstore configured as a replica set or a sharded cluster.
To restore data without relying on MongoDB database, consider backing up to an AWS S3-compatible storage snapshot store, one or more NAS devices, or a file system on a SAN with advanced features for file system backups, such as high availability, compression, or deduplication.
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 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
When sizing the backup of your data, keep the replica set size to 2 TB or less of uncompressed data. If your database increases beyond 2 TB of uncompressed data:
Fragmentar la base de datos
Keep each shard to 2 TB or less of uncompressed data
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.
The network connection has very low packet loss and a low round trip delay time.
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 sucesiva depende de la carga de escritura.
Si fragmenta esta base de datos en cuatro fragmentos, cada uno ejecuta su copia de seguridad por separado. Esto da como resultado una copia de seguridad que tarda menos de ocho 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 | 0 días | 1 año |
Instantánea semanal | 2 semanas | 1 año |
Instantánea mensual | 1 mes | 7 años |
Nota
Las instantáneas mensuales son instantáneas completas de forma predeterminada, no instantáneas incrementales.
You can change a backed-up deployment's schedule through its Edit Snapshot Schedule menu option, available through the Backup page. Administrators can change snapshot frequency and retention through the snapshotSchedule resource in the 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 today |
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 does not backup deployments where the total number of collections on the deployment meets or exceeds
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 takes snapshots from each of the shards for sharded clusters and the Config Server Replica Sets at approximately the same time.
Bases de datos que ejecutan FCV 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.
Funciones de copia de seguridad admitidas actualmente
Característica | Bases de datos que ejecutan FCV 4.2 y posteriores | Bases de datos que ejecutan FCV 4.0 y anteriores |
|---|---|---|
Backs up Data using WiredTiger Snapshots | ||
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 | ||
Can Filter using Namespaces [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] | ||
Supports Saving to blockstore snapshot storage | ||
Admite guardar en almacenamiento compatible con S3 Almacenamiento 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 o anteriores, o 6.0.1 o posteriores. |
| [3] | Performing a PIT restore requires Ops Manager 4.2.13 or later. |
| [4] | Ops Manager requires a full backup for your first backup, after a snapshot has been deleted, and if the blockstore block size has been changed. Incremental backups reduce network transfer and storage costs.This feature works with:
|
| [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
If you configure Ops Manager to use multiple Ops Manager application servers behind an HTTP or HTTPS load balancer and use file system snapshots, FCV 4.2 or later backup snapshot jobs run in parallel on one or more servers. Ensure that you have a shared file system mounted on each Ops Manager server. The Ops Manager application server might open and write different offsets of the same files. Ensure that the shared file system allows this. Otherwise, you will encounter access errors.
Bases de datos que ejecutan FCV 4.0 y 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.
The following considerations apply when your databases run any version of MongoDB 4.0 or earlier or when they run MongoDB 4.2 with
"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 de 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 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 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.
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.
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:
With WiredTiger, Ops Manager limits backups to deployments with fewer than 100,000 files. Files includes collections and indexes.
MongoDB 4.2 removes MMAPv1 storage. To learn more about storage engines, see Storage in the MongoDB manual.
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
You may use checkpoints for clusters that run MongoDB with Feature Compatibility Version of 4.0 or earlier. Checkpoints were removed from MongoDB instances with FCV of 4.2 or later.
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.
Snapshots when Agent Can't Contact a 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.
Consideraciones sobre copias de seguridad regionales
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:
Administrar el almacenamiento de instantáneas compatible con S3
Administrar el almacenamiento de instantáneas del sistema de archivos
Además, debe asociar uno de cada uno de los siguientes elementos con una región de implementación:
tienda de sincronización (a menos que
mms.backup.noSyncStateconfiguretrueen)
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.