Création automatique de sauvegardes

Lorsque vous provisionnez une instance « Cloud Databases » de génération 2, le système crée automatiquement des instances de sauvegarde indépendantes pour vos sauvegardes quotidiennes planifiées. Ces sauvegardes :

• Sont créés quotidiennement selon votre planning de sauvegarde
• Persiste pendant 30 jours par défaut
• Sont gérés automatiquement par le service
• Apparaître dans votre liste de ressources et dans votre centre de bases de données

Création de sauvegardes à la demande

Vous pouvez créer à tout moment des sauvegardes indépendantes à la demande à l'aide du contrôleur de ressources « IBM Cloud ». Ces sauvegardes :

• Sont créés immédiatement sur demande
• Appliquer les mêmes politiques de conservation que pour les sauvegardes automatiques
• Peut être supprimé manuellement avant son expiration
• Sont utiles avant des changements majeurs ou des migrations

Cycle de vie des sauvegardes

Les sauvegardes indépendantes suivent le cycle de vie suivant :

1. Provisionnement: une instance de sauvegarde est créée (automatiquement ou à la demande)
2. Actif: la sauvegarde est disponible pour les opérations de restauration
3. Expiration: la sauvegarde arrive à la fin de sa période de conservation (30 jours par défaut)
4. Suppression: la sauvegarde est supprimée automatiquement ou manuellement

Contrairement aux sauvegardes couplées, les sauvegardes indépendantes peuvent être supprimées manuellement à tout moment via le Contrôleur de ressources, ce qui vous offre un meilleur contrôle sur vos données de sauvegarde et les coûts associés.

Configuration de l'instance de base de données pour des sauvegardes indépendantes

Vous pouvez configurer les fonctionnalités suivantes sur l'instance de base de données :

Vous pouvez définir la configuration autorisée dans les paramètres de provisionnement de l'instance de base de données. Par exemple, la configuration suivante permet de conserver les sauvegardes même après la suppression de la base de données :

ibmcloud resource service-instance-create \
  <DATABASE_INSTANCE_NAME> \
  <DATABASE_SERVICE_NAME> \
  <DATABASE_SERVICE_PLAN_NAME> \
  <REGION> \
  -g <RESOURCE_GROUP> \
  -p '{
    "dataservices": {
      "backups": {"preserve": true}
    }
  }'

Vous pouvez définir l'option preserve dans la demande de provisionnement de l'instance de base de données. L'exemple suivant permet de configurer l'instance de base de données afin de conserver les sauvegardes après la suppression de celle-ci :

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<DATABASE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE-GROUP>",
    "resource_plan_id": "<DATABASE_SERVICE_PLAN_NAME>",
    "parameters": {
      "dataservices": {
        "backups": {
          "preserve": true
        }
      }
    }
  }'

Vous pouvez configurer des sauvegardes automatiques à l'aide de la requête Terraform suivante :

Exemple :

data "ibm_resource_group" "rg" {
  name = var.resource_group_name
}
resource "ibm_database" "backup_configuration_test" {
  name              = "<DATABASE_INSTANCE_NAME>"
  resource_group_id = data.ibm_resource_group.rg.id
  service = "<DATABASE_SERVICE_NAME>"
  plan    = "<DATABASE_SERVICE_PLAN_ID>"
  location          = "<GEN2-REGION>"
  service_endpoints = "private"
  backups {
    retention = 30
    preserve = true
    automatic_backups {
      copy {
        enabled = true
        target = [
          {
            region = "<TARGET-GEN2-REGION>"
          }
        ]
      }
    }
  }
}

Restauration à partir d'une sauvegarde indépendante

Les sauvegardes indépendantes peuvent être restaurées sur une nouvelle instance de base de données même si l'instance source n'existe plus, ce qui offre une plus grande flexibilité dans les scénarios de reprise après sinistre et de conservation des données.

Les sauvegardes sont restaurées sur une nouvelle instance. Une fois le provisionnement de la nouvelle instance terminé, vos données contenues dans le fichier de sauvegarde sont restaurées sur la nouvelle instance.

Par défaut, la nouvelle instance est automatiquement dimensionnée en fonction de la taille de disque par défaut et de la taille d'hôte de l'instance source au moment de la sauvegarde à partir de laquelle vous effectuez la restauration. Pour ajuster les ressources allouées à la nouvelle instance, utilisez les champs facultatifs de l'interface utilisateur, de la ligne de commande ou de l'API afin de redimensionner la nouvelle instance. Veillez à allouer suffisamment de ressources pour vos données et votre charge de travail; si l'instance ne dispose pas de ressources suffisantes ou si la sauvegarde occupe plus d'espace que la taille par défaut du disque et qu'aucune taille de disque n'a été spécifiée, la restauration échouera.

