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 demonio de copia de seguridad creaba la restauración completa a un punto en el tiempo en su host. Con 3.6, se descarga una herramienta del lado del cliente junto con la instantánea. Esta herramienta descarga y aplica el oplog a una instantánea en el sistema cliente. Esto reduce las necesidades de red y almacenamiento para la implementación de Ops Manager.
Considerations
Revisar el cambio al subtipo BSON BinData
La especificación BSON cambió el subtipo predeterminado para el tipo de datos binarios BSON (BinData) de 2 a 0. Algunos datos binarios almacenados en una instantánea pueden ser BinData subtipo 2. Backup detecta y convierte automáticamente los datos de instantánea BinData subtipo 2 a BinData subtipo 0. Si el código de su aplicación espera BinData subtipo 2, debe actualizarlo para que funcione 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 FCV deben cumplir con las consideraciones de copia de seguridad pertinentes.
Consideraciones sobre el cifrado
Para restaurar desde una copia de seguridad cifrada, necesita la misma clave maestra utilizada para cifrar la copia de seguridad y el mismo certificado que se encuentra en el host del demonio de copia de seguridad o un nuevo certificado proporcionado 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 número de segundos transcurridos desde la época UNIX.
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
Seleccione el proyecto al que desea restaurar la instantánea.
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.
Importante
Rotar la clave maestra después de la restauración de snapshots cifrados con AES256-GCM
Si restaura una instantánea cifrada que Ops Manager cifró con AES256-GCM, gire su 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
Restaure la instantánea manualmente solo si no puede realizar una restauración automática. Si determina que debe usar una restauración manual, comuníquese con el soporte de MongoDB para obtener ayuda. Esta sección ofrece una descripción general de las etapas del 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 conjunto de réplicas y al conjunto de réplicas del servidor de configuración (CSRS) con el shell heredado o con
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.
Detenga todos los procesos
mongodque se estén ejecutando en los hosts de destino.Provisiona suficiente espacio de almacenamiento para alojar los datos restaurados.
Prepare los directorios para los datos y registros.
Agregue un archivo de configuración al directorio de su servidor MongoDB con las rutas de almacenamiento y registro del host de destino, así como la configuración para las réplicas y los roles de fragmentación.
Nota
Para la restauración a un punto específico del tiempo
Antes de reiniciar
mongodcomo un nuevo conjunto de réplicas de nodo único, restaure las instantáneas puntuales en un nodo CSRS.Restaura el conjunto de réplicas de cada partición.
Nota
Para la restauración a un punto específico del tiempo
Antes de reiniciar
mongodcomo un nuevo conjunto de réplicas de nodo único, restaure las instantáneas puntuales en el nodo de cada fragmento.
El procedimiento completo de restauración manual se encuentra en la documentación de MongoDB Server 4.2. Para implementaciones de MongoDB 4.4 o posteriores, consulte las versiones correspondientes del manual.