Utiliser la récupération à un moment précis (PITR)

MySQL | PostgreSQL | SQL Server

Cette page explique comment utiliser la récupération à un moment précis (PITR) pour restaurer votre instance Cloud SQL principale.

Pour en savoir plus sur la récupération PITR, consultez la section Récupération PITR.

Par défaut, la récupération PITR est activée lorsque vous créez une instance Cloud SQL Enterprise Plus, que vous utilisiez la console Google Cloud, gcloud CLI, Terraform ou L'API Cloud SQL Admin

Si vous créez une instance Cloud SQL Enterprise dans la console Google Cloud, la récupération PITR est activée par défaut. Sinon, si vous créez l'instance à l'aide de gcloud CLI, de Terraform ou de l'API Cloud SQL Admin, vous devez activer manuellement la récupération à un moment précis.

Stockage des journaux pour la récupération PITR

Cloud SQL utilise des journaux binaires pour la récupération PITR.

Le 11 août 2023, nous avons lancé le stockage des journaux de transactions pour la récupération PITR dans Cloud Storage. Depuis ce lancement, les conditions suivantes s'appliquent :

Toutes les instances de l'édition Cloud SQL Enterprise Plus stockent leurs journaux binaires utilisés pour la récupération à un moment précis dans Cloud Storage. Seules les instances Cloud SQL Enterprise Plus que vous avez mises à niveau depuis l'édition Cloud SQL Enterprise avant le 1er avril 2024 et pour lesquelles la récupération PITR a été activée avant le 11 août 2023 continuent de stocker leurs journaux pour la récupération PITR sur le disque.
Les instances Cloud SQL Enterprise créées avec la récupération PITR activée avant le 11 août 2023 continuent de stocker leurs journaux sur le disque.
Si vous mettez à niveau une instance Cloud SQL Enterprise après le 1er avril 2024 qui stocke les journaux de transactions pour la récupération PITR sur disque vers l'édition Cloud SQL Enterprise Plus, le processus de mise à niveau change l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis vers Cloud Storage. Pour en savoir plus, consultez la page Mettre à niveau une instance vers l'édition Cloud SQL Enterprise Plus à l'aide de la mise à niveau sur place.
Toutes les instances Cloud SQL Enterprise que vous créez avec la récupération PITR activée après le 11 août 2023 stockent les journaux utilisés pour la récupération PITR dans Cloud Storage.

Pour savoir comment vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération PITR, consultez la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis.

Pour les instances qui ne stockent les journaux binaires que sur le disque, vous pouvez également déplacer les journaux du disque vers Cloud Storage en désactivant, puis en réactivant la récupération PITR.

Durée de conservation des journaux

Cloud SQL conserve les journaux de transactions dans Cloud Storage jusqu'à atteindre la valeur définie dans le paramètre de configuration de la récupération PITR transactionLogRetentionDays. Cette valeur peut aller de 1 à 35 jours pour l'édition Cloud SQL Enterprise Plus et de 1 à 7 jours pour l'édition Cloud SQL Enterprise. Si aucune valeur n'est définie pour ce paramètre, la durée de conservation des journaux de transactions par défaut est de 14 jours pour les instances Cloud SQL Enterprise Plus et de sept jours pour les instances de l'édition Cloud SQL Enterprise. Pour en savoir plus sur la définition des jours de conservation des journaux de transactions, consultez Définir la durée de conservation des journaux de transactions.

Bien qu'une instance stocke les journaux binaires utilisés pour la récupération à un moment précis dans Cloud Storage, elle conserve également un nombre plus faible de journaux binaires sur le disque pour permettre leur réplication sur Cloud Storage. Par défaut, lorsque vous créez une instance avec la récupération PITR activée, celle-ci stocke ses journaux binaires pour la récupération PITR dans Cloud Storage. Cloud SQL définit également automatiquement la valeur des options expire_logs_days et binlog_expire_logs_seconds sur l'équivalent d'un jour. Cela correspond à une journée de journaux sur le disque.

