Récupération ponctuelle (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition offre un PITR utilisant tout horodatage supérieur au point de récupération disponible le plus ancien. Pour reconnaître le point de récupération le plus ancien via l'API, utilisez le noeud final d'horodatage de récupération au point de cohérence.

Lors de la restauration à un point spécifique au cours des 7 derniers jours, avec une heure de restauration après la dernière transaction, votre restauration échoue avec le message: recovery ended before configured recovery target is reached. Si votre restauration échoue pour cette raison, effectuez la restauration au dernier point disponible ou choisissez une date et une heure antérieures pour la restauration à un point spécifique au cours des 7 derniers jours.

{
    "point_in_time_recovery_data": {
        "earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
    }
}

Dans cette phase, le point de terminaison de l'horodatage de récupération ponctuelle renvoie toujours l'heure actuelle, soit environ une semaine.

Instantanés

Enterprise EditionMongoDB propose PITR via des instantanés gérés par le Ops Manager.

Il existe des considérations spécifiques relatives au PITR lorsque celui-ci n'est pas pris en charge.

PITR après mise à niveau de version

La restauration ponctuelle permet de restaurer une version antérieure à une mise à niveau majeure dès que la sauvegarde est terminée. Le retour à la version antérieure à la mise à niveau majeure, au cours des 7 derniers jours, n'est autorisé que si cette version reste prise en charge.

PITR n'est pas disponible pour une version qui ne dispose pas d'une sauvegarde complète.

Récupération

Les sauvegardes sont restaurées dans un nouveau déploiement. Une fois que le nouveau déploiement a terminé la mise à disposition, vos données du fichier de sauvegarde sont restaurées dans le nouveau déploiement. Les sauvegardes sont également restaurables sur les comptes, mais uniquement à l'aide de l'API et uniquement si l'utilisateur qui exécute la restauration a accès aux comptes source et de destination.

Le nouveau déploiement est automatiquement dimensionné pour avoir la même allocation de disque et de mémoire que le déploiement source au moment de la sauvegarde à partir de laquelle vous effectuez la restauration. En particulier avec PITR, cela pourrait ne pas correspondre à la taille actuelle de votre déploiement. Si vous devez ajuster les ressources allouées au nouveau déploiement, utilisez les zones facultatives de l'interface utilisateur, de l'interface de ligne de commande ou de l'API pour redimensionner le nouveau déploiement. Si le déploiement ne dispose pas de suffisamment de ressources, la restauration échoue. Par conséquent, allouez suffisamment de ressources pour vos données et votre charge de travail.

Alors que le stockage et la mémoire sont restaurés au même niveau que le déploiement source, les configurations d'instance spécifiques ne sont pas automatiquement définies pour la nouvelle instance. Dans ce cas, il peut être nécessaire de réexécuter la configuration après une restauration. Notez toutes les modifications apportées à l'instance avant d'exécuter la restauration (paramètres tels que shared_buffers, max_connections, deadlock_timeout, archive_timeout) afin de garantir la précision des paramètres de l'instance une fois la restauration terminée.

Ne supprimez pas le déploiement source pendant la restauration de la sauvegarde. Vous devez attendre que le nouveau déploiement soit mis à disposition et que la sauvegarde soit restaurée avant de supprimer l'ancien déploiement. La suppression d'un déploiement supprime également ses sauvegardes. Par conséquent, non seulement la restauration échoue, mais vous risquez de ne pas être en mesure de récupérer la sauvegarde.

Récupération via l'interface utilisateur

Une fois la première sauvegarde de votre déploiement terminée, l'option de récupération à un point de cohérence s'affiche dans l'interface utilisateur. Pour lancer un PITR, entrez l'heure à laquelle vous souhaitez procéder à la restauration en temps universel coordonné.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Pour restaurer la dernière heure disponible, sélectionnez cette option. Lorsque vous cliquez sur Restaurer, les options de récupération s'affichent. Entrez un nom, sélectionnez la version, la région et les ressources allouées pour le nouveau déploiement. Cliquez sur Récupérer pour lancer le processus.

Si vous utilisez Key Protect et disposez d'une clé, vous devez utiliser l'interface CLI pour récupérer vos données. Une commande est fournie à cet effet pour vous faciliter la tâche.

Reprise avec l'interface de ligne de commande

Le contrôleur de ressources prend en charge la mise à disposition des déploiements de base de données, et la mise à disposition et la restauration sont la responsabilité de l'interface de ligne de commande du contrôleur de ressources. Utilisez la commande 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":""}'

Les paramètres disponibles sont les suivants :

  • instance_name (Obligatoire): Le nom lisible par l'homme de la nouvelle instance à déployer, par exemple, new-mongo.
  • service_id (obligatoire): Dans ce contexte, il s'agit de databases-for-mongodb.
  • service_plan_name (obligatoire): standard ou enterprise.
  • region (obligatoire): La IBM Cloud® région où la nouvelle base de données sera déployée, par exemple, eu-gb.
  • point_in_time_recovery_deployment_id (Obligatoire): L'identifiant du déploiement source (également connu sous le nom de CRN).
  • point_in_time_recovery_time: Le moment auquel la sauvegarde est restaurée, au format %Y-%m-%dT%H:%M:%SZ, Par exemple,2024-05-10T08:15:00Z. Laissez ce champ vide pour obtenir le dernier point restaurable.
  • version: La version de la base de données, par exemple "6.0 ". Laissez ce champ vide pour utiliser la dernière version préférée.
  • key_protect_key: ID (CRN) du Key Protect ressource utilisée. Ce champ est facultatif pour le cryptage BYOK (Bring Your Own Key).
  • members_host_flavor: taille de l'hôte d'instance que vous souhaitez déployer. Si elle n'est pas fournie, la nouvelle instance sera créée avec la même RAM et le même processeur que l'instance source. Voir ce tableau pour les valeurs disponibles.

Exemple

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":""}'

Récupération à l'aide de l'API

Le contrôleur de ressources prend en charge la mise à disposition des déploiements de base de données, et la mise à disposition et la restauration sont la responsabilité de l'API du contrôleur de ressources. Vous devez effectuer les étapes nécessaires à l'utilisation de l'API du contrôleur de ressources avant de pouvoir l'utiliser pour effectuer une restauration à partir d'une sauvegarde.

Une fois que vous disposez de toutes les informations, la demande de création est envoyée POST au /resource_instances point de terminaison.

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>"
    }
  }'

