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 copia de seguridad.
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
Tu rendimiento de red declarado, como 10 Gbps o 100 Gbps, es un máximo teórico. Ese valor no tiene en cuenta el uso compartido ni la limitación del tráfico de red.
Considera 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 copia de seguridad.
La conexión de red tiene una pérdida de paquetes muy baja y un tiempo de retraso de ida y vuelta bajo.
Una copia de seguridad completa de tus datos puede tardar 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 una única unidad de almacenamiento NVMe o una unidad de almacenamiento NVMe reflejada.
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 asumir que no hay compresión adicional de la red. |
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 un cronograma; no se pueden realizar instantáneas on-demand.
Cloud Manager retiene instantáneas durante los períodos de tiempo enumerados 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.
snapshot | Política de retención por defecto | 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 coherencia causal al tomar snapshots, excepto por las estadísticas de tamaño informadas por collStats y
db.[collection].count(). Las estadísticas de tamaño reportadas por collStats ydb.[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 snapshots coherentes en caso de 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 filtrar usando los 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 a una FCV 4.2 o base de datos posterior a un almacenamiento de sistema de archivos ignoran File System Store Gzip Compression Level. |
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.
Debes tener en cuenta el cambio en el tamaño del bloque de almacenamiento en bloques. Si no configuraste tu tamaño de bloque y utilizaste la configuración por defecto, ese tamaño de bloque cambia de 64 KB a 1 MB. Esto puede afectar el uso del almacenamiento.
Debe asegurarse de que los nombres de host en su configuración de set de réplicas coincidan con los nombres de host que utiliza el MongoDB Agent, o que sus mapeos de hosts contengan los nombres de host correctos. Puedes usar rs.conf() para verificar la configuración de tu set 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.
Se debe implementar un MongoDB Agent con cada nodo
mongoden el clúster.
Nota
Si Cloud Manager no administra tu clúster:
Concede los
backupyclusterAdminroles al usuario de MongoDB que ejecuta las copias de seguridad.Asegú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 sets de réplicas o clústeres. Para respaldar un proceso **autónomo** de mongod, debes convertirlo en un **set de réplicas** de un solo **nodo**.
Las siguientes consideraciones se aplican cuando tus 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 |
|---|---|
Almacenamiento en bloques de MongoDB | Utiliza espacio adicional en disco hasta la cantidad de bloques activos para cada tarea. |
Almacenamientos de snapshot | Elimina snapshots caducadas |
almacén de snapshots 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 respaldar los clústeres de MongoDB, usa el motor de almacenamiento WiredTiger motor de almacenamiento.
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 el almacenamiento MMAPv1. 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 una mongod
Para clústeres particionados, si la Copia de Seguridad no puede como acceder a un proceso mongod, ya sea una partición como o un servidor de configuración, el agente no puede insertar un token de oplog de sincronización. En estos casos, Cloud Manager no crea el snapshot y muestra un mensaje de advertencia.