En réduisant la valeur de ces paramètres d'option, Cloud SQL vous aide à réduire les coûts d'utilisation du disque. Toutefois, si vous souhaitez que des journaux supplémentaires soient disponibles sur le disque, par exemple pour parcourir les journaux binaires avec l'utilitaire mysqlbinlog, augmentez les valeurs de ces options. Cloud SQL conserve les journaux sur le disque pendant la durée minimale de conservation des journaux de transactions ou pendant les valeurs définies pour les options.

Pour les journaux binaires utilisés pour la récupération PITR et stockés sur le disque, Cloud SQL conserve les journaux correspondant à la valeur minimale définie pour l'une des configurations suivantes:

Le paramètre de configuration de sauvegarde transactionLogRetentionDays
L'option expire_logs_days ou binlog_expire_logs_seconds

La modification des valeurs de ces options peut affecter le comportement de la récupération PITR et le nombre de jours durant lesquels les journaux sont stockés sur le disque. Nous vous déconseillons de configurer la valeur de ces options sur 0. Pour en savoir plus sur ces options, consultez la section Configurer des options de base de données.

Pour les instances où la clé de chiffrement gérée par le client (CMEK) est activée, les journaux binaires sont chiffrés à l'aide de la dernière version de CMEK. Pour effectuer une restauration, toutes les versions de la clé les plus récentes correspondant au nombre de jours configurés pour le paramètre retained-transaction-log-days doivent être disponibles.

Journaux et utilisation du disque

De nouveaux journaux sont générés régulièrement et utilisent de l'espace de stockage. Les journaux binaires, ainsi que leur sauvegarde automatique, sont automatiquement supprimés, après que la valeur définie pour transactionLogRetentionDays soit atteinte.

Pour connaître la quantité de disque utilisée par les journaux binaires, consultez la métrique bytes_used_by_data_type de l'instance. La valeur du type de données binlog renvoie la taille des binlogs sur le disque. Pour les instances qui stockent les journaux de transactions utilisés pour la récupération PITR sur le disque, Cloud SQL supprime définitivement les données du disque quotidiennement afin de respecter le paramètre de récupération PITR transactionLogRetentionDays, comme décrit dans la section Sauvegarde automatique et conservation des journaux de transactions. Toutefois, si vous définissez l'option expire_logs_days sur une valeur inférieure au nombre de jours de conservation des journaux de transactions, Cloud SQL peut supprimer définitivement le binaire plus tôt.

Si la taille de vos journaux binaires pose problème pour votre instance :

Vérifiez si votre instance stocke les journaux sur le disque. Pour déplacer les journaux utilisés pour la récupération PITR du disque vers Cloud Storage, désactivez et réactivez la récupération PITR. Cette opération entraîne un temps d'arrêt de quelques minutes, mais libère de l'espace disque. Si vous utilisez l'édition Cloud SQL Enterprise, vous pouvez également passer à l'édition Cloud SQL Enterprise Plus pour changer l'emplacement de stockage de vos journaux PITR.
Vous pouvez augmenter l'espace de stockage disponible sur celle-ci. Sachez toutefois qu'une augmentation importante de l'espace disque occupé par vos journaux binaires peut être temporaire.
Nous vous recommandons d'activer l'augmentation automatique de l'espace de stockage pour éviter tout problème de stockage inattendu.
Si vous souhaitez supprimer des journaux et récupérer de l'espace de stockage, vous pouvez désactiver la récupération PITR sans la réactiver. Cependant, la réduction du stockage utilisé ne réduit pas la taille du disque provisionné pour l'instance.
Les journaux sont supprimés définitivement une fois par jour, et non de manière continue. Si vous définissez la durée de conservation des journaux sur une valeur de deux jours, cela signifie qu'au moins deux jours et au plus trois jours de journaux sont conservés. Nous vous recommandons de définir le nombre de sauvegardes à une valeur correspondant à la durée de conservation des journaux plus un, afin de garantir un minimum de jours spécifiés de rétention des journaux.

Pour en savoir plus sur la récupération PITR, consultez la page Récupération PITR.