Ne supprimez pas la sauvegarde pendant sa restauration. Avant de supprimer la sauvegarde, attendez que la nouvelle instance soit mise en service et que la sauvegarde soit restaurée. La suppression de l'instance de base de données entraîne également, par défaut, la suppression de ses sauvegardes.

Vous disposez d'un accès immédiat à l'instance de base de données restaurée, mais les performances d'E/S sont réduites jusqu'à ce que l'hydratation soit terminée. Il n'est pas possible de créer des sauvegardes sur l'instance restaurée tant que l'hydratation n'est pas terminée. Vous pouvez suivre vos progrès en matière d'hydratation grâce aux événements de la plateforme « Activity Tracker ». Pour plus d'informations, consultez la rubrique « at-events ».

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<DATABASE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE-GROUP>",
    "resource_plan_id": "<DATABASE_SERVICE_PLAN_NAME>",
    "parameters": {
      "dataservices": {
        "restore_backup_id": "<BACKUP_CRN>"
      }
    }
  }'

Exemple :

  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "mysql-restore-abc",
    "target": "us-east",
    "resource_group": "b67d9228670d473097259e2b343de464",
    "resource_plan_id": "databases-for-mysql-gen2-standard",
    "parameters": {
      "dataservices": {
        "restore_backup_id": "crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"
      }
    }
  }'

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID>-gen2-<PLAN NAME> <REGION> -p  '{"dataservices":{"restore_backup_id":"<BACKUP_CRN>"}}'

ibmcloud resource service-instance-create mysql-restore-abc databases-for-mysql databases-for-mysql-gen2-standard us-east -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"}}'

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> gen2-<PLAN NAME> <REGION> -p
'{"restore_backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "storage_gb":"DESIRED_DISK_IN_GB", "host_flavor": "<VALUE>"}'

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters":{
      "restore_backup_id": "<BACKUP_ID>"
    }
  }'

Chiffrement des sauvegardes

Les sauvegardes indépendantes sont chiffrées au repos à l'aide du même algorithme de chiffrement que celui utilisé pour l'instance de base de données. Si vous utilisez « Key Protect » pour gérer le chiffrement de votre base de données, vos sauvegardes sont chiffrées avec la même clé. Pour plus d'informations, consultez la section « Intégration de Key Protect ».

Lorsque vous restaurez une sauvegarde qui a été chiffrée à l'aide d'une clé « Key Protect », vous pouvez utiliser cette même clé ou une autre clé. Si vous utilisez une autre clé, la nouvelle instance est chiffrée avec cette nouvelle clé.

Disponibilité d'une version inter-régions

Une sauvegarde ne peut être copiée que lorsqu'elle est à l'état Actif. La région cible doit être différente de la région source.

Les sauvegardes copiées sont créées sous forme d'instances de sauvegarde indépendantes dans la région cible et ne peuvent être restaurées que dans cette région. Par exemple, si une sauvegarde existe dans et ca-mon que vous souhaitez la restaurer dans in-che, vous devez d'abord créer une copie de la sauvegarde dans in-che, puis effectuer la restauration à partir de cette copie.

Vous pouvez configurer des sauvegardes automatiques inter-régions pour une instance de base de données. Une seule région cible peut être configurée pour les copies de sauvegarde, et celle-ci doit être différente de la région de l'instance de base de données. Vous pouvez sélectionner n'importe quelle région prise en charge comme région cible.

Vous pouvez également désactiver les copies de sauvegarde automatiques entre régions en supprimant la région cible configurée de la configuration de l'instance de base de données à l'aide de l'interface utilisateur, de l'API ou de la CLI.

Si aucune région cible n'est spécifiée et que les sauvegardes automatiques sont activées, les régions cibles par défaut suivantes sont appliquées à l'instance de base de données.

Bases de données dotées de sauvegardes indépendantes

Les bases de données répertoriées dans le tableau passent actuellement d'un système de sauvegardes couplées à un système de sauvegardes indépendantes dans les régions spécifiées.

Les sauvegardes indépendantes seront activées progressivement pour les bases de données et les régions concernées.

Pendant la période de transition de 30 jours :

• Les sauvegardes couplées et les sauvegardes indépendantes coexistent.
• Toutes les nouvelles sauvegardes sont créées en tant que sauvegardes indépendantes.
• Les sauvegardes couplées existantes continuent de fonctionner et sont automatiquement supprimées au bout de 30 jours.
• L'interface utilisateur affiche les deux types de sauvegarde.
• Aucune action n'est nécessaire. La transition s'effectue automatiquement.
• À l'issue de la période de transition de 30 jours, seules les sauvegardes indépendantes seront conservées.

MySQL

Databases for MySQL ne prend en charge que les sauvegardes indépendantes à partir de la mise à disposition générale. Il n'y a pas de sauvegardes couplées ni de période de transition pour les déploiements d' MySQL.