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.
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 Cloud 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 Cloud Manager a su almacenamiento de respaldo.
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 la Calculadora de rendimiento de red y no asume ninguna compresión de red adicional. |
Política de frecuencia y retención de instantáneas
De forma predeterminada, Cloud Manager toma una instantánea base de sus datos cada 6 horas.
Si lo desean, los administradores pueden cambiar la frecuencia de las instantáneas base a 6, 8, 12 o 24 horas. Cloud Manager crea instantáneas automáticamente según una programación; no se pueden tomar instantáneas a demanda.
Cloud Manager conserva instantáneas durante los períodos de tiempo que se indican en la siguiente tabla.
Si finaliza la copia de seguridad de una implementación, Cloud 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, Cloud 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 7 | año de 1 |
Instantánea semanal | semanas de 4 | año de 1 |
Instantánea mensual | meses de 13 | 7años |
Los cambios en el cronograma de instantáneas afectan los costos de almacenamiento de instantáneas.
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.
No puedes cambiar el tiempo de referencia de una instantánea en Cloud Manager.
Límites
Cloud 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.Cloud Manager no replica las opciones de recopilación de índices.
Encriptación
No se pueden almacenar copias de seguridad con el cifrado de WiredTiger. Sin embargo, sí se pueden almacenar con el motor de almacenamiento de WiredTiger si no se activa el cifrado. Si se restaura desde una copia de seguridad, se restauran los archivos sin cifrar.
Consideraciones sobre copias de seguridad
Coherencia e instantáneas
Para clústeres que ejecutan MongoDB versión 4.2 o posterior:
Cloud Manager mantiene la coherencia causal al tomar instantáneas, excepto las estadísticas de tamaño reportadas por collStats y.
db.[collection].count()Estas estadísticasdb.[collection].count()pueden ser inexactas.Cloud 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:
Cloud Manager mantiene instantáneas consistentes ante fallos.
Cloud 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
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 | ||
Admite instantáneas que utilizan CifradoKMIP []5 | ||
Admite snapshots que usan cifrado de clave local [6] | ||
Admite el guardado en almacenamiento de instantáneas S3 | ||
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 Cloud 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] | Cloud 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] | FCV 4.2 y las copias de seguridad posteriores no admiten el cifrado de clave local. |
| [7] | Las copias de seguridad de una FCV 4.2 base de datos o posterior en un almacén del sistema de archivos File System Store Gzip Compression Level 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 se necesita una base de datos de origen sincronizada. Al tomar una instantánea, Cloud Manager selecciona el miembro del conjunto de réplicas con el menor impacto en el rendimiento y la mayor duplicación de datos de la instantánea a nivel de almacenamiento.
Debe implementar un agente MongoDB con cada nodo del
mongodclúster.
Nota
Si Cloud 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.
Bases de datos que ejecutan FCV 4.0 y versiones anteriores
Importante
Solo se pueden realizar copias de seguridad de clústeres fragmentados o conjuntos de réplicas. Para realizar una copia de seguridad de un proceso mongod independiente, debe convertirlo en un conjunto de réplicas de un solo miembro.
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
Cloud 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 | Se puede usar espacio de disco adicional si Cloud Manager crea una instantánea mientras se ejecuta el trabajo de limpieza. Cloud 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.
Filtro de espacios de nombres
El filtro de espacios de nombres permite especificar las bases de datos y colecciones que se respaldarán. Se crea un Deny List de las que se excluirán o un Whitelist de las que se incluirán. Se realizan las selecciones al iniciar una copia de seguridad y se pueden editar posteriormente según sea necesario. Si se modifica el filtro de forma que se añadan datos a la copia de seguridad, se requiere una resincronización.
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 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 Cloud 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, Cloud 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 en el disco de Cloud Manager.
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 Cloud 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 Feature Compatibility Version de 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con FCV 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, Cloud 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, Cloud 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 Cloud 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 el caso de clústeres fragmentados que se ejecutan con FCV 4.0 o versiones anteriores, Cloud 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, Cloud Manager intenta deshabilitar el balanceador, pero no puede. En tales casos, Cloud 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, Cloud Manager no crea la instantánea y muestra un mensaje de advertencia.