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 así lo desean, los administradores pueden cambiar la frecuencia de las instantáneas base a 6, 8, 12 o 24 horas. Ops Manager crea snapshots automáticamente siguiendo un cronograma. También puedes tomar snapshots 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.
Ops Manager siempre conserva al menos una instantánea restaurable para una implementación respaldada. En la práctica, esto significa que si una serie de trabajos de copia de seguridad fallan y el período de retención configurado provocaría la expiración de todas las instantáneas existentes, Ops Manager pospone la optimización de la instantánea más reciente que se haya realizado correctamente hasta que se complete una nueva copia de seguridad exitosa.
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. Utiliza cursores de copia de seguridad en lugar de bases de datos principales para cifrar tareas de copia de seguridad. Para más información, consulte Servicio daemon de copias de seguridad.
Consideraciones sobre copias de seguridad
Coherencia y snapshots
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.
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.
Copias de seguridad incrementales
Ops Manager crea identificadores para cada archivo de la base de datos durante las copias de seguridad incrementales. Asegúrese de que el límite de archivos abiertos sea mayor que el número de archivos antes de realizar una copia de seguridad incremental. Como alternativa, realice una copia de seguridad completa en lugar de una incremental.
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.
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.
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.
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.