Activer la récupération PITR

Lorsque vous créez une instance dans Google Cloud Console, les options de sauvegardes automatisées et d'activation de la récupération à un moment précis sont automatiquement activées.

La procédure suivante active la récupération PITR sur une instance principale existante.

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Ouvrez le menu "Autres actions" au niveau de l'instance pour laquelle vous souhaitez activer la récupération PITR, puis cliquez sur Modifier.
Sous Personnaliser votre instance, développez la section Protection des données.
Cochez la case Activer la récupération à un moment précis.
Développez les options avancées.
Indiquez le nombre de jours de conservation des journaux, compris entre 1 et 35 pour l'édition Cloud SQL Enterprise Plus, ou entre 1 et 7 pour l'édition Cloud SQL Enterprise.
Cliquez sur Enregistrer.

gcloud

Affichez la présentation de l'instance :

gcloud sql instances describe INSTANCE_NAME

Si la mention enabled: false s'affiche dans la section backupConfiguration, activez les sauvegardes planifiées :
```
gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM
```
Spécifiez le paramètre backup-start-time au format 24 heures dans le fuseau horaire UTC ± 00.
Activez la récupération PITR :
```
gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log
```
Si vous activez la récupération PITR sur une instance principale, vous pouvez également configurer le nombre de jours pendant lesquels vous souhaitez conserver les journaux de transactions en ajoutant le paramètre suivant :
```
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
```
Confirmez la modification :
```
gcloud sql instances describe INSTANCE_NAME
```
Dans la section backupConfiguration, vous voyez le message binaryLogEnabled: true s'afficher si la modification a réussi.

Terraform

Pour activer la récupération PITR, utilisez une ressource Terraform.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Appliquer les modifications

Pour appliquer votre configuration Terraform dans un projet Google Cloud, suivez les procédures des sections suivantes.

Préparer Cloud Shell

Lancez Cloud Shell.
Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.

Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.

Préparer le répertoire

Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).

Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension .tf, par exemple main.tf. Dans ce tutoriel, le fichier est appelé main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.

Copiez l'exemple de code dans le fichier main.tf que vous venez de créer.

Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.
Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
Enregistrez les modifications.
Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire.
```
terraform init
```
Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option -upgrade :
```
terraform init -upgrade
```

Appliquer les modifications

Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes :
```
terraform plan
```
Corrigez les modifications de la configuration si nécessaire.
Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité :
```
terraform apply
```
Attendez que Terraform affiche le message "Apply completed!" (Application terminée).
Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud, accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.

Supprimer les modifications

Pour supprimer vos modifications, procédez comme suit :

Pour désactiver la protection contre la suppression, définissez l'argument deletion_protection sur false dans le fichier de configuration Terraform.
```
deletion_protection =  "false"
```
Appliquez la configuration Terraform mise à jour en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité :
```
terraform apply
```

Supprimez les ressources précédemment appliquées à votre configuration Terraform en exécutant la commande suivante et en saisissant yes à l'invite :
```
terraform destroy
```

REST v1

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
START_TIME : heure (en heures et en minutes).

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Remarque : La commande suivante suppose que vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login, ou en utilisant Cloud Shell, qui vous connecte automatiquement à la CLI gcloud. Vous pouvez exécuter gcloud auth list pour vérifier le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell (Windows)

Remarque:La commande suivante suppose que vous vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login. Vous pouvez exécuter gcloud auth list pour vérifier le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
START_TIME : heure (en heures et en minutes).

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Réaliser une récupération PITR à l'aide d'un horodatage

L'utilisation de l'horodatage est l'approche recommandée pour effectuer une récupération à un moment précis. Cloud SQL se sert de l'utilitaire mysqlbinlog pour restaurer des instances jusqu'à une heure spécifique. Pour en savoir plus sur l'utilitaire mysqlbinlog, consultez la documentation de référence MySQL.

Pour effectuer la tâche suivante, vous devez disposer des éléments suivants :

