Cuando restaures un clúster desde una snapshot, Ops Manager te proporcionará archivos de restauración para el punto de restauración seleccionado.
Para aprender sobre el proceso de restauración, consulta Descripción general de la restauración.
Importante
Válido en Ops Manager 3.6: Restauraciones a un punto específico del tiempo
Antes de 3.6, el daemon de copias de seguridad creaba la restauración a un punto específico del tiempo completa en su host. Con 3.6, descarga una herramienta del lado del cliente junto con su snapshot. Esta herramienta descarga y aplica el oplog a un snapshot en su sistema cliente. Esto reduce las necesidades de red y almacenamiento para su implementación de Ops Manager.
Considerations
Revisar cambio al sub-tipo BSON BinData
La especificación BSON cambió el subtipo por defecto para el tipo de datos binarios BSON (BinData) de 2 a 0. Algunos datos binarios almacenados en una snapshot pueden ser del subtipo BinData 2. La copia de seguridad detecta automáticamente y convierte los datos de snapshot en BinData subtipo 2 a BinData subtipo 0. Si el código de tu aplicación espera BinData subtipo 2, deberás actualizar tu código para trabajar con BinData subtipo 0.
Tip
Las notas sobre la especificación BSON explican los detalles específicos de este cambio.
Restaurar usando la configuración dada en restoreInfo.txt
El archivo de copia de seguridad de restauración incluye un archivo de metadatos llamado restoreInfo.txt. Este archivo recopila las opciones que utilizó la base de datos cuando se tomó la snapshot. La base de datos debe ejecutarse con las opciones mencionadas después de haber sido restaurada. Este archivo contiene:
Nombre del grupo
Nombre del set de réplicas
ID del clúster (si corresponde)
snapshot timestamp (como marca de tiempo en UTC)
Restaurar marca de tiempo (como marca de tiempo BSON en UTC)
Última Oplog aplicada (como un Timestamp BSON en UTC)
Versión de MongoDB
Tipo de motor de almacenamiento
mongod startup optionsutilizado en la base de datos cuando se tomó la snapshotcifrado (Solo aparece si se habilita el cifrado en el snapshot)
UUID de clave maestra (solo aparece si el cifrado está activado en la snapshot)
Si se está realizando una restauración desde una copia de seguridad cifrada, debe de tener un certificado establecido para esta clave maestra.
Consideraciones sobre copias de seguridad
Todas las bases de datos de FCV deben cumplir con las consideraciones de copia de seguridad.
Consideraciones sobre el cifrado
Para la restauración desde una copia de seguridad cifrado, necesitas la misma clave maestra que se utilizó para cifrar la copia de seguridad y ya sea el mismo certificado que se encuentra en el host del daemon de copias de seguridad o un nuevo certificado aprovisionado con esa clave desde el host KMIP.
Si la snapshot está cifrada, el panel de restauración muestra el ID de la clave maestra KMIP y la información del servidor KMIP. También puedes encontrar la información al visualizar la snapshot como en el archivo restoreInfo.txt.
Deshabilitar las solicitudes de cliente a MongoDB durante la restauración
Debe asegurarse de que la implementación de MongoDB no reciba solicitudes de clientes durante la restauración. Debe hacer una de las siguientes cosas:
Restaura en nuevos sistemas con nuevos hostnames y vuelve a configurar el código de tu aplicación una vez que la nueva implementación esté en funcionamiento, o bien
Asegúrese de que la implementación de MongoDB no reciba solicitudes de cliente mientras restaura datos.
Restaurar una instantánea
Para que Ops Manager restaure automáticamente la snapshot:
Selecciona el punto de restauración.
Elige el punto del que deseas restaurar tu copia de seguridad.
Tipo de restauraciónDescripciónAcciónSnapshot
Permite elegir una snapshot almacenada.
Selecciona una snapshot existente para restaurar.
Point In Time
Crea una instantánea personalizada que incluye todas las operaciones hasta, pero sin incluir, la hora seleccionada. Por defecto, Oplog Store almacena 24 horas de datos.
Por ejemplo, si seleccionas
12:00, la última operación en la restauración será11:59:59o anterior.El cuadro de diálogo de restauración también muestra el restorable time ranges para la implementación. Solo puede elegir una hora que se encuentre dentro de uno de estos rangos. Si la hora que desea no está disponible, existe una brecha de oplog para ese período.
Seleccione un Date y un Time.
Oplog Timestamp
Crea un snapshot personalizado que incluye todas las operaciones hasta e incluyendo la marca de tiempo Oplog ingresada. La marca de tiempo Oplog contiene dos campos:
Timestamp
marca de tiempo en el número de segundos que han transcurrido desde el Unix epoch
Increment
Orden de la operación aplicada en ese momento como un valor ordinal de 32 bits.
Escribe un Oplog Timestamp y Increment.
Ejecute una query contra
local.oplog.rsen su set de réplicas para encontrar la marca de tiempo deseada.Haga clic en Next.
Elija restaurar los archivos en otro clúster.
Haga clic en Choose Cluster to Restore to.
Complete los siguientes campos:
CampoAcciónProject
Cluster to Restore to
Seleccione un clúster al que quiera restaurar el snapshot.
Ops Manager debe gestionar el clúster sharded de destino.
ADVERTENCIA: La automatización remueve todos los datos existentes del clúster. Preserva todas las copias de seguridad y las snapshots para el clúster existente.
Haga clic en Restore.
Ops Manager anota cuánto espacio de almacenamiento requiere la restauración en su Interfaz de Usuario.
Haz clic Restoreen.
Importante
Rotar la clave maestra después de la restauración de snapshots cifrados con AES256-GCM
Si restauras una snapshot cifrada que Ops Manager cifró con AES256-GCM, rota tu clave maestra después de completar la restauración.
El proceso de restauración manual asume que:
El host de destino no cuenta con ningún dato.
No has utilizado una snapshot cifrada.
No ha activado la autenticación de dos factores.
Advertencia
Restaura la snapshot manualmente sólo si no puedes ejecutar una restauración automática. Si determina que debe usar una restauración manual, contacte al soporte de MongoDB para obtener ayuda. Esta sección proporciona una visión general de las etapas en el procedimiento de restauración manual.
El proceso de restauración manual tiene las siguientes etapas generales que realizas con la ayuda del equipo de soporte de MongoDB:
Conéctese a cada set de réplicas y al set de réplicas del servidor de configuración (CSRS) usando el shell heredado o
mongosh.(opcional). Revise el archivo de configuración de cada set de réplicas y CSRS. Una vez completado el proceso de restauración, puede reconstruir la configuración en los sets de réplicas restaurados utilizando los archivos de configuración guardados.
Deten todos los procesos
mongodque se ejecutan en los hosts de destino.Provisiona suficiente espacio de almacenamiento para alojar los datos restaurados.
Prepare los directorios para los datos y registros.
Agrega un archivo de configuración al directorio de tu MongoDB Server con las rutas de almacenamiento y registro del host de destino, y la configuración para réplicas y roles de particionado.
El procedimiento completo de restauración manual se puede encontrar en la documentación de MongoDB Server 4.2. Para implementaciones de MongoDB 4.4 o posteriores, consulta las versiones correspondientes del manual.