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 Restore Overview.
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 creó la restauración a un punto específico del tiempo en su host. Con 3.6, se descarga una herramienta del lado del cliente junto con tu snapshot. Esta herramienta descarga y aplica el oplog a una snapshot en tu sistema cliente. Esto reduce las necesidades de red y almacenamiento para tu implementación de Ops Manager.
Considerations
Revisar el cambio a BinData Subtipo BSON
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 instantánea pueden ser de subtipo BinData 2. La copia de seguridad detecta y convierte automáticamente los datos de la snapshot en el subtipo BinData 2 al subtipo BinData 0. Si el código de tu aplicación espera el subtipo BinData 2, debes actualizar tu código para funcionar con el subtipo BinData 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
Opciones de inicio de mongod utilizadas en la base de datos cuando se tomó la instantánea
cifrado (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
Todo Las bases de datosFCV deben cumplir con las consideraciones de respaldo adecuadas.
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 instantánea está cifrada, el panel de restauración muestra el ID de la clave maestra de KMIP y la información del servidor KMIP. También puede encontrar esta información al visualizar la propia instantánea y 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:
Seleccione el punto de restauración.
Elija el punto desde el que desea restaurar su copia de seguridad.
Tipo de restauraciónDescripciónAcciónSnapshot
Le permite elegir una instantánea 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 selecciona
12:00, la última operación en la restauración será11:59:59o anterior.Seleccione Date y 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.
Escriba 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 administrar el clúster fragmentado 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.
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
mongoomongosh.(Opcional). Revise el archivo de configuración de cada conjunto de réplicas y el CSRS. Tras completar el proceso de restauración, puede reconstruir la configuración de los conjuntos 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.
Preparar directorios para 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.