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.
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 las mejores prácticas. No son 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 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 el Calculadora de rendimiento de red y no asume ninguna compresión de red adicional. |
frecuencia de snapshot y política de retención
Por defecto, 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 eliminará inmediatamente las instantáneas que estén dentro de las fechas de la política de retención actual.
Si detienes la copia de seguridad de una implementación, Cloud Manager deja de tomar nuevas instantáneas pero conserva las instantáneas existentes hasta la fecha de expiración 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) |
Daily snapshot | 7 días | 1 año |
snapshot semanal | 4 semanas | 1 año |
Snapshot mensual | 13 meses | 7 años |
Los cambios en el cronograma de instantáneas afectan los costos de almacenamientode tus instantáneas.
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.
No puedes cambiar la hora de referencia de un snapshot en Cloud Manager.
Límites
Cloud Manager no realiza copias de seguridad de implementaciones donde el número total de colecciones en la implementación cumpla o exceda
100,000.Cloud Manager no replica las opciones de la colección de índices.
Encriptación
No se pueden almacenar copias de seguridad utilizando el cifrado WiredTiger. Puedes almacenar copias de seguridad utilizando el motor de almacenamiento WiredTiger si no habilitas el cifrado. Si restauras desde una copia de seguridad, restauras archivos no cifrados.
Consideraciones sobre copias de seguridad
Coherencia y snapshots
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 el tiempo entre todas las particiones para los clústeres. 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:
Cloud Manager mantiene instantáneas consistentes ante fallos.
Cloud Manager realiza snapshots de cada una de las particiones para los clústeres y de los sets 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
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 rollback y avances (snapshots) que utilizan KMIP Cifrado [5] | ||
Admite snapshots que usan cifrado de clave local [6] | ||
Admite guardar en el almacenamiento de snapshots S3 | ||
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 por namespace solo es compatible con versiones del Cloud 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. |
| [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 que se haya eliminado 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] | FCV Las copias de seguridad 4.2 y posteriores no son compatibles con el cifrado de claves locales. |
| [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 límites
Para ejecutar copias de seguridad y restauraciones si utilizas MongoDB 4.2 o posterior con FCV 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 necesitas una base de datos fuente de sincronización. Cuando se toma una snapshot, Cloud Manager selecciona el miembro del set de réplicas con el menor impacto en el rendimiento y la mayor duplicación de los datos de la snapshot a nivel de almacenamiento.
Debe implementar un agente MongoDB con cada nodo del
mongodclúster.
Nota
Si Cloud Manager no administra 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.
Bases de datos que ejecutan compatibilidad de características entre versiones 4.0 o anterior
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
Colección de basura de snapshots expiradas
Cloud Manager gestiona las snapshots vencidas utilizando tareas de limpieza. Estas tareas de limpieza actúan de manera diferente según el almacenamiento de snapshot que contenga 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 | Se puede usar espacio adicional en disco si Cloud Manager crea un snapshot mientras la tarea de limpieza está en ejecución. Cloud 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.
Filtro de namespace
El filtro de namespaces te permite especificar qué base de datos y colecciones respaldar. Se crea un Deny List de los que se desea excluir o un Whitelist de los que se desea incluir. Se realizan tus selecciones al iniciar una copia de seguridad y posteriormente puedes editarla según sea necesario. Si se cambia el filtro de forma que se agrega datos a la copia de seguridad, se requiere una resincronización.
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. Usar una lista de denegación suele ser preferible a usar una lista blanca, ya que esta última requiere que optes intencionadamente por cada namespace que deseas proteger con backup.
Nota
El filtrado de namespaces solo es compatible con las versiones 6.0.8 y posteriores de Cloud Manager. 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, Cloud Manager limita las copias de seguridad a 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, 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 forma que también se reduzca el tamaño de la copia de los datos en disco de Cloud Manager.
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 Cloud Manager proporcione instantáneas en el nuevo formato de motor de almacenamiento.
Compilar un índice en un set de réplicas de manera progresiva.
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.
Para clústeres fragmentados, los puntos de control brindan puntos de restauración adicionales entre instantáneas. Con los puntos de control activados, Cloud Manager crea puntos de restauración en intervalos configurables de cada 15, 30 o 60 minutos entre instantáneas. Para activar los puntos de control, consulte active los puntos de control.
Para crear un punto de control, Cloud 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 Cloud Manager aplique el oplog de cada partición y 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 la restauración desde una snapshot.
Instantáneas cuando el agente no puede detener el equilibrador
Para clústeres que se ejecutan con compatibilidad de características entre versiones 4.0 o anterior, Cloud Manager deshabilita el balanceador antes de tomar un snapshot del cluster. En ciertas situaciones, como una migración prolongada o la ausencia de mongos en ejecución, Cloud Manager intenta deshabilitar el equilibrador pero no puede. En tales casos, Cloud Manager sigue tomando instantáneas del clúster, pero marca aquellas que podrían tener datos incompletos o inconsistentes. Las instantáneas de clúster tomadas durante una operación de equilibrio activa corren el riesgo de pérdida de datos o de datos huérfanos.
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.