Journalisation binaire et sauvegardes de l'instance activées, avec journalisation binaire continue depuis la dernière sauvegarde précédant l'événement à partir duquel vous souhaitez effectuer la récupération Pour en savoir plus, consultez la section Activer la journalisation binaire.
Un horodatage pour définir le point de récupération. Les événements qui se produisent au moment et après cet horodatage ne sont pas reflétés dans la nouvelle instance.

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Ouvrez le menu "Autres actions" pour l'instance que vous souhaitez récupérer, puis cliquez sur Créer un clone.
Vous pouvez également mettre à jour l'ID du nouveau clone sur la page Créer un clone.
Sélectionnez Cloner à partir d'un moment antérieur.
Saisissez la date et l'heure de la récupération PITR.
Cliquez sur Create clone (Créer un clone).

gcloud

Créez un clone à l'aide de la récupération PITR.

Remplacez les éléments suivants :

SOURCE_INSTANCE_NAME : nom de l'instance à partir de laquelle vous effectuez la restauration.
NEW_INSTANCE_NAME : nom du clone.
TIMESTAMP : fuseau horaire UTC de l'instance source au format RFC 3339. Exemple : 2012-11-15T16:19:00.094Z.

gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST v1

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

project-id : ID du projet
target-instance-id : ID de l'instance cible
source-instance-id : ID de l'instance source
restore-timestamp : moment jusqu'auquel effectuer la restauration

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Corps JSON de la requête :

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

project-id : ID du projet
target-instance-id : ID de l'instance cible
source-instance-id : ID de l'instance source
restore-timestamp : moment jusqu'auquel effectuer la restauration

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Corps JSON de la requête :

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Désactiver la récupération PITR

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Ouvrez le menu "Autres actions" pour l'instance que vous souhaitez désactiver, puis sélectionnez Modifier.
Sous Personnaliser votre instance, développez la section Protection des données.
Désactivez l'option Activer la récupération à un moment précis.
Cliquez sur Enregistrer.
Sur la page Présentation de l'instance, sous Configuration, le paramètre de récupération PITR apparaît comme étant désactivé.

gcloud

Désactivez la récupération à un moment précis :

gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log

Confirmez la modification :
```
gcloud sql instances describe INSTANCE_NAME
```
Dans la section backupConfiguration, vous voyez le message binaryLogEnabled: false s'afficher si la modification a réussi.

REST v1

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

project-id : ID du projet
instance-id : ID de l'instance.

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

project-id : ID du projet
instance-id : ID de l'instance.

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis

Vous pouvez vérifier où votre instance Cloud SQL stocke les journaux de transactions utilisés pour la récupération à un moment précis.

gcloud

Pour déterminer si votre instance stocke les journaux pour la récupération PITR sur le disque ou sur Cloud Storage, utilisez la commande suivante:

   gcloud sql instances describe INSTANCE_NAME

Remplacez INSTANCE_NAME par le nom de l'instance.

Dans le résultat de la commande, le champ transactionalLogStorageState fournit des informations sur l'emplacement de stockage des journaux de transactions pour la récupération PITR pour l'instance. Les états de stockage des journaux de transactions possibles sont les suivants:

DISK: l'instance stocke les journaux de transactions utilisés pour la récupération PITR sur le disque. Si vous mettez à niveau une instance Cloud SQL Enterprise vers l'édition Cloud SQL Enterprise Plus, le processus de mise à niveau bascule également l'emplacement de stockage des journaux vers Cloud Storage. Pour en savoir plus, consultez la page Mettre à niveau une instance vers l'édition Cloud SQL Enterprise Plus à l'aide de la mise à niveau sur place.
SWITCHING_TO_CLOUD_STORAGE: l'instance bascule l'emplacement de stockage des journaux de transactions PITR vers Cloud Storage.
SWITCHED_TO_CLOUD_STORAGE: l'instance a terminé le changement d'emplacement de stockage des journaux de transactions PITR du disque vers Cloud Storage.
CLOUD_STORAGE: l'instance stocke les journaux de transactions utilisés pour la récupération à un moment précis dans Cloud Storage.

