Recuperación puntual (PITR)
IBM Cloud® Databases for MongoDB Enterprise Edition ofrece PITR utilizando cualquier indicación de fecha y hora mayor que el punto de recuperación disponible más temprano. Para descubrir el punto de recuperación más antiguo a través de la API, utilice el punto final de indicación de fecha y hora de recuperación de punto en el tiempo.
Al restaurar a un punto específico en los últimos 7 días, con un tiempo de restauración después de la última transacción, la restauración falla con el mensaje: recovery ended before configured recovery target is reached. Si la restauración
falla por este motivo, restaure hasta el último punto disponible o elija una fecha y hora anteriores para restaurar a un punto específico en los últimos 7 días.
{
"point_in_time_recovery_data": {
"earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
}
}
En esta fase, el punto final de la marca de tiempo de recuperación puntual siempre devuelve la hora actual, aproximadamente una semana.
Instantáneas
Enterprise EditionMongoDB ofrece PITR a través de instantáneas mantenidas por el Ops Manager.
Hay consideraciones específicas sobre PITR cuando PITR no es compatible.
PITR tras la actualización de la versión
Tras una actualización de versión, la recuperación a un momento determinado (PITR) para la nueva versión no estará disponible hasta que se haya completado una instantánea inicial de la implementación actualizada y se haya realizado una copia de seguridad de la misma mediante Ops Manager. La recuperación a un momento determinado solo puede restaurar los datos a un momento posterior a una actualización de versión principal una vez que se haya completado esta instantánea inicial. Esta instantánea no aparece en la lista de copias de seguridad disponibles. Solo se admite la vuelta a la versión anterior (en un plazo de 7 días desde la actualización) si dicha versión sigue siendo compatible.
PITR no estará disponible temporalmente para una versión hasta que se haya completado una instantánea de dicha versión y se haya realizado correctamente la copia de seguridad.
Recuperación
Las copias de seguridad se restauran en un nuevo despliegue. Después de que finalice el suministro del nuevo despliegue, los datos del archivo de copia de seguridad se restauran en el nuevo despliegue. Las copias de seguridad también se pueden restaurar entre cuentas, pero solo mediante la API y solo si el usuario que está ejecutando la restauración tiene acceso a las cuentas de origen y de destino.
La nueva implementación se configura automáticamente con la misma asignación de disco y memoria que la implementación de origen en el momento de la copia de seguridad a partir de la cual se realiza la restauración. Especialmente con PITR, es posible que ese no sea el tamaño actual de tu implementación. Si necesita ajustar los recursos asignados al nuevo despliegue, utilice los campos opcionales de la IU, la CLI o la API para cambiar el tamaño del nuevo despliegue. Si el despliegue no tiene suficientes recursos, la restauración falla, por lo tanto, asigne los suficientes para los datos y la carga de trabajo.
Mientras que el almacenamiento y la memoria se restauran igual que el despliegue de origen, las configuraciones específicas de la instancia no se establecen automáticamente para la nueva instancia. En este caso, puede ser necesario volver a
ejecutar la configuración después de una restauración. Anota cualquier modificación realizada en la instancia antes de ejecutar la restauración (parámetros como shared_buffers, max_connections, deadlock_timeout,
archive_timeout) para garantizar que la configuración de la instancia sea correcta una vez finalizada la restauración.
No suprima el despliegue de origen mientras la copia de seguridad se está restaurando. Debe esperar hasta que se suministre el nuevo despliegue y se restaure la copia de seguridad antes de suprimir el despliegue anterior. La supresión de un despliegue también suprime sus copias de seguridad. Por lo tanto, no sólo falla la restauración, sino que es posible que no pueda recuperar la copia de seguridad.
Recuperación a través de la interfaz de usuario
Una vez completada la primera copia de seguridad del despliegue, la opción de recuperación de punto en el tiempo se mostrará en la interfaz de usuario. Para iniciar una PITR, especifique la hora a la que desea volver a restaurar en la hora universal coordinada (UTC).
La indicación de fecha y hora de recuperación de punto en el tiempo debe tener el formato siguiente: %Y-%m-%dT%H:%M:%SZ.
Para restaurar a la hora más reciente disponible, selecciona esa opción. Al pulsar Restaurar aparecen las opciones de la recuperación. Especifique un nombre, y seleccione la versión, la región y los recursos disponibles para el nuevo despliegue. Pulse Recuperar para iniciar el proceso.
Si utilizas Key Protect y dispones de una clave, debes utilizar la CLI para la recuperación; para tu comodidad, se proporciona un comando.
Recuperación con la CLI
El controlador de recursos da soporte al suministro de despliegues de bases de datos, y el suministro y la restauración son responsabilidad de la CLI del controlador de recursos. Utilice el mandato resource service-instance-create.
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_NAME> <REGION> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP", "version":""}'
Los parámetros disponibles son:
instance_name(Obligatorio): El nombre legible por humanos de la nueva instancia a desplegar, por ejemplo,new-mongo.service_id(Obligatorio): En este contexto esdatabases-for-mongodb.service_plan_name(Obligatorio):standardoenterprise.region(Obligatorio): La región IBM Cloud® donde se desplegará la nueva base de datos, por ejemplo,eu-gb.point_in_time_recovery_deployment_id(Obligatorio): El ID del despliegue de origen (también conocido como CRN).point_in_time_recovery_time: el momento en el que se restaura la copia de seguridad, en el formato%Y-%m-%dT%H:%M:%SZ, Por ejemplo,2024-05-10T08:15:00Z. Deje este campo en blanco para obtener el último punto restaurable.version: La versión de la base de datos, por ejemplo, "6.0 ". Deje este campo en blanco para utilizar la versión preferida más reciente.key_protect_key: ID (CRN) del Key Protect recurso utilizado. Este campo es opcional para el cifrado BYOK (Traiga su propia clave).members_host_flavor: el tamaño del host de la instancia que desea implementar. Si no se proporciona, la nueva instancia se creará con la misma RAM y CPU que la instancia de origen. Consulte esta tabla para ver los valores disponibles.
Ejemplo
ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":""}'
Recuperación con la API
El controlador de recursos da soporte al suministro de despliegues de bases de datos, y el suministro y la restauración son responsabilidad de la API del controlador de recursos. Debe seguir los pasos necesarios para utilizar la API del controlador de recursos para poder utilizarlo para restaurar a partir de una copia de seguridad.
Una vez que tengas toda la información, la solicitud de creación es un POST dirigido al /resource_instances punto
de acceso.
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "<SERVICE_INSTANCE_NAME>",
"target": "<REGION>",
"resource_group": "<YOUR-RESOURCE-GROUP>",
"resource_plan_id": "<SERVICE-ID>",
"parameters": {
"point_in_time_recovery_time":"<TIMESTAMP>",
"point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
}
}'
Todos los campos siguientes son obligatorios:
name: El nombre legible por humanos de la nueva instancia que se implementará, por ejemplonew-mongo.resource_group: El ID del grupo de recursos, por ejemplo5c49eabc12fgt65resource_plan_id: En este contexto esto esdatabases-for-mongodb-enterprisetarget: El IBM Cloud región donde se implementará la nueva base de datos, por ejemploeu-gb. Se admiten las restauraciones entre regiones, salvo en el caso de restaurar una copia de seguridad deeu-deen otra región.
Además, un parameters El objeto se puede suministrar con los siguientes campos:
point_in_time_recovery_deployment_id: el ID de la implementación de origen (también conocido como CRN).point_in_time_recovery_time: el momento en el que se restaura la copia de seguridad, en el formato%Y-%m-%dT%H:%M:%SZ, Por ejemplo,2024-05-10T08:15:00Z. Deje este campo en blanco para obtener el último punto restaurable.version: La versión de la base de datos, por ejemplo, "6.0 ". Deje este campo en blanco para utilizar la versión preferida más reciente.key_protect_key: ID (CRN) del Key Protect recurso utilizado. Este campo es opcional para el cifrado BYOK (Traiga su propia clave).members_host_flavor: el tamaño del host de la instancia que desea implementar. Si no se proporciona, la nueva instancia se creará con la misma RAM y CPU que la instancia de origen. Ver el mesa para los valores disponibles.
La indicación de fecha y hora de recuperación de punto en el tiempo debe tener el formato siguiente: %Y-%m-%dT%H:%M:%SZ.
Restauración de una copia de seguridad con Terraform
Antes de restaurar, asegúrese de que point_in_time_recovery_time no tenga más de una semana. Si la marca de tiempo tiene más de 7 días, con una precisión de segundos, la validación falla.
Utilice el origen de datos ibm_database_point_in_time_recovery para restaurar la instancia de base de
datos con point_in_time_recovery.
La indicación de fecha y hora de recuperación de punto en el tiempo debe tener el formato siguiente: %Y-%m-%dT%H:%M:%SZ.
El script de Terraform tiene este aspecto.
terraform {
required_providers {
ibm = {
version = "1.44.3"
source = "IBM-Cloud/ibm"
}
}
}
variable "ibmcloud_api_key" {
description = "<Enter your IBM Cloud API Key>"
}
provider "ibm" {
region = "us-south"
ibmcloud_api_key = var.ibmcloud_api_key
}
data "ibm_resource_group" "default_group" {
is_default = true
}
resource "ibm_database" "mongodb_enterprise" {
resource_group_id = data.ibm_resource_group.default_group.id
name = "testing-mongodb-pitr"
service = "databases-for-mongodb"
plan = "enterprise"
location = "us-south"
point_in_time_recovery_deployment_id = "<crn>"
point_in_time_recovery_time = "2022-09-14T14:47:45Z"
}
Lo anterior restaurará a una nueva base de datos con el mismo tamaño de host y tamaño de disco que la fuente. Si desea modificar el tamaño del host o del disco de su implementación, consulte la Documentación de terraforma para el formato correcto.
Recuperación puntual (PITR) restauración offline
IBM Cloud® Databases for MongoDB Enterprise Edition requiere dos procesos para iniciar una restauración. En primer lugar, se toma una instantánea de Ops Manager AppDB. A continuación, esta instantánea sirve como copia de seguridad de PITR, que se puede utilizar para restaurar la base de datos.
En algunos recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. En estos escenarios, el proceso PITR puede fallar. En esos casos Databases for MongoDB Enterprise Edition La restauración sin conexión de recuperación puntual (PITR) se puede utilizar para restaurar a la última instantánea disponible. La opción de restauración fuera de línea garantiza la disponibilidad de los datos y la resiliencia del sistema en un caso en el que el método de instantánea no funciona como se esperaba.
Recuperación puntual (PITR) restauración offline a través de la interfaz de usuario
Inicie una restauración fuera de línea a través del panel de control IBM Cloud tal como lo haría para un PITR estándar. Elija la tercera opción de recuperación de punto en el tiempo.
Recuperación puntual (PITR) restauración offline a través de la CLI
Inicie una restauración fuera de línea mediante la CLI de IBM Cloud utilizando un mandato como:
ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":"", "offline_restore": true}'
Especifique los parámetros siguientes:
point_in_time_recovery_deployment_id: es el CRN de origen.point_in_time_recovery_time- Déjalo en blanco,"".offline_restore- Establece este valor en «true».
El resultado comando es el siguiente:
Creating service instance <INSTANCE_NAME> in resource group Default of account <ACCOUNT> as <USER>...
OK
Service instance <INSTANCE_NAME> was created.
Name: <INSTANCE_NAME>
ID: crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::
GUID: 3c647ad1-b9a8-2233-a47e-668d8b83e79f
Location: <LOCATION>
State: provisioning
Type: service_instance
Sub Type: Public
Service Endpoints: public
Allow Cleanup: false
Locked: false
Created at: 2023-08-03T09:36:37Z
Updated at: 2023-08-03T09:36:41Z
Last Operation:
Status create in progress
Message Started create instance operation
La indicación de fecha y hora de recuperación de punto en el tiempo debe tener el formato siguiente: %Y-%m-%dT%H:%M:%SZ.
Recuperación puntual (PITR) restauración offline a través de la API
El controlador de recursos da soporte al suministro de despliegues de bases de datos, y el suministro y la restauración son responsabilidad de la API del controlador de recursos. Complete los pasos necesarios para utilizar la API del controlador de recursos antes de utilizarla para restaurar a partir de una copia de seguridad.
Después de tener toda la información, la solicitud de creación es un POST para el /resource_instances que tendrá el aspecto siguiente:
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "<SERVICE_INSTANCE_NAME>",
"target": "<REGION>",
"resource_group": "<YOUR-RESOURCE-GROUP-ID>",
"resource_plan_id": "<SERVICE-ID>",
"parameters": {
"point_in_time_recovery_time":"<TIMESTAMP>",
"point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>",
"offline_restore": true
}
}'
Especifique los parámetros siguientes:
point_in_time_recovery_deployment_id: es el CRN de origen.point_in_time_recovery_time- Déjalo en blanco,"".offline_restore- Establece este valor en «true».
La indicación de fecha y hora de recuperación de punto en el tiempo debe tener el formato siguiente: %Y-%m-%dT%H:%M:%SZ.