Les champs suivants sont tous obligatoires :

  • name: Le nom lisible par l'homme de la nouvelle instance à déployer, par exemple new-mongo.
  • resource_group: L'ID du groupe de ressources, par exemple 5c49eabc12fgt65
  • resource_plan_id: Dans ce contexte, c'est databases-for-mongodb-enterprise
  • target: Le IBM Cloud région où la nouvelle base de données sera déployée, par exemple eu-gb. Les restaurations interrégionales sont prises en charge, à l'exception de la restauration d'une eu-de sauvegarde vers une autre région.

De plus, un parameters L'objet peut être fourni avec les champs suivants :

  • point_in_time_recovery_deployment_id  : ID du déploiement source (également appelé CRN).
  • point_in_time_recovery_time: Le moment auquel la sauvegarde est restaurée, au format %Y-%m-%dT%H:%M:%SZ, Par exemple,2024-05-10T08:15:00Z. Laissez ce champ vide pour obtenir le dernier point restaurable.
  • version: La version de la base de données, par exemple "6.0 ". Laissez ce champ vide pour utiliser la dernière version préférée.
  • key_protect_key: ID (CRN) du Key Protect ressource utilisée. Ce champ est facultatif pour le cryptage BYOK (Bring Your Own Key).
  • members_host_flavor: taille de l'hôte d'instance que vous souhaitez déployer. Si elle n'est pas fournie, la nouvelle instance sera créée avec la même RAM et le même processeur que l'instance source. Voir le tableau pour les valeurs disponibles.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Restauration d'une sauvegarde avec Terraform

Avant de procéder à la restauration, assurez-vous que votre point_in_time_recovery_time n'a pas plus d'une semaine. Si l'horodatage remonte à plus de 7 jours, à la seconde près, la validation échoue.

Utilisez la source de données ibm_database_point_in_time_recovery pour restaurer votre instance de base de données avec point_in_time_recovery.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Votre script Terraform ressemble à ceci.

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"

}

Ce qui précède restaurera vers une nouvelle base de données avec la même taille d'hôte et la même taille de disque que la source. Si vous souhaitez modifier la taille de l'hôte ou la taille du disque de votre déploiement, reportez-vous au Documentation Terraform pour le bon formatage.

Restauration hors ligne avec récupération au point de départ (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition requiert deux processus pour lancer une restauration. Tout d'abord, une image instantanée de Ops Manager AppDBest prise. Cette image instantanée sert ensuite de sauvegarde PITR, qui peut être utilisée pour restaurer votre base de données.

Dans certaines reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception haute disponibilité à le gérer. Dans certains cas, le processus PITR peut échouer. Dans ces cas Databases for MongoDB Enterprise Edition La restauration hors ligne de récupération ponctuelle (PITR) peut être utilisée pour restaurer le dernier instantané disponible. L'option de restauration hors ligne garantit la disponibilité des données et la résilience du système dans le cas où la méthode d'image instantanée ne fonctionne pas comme prévu.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de l'interface utilisateur

Lancez une restauration hors ligne via le tableau de bord IBM Cloud comme vous le feriez pour un PITR standard. Choisissez la troisième option de reprise à un point de cohérence.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de la CLI

Lancez une restauration hors ligne via l'interface de ligne de commande IBM Cloud à l'aide d'une commande telle que:

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}'

Indiquez les paramètres suivants :

  • point_in_time_recovery_deployment_id-Il s'agit du CRN source.
  • point_in_time_recovery_time- Laissez ce champ vide. ""
  • offline_restore- Définissez cette valeur sur true.

La sortie de la commande ressemble à ceci :

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

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de l'API

Le contrôleur de ressources prend en charge la mise à disposition des déploiements de base de données, et la mise à disposition et la restauration sont la responsabilité de l'API du contrôleur de ressources. Effectuez les étapes nécessaires pour utiliser l'API du contrôleur de ressources avant de l'utiliser pour effectuer une restauration à partir d'une sauvegarde.

Une fois que vous disposez de toutes les informations, la demande de création est un POST du /resource_instances qui se présente comme suit:

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
    }
  }'

Indiquez les paramètres suivants :

  • point_in_time_recovery_deployment_id-Il s'agit du CRN source.
  • point_in_time_recovery_time- Laissez ce champ vide. ""
  • offline_restore- Définissez cette valeur sur true.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.