Définir la durée de conservation des journaux de transaction

Pour définir le nombre de jours de conservation des journaux binaires, procédez comme suit :

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Ouvrez le menu "Autres actions" pour l'instance pour laquelle vous souhaitez définir les journaux de transactions et sélectionnez Modifier.
Sous Personnaliser votre instance, développez la section Protection des données.
Dans la section Activer la récupération à un moment précis, développez Options avancées.
Indiquez le nombre de jours de conservation des journaux, compris entre 1 et 35 pour l'édition Cloud SQL Enterprise Plus, ou entre 1 et 7 pour l'édition Cloud SQL Enterprise.
Cliquez sur Enregistrer.

gcloud

Modifiez l'instance pour définir le nombre de jours de conservation des journaux binaires.

Remplacez les éléments suivants :

INSTANCE-NAME : nom de l'instance sur laquelle vous souhaitez définir les journaux de transactions.
DAYS-TO-RETAIN : nombre de jours de journaux de transactions à conserver. Pour l'édition Cloud SQL Enterprise Plus, la plage valide est comprise entre 1 et 35 jours, avec une valeur par défaut de 14 jours. Pour l'édition Cloud SQL Enterprise, la plage valide est comprise entre 1 et 7 jours, avec une valeur par défaut de 7 jours. Si aucune valeur n'est spécifiée, la valeur par défaut est utilisée. Valable uniquement si la récupération PITR est activée. Conserver davantage de jours de journaux de transactions nécessite une capacité de stockage plus importante.

  gcloud sql instances patch INSTANCE-NAME \
    --retained-transaction-log-days=DAYS-TO-RETAIN

REST v1

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

days-to-retain : nombre de jours pendant lesquels les journaux de transactions sont conservés (entre 1 et 7)
project-id : ID du projet
instance-id : ID de l'instance.

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

days-to-retain : nombre de jours pendant lesquels les journaux de transactions sont conservés (entre 1 et 7)
project-id : ID du projet
instance-id : ID de l'instance.

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

Corps JSON de la requête :

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Effectuer une récupération PITR à l'aide des positions dans les journaux binaires

Bien que nous vous recommandions d'effectuer une récupération PITR à l'aide d'horodatages, comme décrit dans la section Effectuer une récupération PITR à l'aide d'un horodatage, vous pouvez également effectuer une récupération PITR en indiquant une position spécifique dans un journal binaire.

Pour en savoir plus sur la récupération PITR à l'aide des positions dans les journaux binaires, consultez la section Récupération PITR à l'aide du journal binaire.

Avant de commencer

Avant d'effectuer cette tâche, vous devez disposer des éléments suivants :

Journalisation binaire et sauvegardes de l'instance activées, avec journalisation binaire continue depuis la dernière sauvegarde précédant l'événement à partir duquel vous souhaitez effectuer la récupération Pour en savoir plus, consultez la section Activer la journalisation binaire.
Les journaux binaires doivent être disponibles sur le disque pour que vous puissiez les parcourir pour rechercher des événements. Pour vérifier la durée de conservation de vos journaux binaires sur le disque, consultez la section Durée de conservation des journaux. Vous ne pouvez pas parcourir les journaux binaires stockés dans Cloud Storage avec l'utilitaire mysqlbinlog.
Nom du fichier journal binaire et position de l'événement à partir duquel vous souhaitez effectuer la récupération (cet événement et tous ceux qui ont eu lieu après ne seront pas répercutés sur la nouvelle instance) Pour en savoir plus, consultez la section Identifier la position dans le journal binaire.

Après avoir identifié le nom de fichier du journal binaire et la position, effectuez la récupération PITR à l'aide des positions d'événements dans les journaux binaires.

Identifier la position de récupération

Utilisez le client MySQL pour vous connecter à l'instance que vous souhaitez restaurer.

Pour ce faire, utilisez Cloud Shell ou votre ordinateur client local. Pour en savoir plus, consultez la page Options de connexion pour les applications externes.
Affichez les fichiers journaux binaires de l'instance :
```
SHOW BINARY LOGS;
```
Affichez les 100 premiers événements dans le fichier journal binaire le plus récent :
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
```
Vous pouvez ajuster le nombre de lignes à afficher, mais vous ne devez pas afficher tous les événements du fichier tant que vous ne connaissez pas la taille du fichier. L'affichage d'un grand nombre d'événements peut affecter les performances du système.
Si l'événement que vous recherchez n'est pas affiché, utilisez la dernière position affichée comme point de départ pour rechercher la série d'événements suivante :
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
```
Une fois que vous avez trouvé l'événement qui marque le moment jusqu'auquel vous souhaitez restaurer, enregistrez la position (affichée dans la colonne Pos) et le nom du fichier journal binaire.

Le nom du fichier journal binaire et la position vont vous permettre d'effectuer la récupération PITR.

Voici un exemple de résultat de la commande SHOW BINLOG EVENTS :

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

Dans cet exemple, vous utiliseriez la position "865" et le nom "mysql-bin.000011" comme position de récupération afin d'effectuer une restauration jusqu'à l'instruction DROP TABLE, en gras ci-dessus. L'instruction DROP TABLE et toutes les opérations après celle-ci ne sont pas répercutées dans la nouvelle instance.

Effectuer une récupération PITR à l'aide des positions d'événements dans les journaux binaires

gcloud

Exécutez la commande gcloud sql instances clone avec les options --bin-log-file-name et --bin-log-position.

Créez la nouvelle instance en utilisant le nom du fichier journal binaire et la position de récupération.

Remplacez les éléments suivants :
- SOURCE_INSTANCE_NAME : nom de l'instance à partir de laquelle vous effectuez la restauration.
- NEW_INSTANCE_NAME : nom du clone.
- BINLOG_FILE_NAME : nom du journal binaire, par exemple mysql-bin.187288.
- POSITION : position dans le journal binaire jusqu'à laquelle restaurer, par exemple 50001356.
```
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION
```
Par exemple, une commande gcloud sql instances clone peut ressembler à ce qui suit :
```
gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
```
Utilisez l'ID d'opération renvoyé par la commande clone pour vérifier l'état de l'opération de restauration.
```
gcloud sql operations describe OPERATION_ID
```
Pendant l'opération en cours, un état RUNNING est renvoyé. Une fois l'opération terminée, un état DONE est renvoyé.

REST v1

Créez la nouvelle instance en utilisant le nom du fichier journal binaire et la position de récupération que vous avez identifiés :

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

project-id : ID du projet
target-instance-id : ID de l'instance cible
source-instance-id : ID de l'instance source
binary-log-file-name : nom du fichier journal binaire
binary-log-position : position dans le fichier journal binaire

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Corps JSON de la requête :

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

Créez la nouvelle instance en utilisant le nom du fichier journal binaire et la position de récupération que vous avez identifiés :

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

project-id : ID du projet
target-instance-id : ID de l'instance cible
source-instance-id : ID de l'instance source
binary-log-file-name : nom du fichier journal binaire
binary-log-position : position dans le fichier journal binaire

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Corps JSON de la requête :

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Vous devriez recevoir une réponse JSON de ce type :

Réponse

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Résoudre les problèmes

Problème Dépannage

Problème	Dépannage
`argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z` OU `Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,`	L'horodatage que vous avez fourni n'est pas valide.
`HTTP Error 400: Successful backup required for carrying out the operation was not found.` OU `Successful backup required for carrying out the operation was not found. or Time where no backups can be found.`	L'horodatage que vous avez fourni correspond à un moment où les sauvegardes ou les coordonnées du journal binaire sont introuvables.

argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z

Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,

L'horodatage que vous avez fourni n'est pas valide.

HTTP Error 400: Successful backup required for carrying out the operation was not found.

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

L'horodatage que vous avez fourni correspond à un moment où les sauvegardes ou les coordonnées du journal binaire sont introuvables.

Étapes suivantes

Configurez des options sur votre clone.