Migrer un compte Azure Cosmos DB du mode de sauvegarde périodique vers le mode de sauvegarde continue

Article
08/15/2024

S’APPLIQUE À : NoSQL MongoDB Gremlin Table

Les comptes Azure CosmosDB avec une stratégie de sauvegarde en mode périodique peuvent être migrés vers le mode continu à l’aide du portail Azure, de l’interface CLI, de PowerShell ou des modèles Resource Manager. La migration du mode périodique vers le mode continu est une migration unidirectionnelle et n’est pas réversible. Après la migration du mode périodique vers le mode continu, vous pouvez profiter des avantages du mode continu.

Voici les principales raisons de migrer en mode continu :

La possibilité d’effectuer une restauration libre-service à l’aide du portail Azure, de l’interface CLI ou de PowerShell.
La possibilité de restaurer avec une précision temporelle d’une seconde pour la dernière fenêtre de 30 jours ou de 7 jours.
La possibilité de s’assurer que la sauvegarde est cohérente entre les plages clés d’étendues ou de partitions au cours d’une période.
La possibilité de restaurer le conteneur, la base de données ou le compte complet lorsqu’il est supprimé ou modifié.
La possibilité de choisir les événements sur le conteneur, la base de données ou le compte et de décider quand initier la restauration.

Notes

La fonctionnalité de migration est unidirectionnelle uniquement et il s’agit d’une action irréversible. Cela signifie qu’une fois que vous avez effectué la migration du mode périodique vers le mode continu, vous ne pouvez pas revenir au mode périodique.

Vous pouvez migrer un compte en mode de sauvegarde continue uniquement si les conditions suivantes sont remplies. Vérifiez également les limites de restauration dans le temps avant la migration de votre compte :

Si le type de compte est API pour NoSQL, API pour Table, Gremlin ou API pour MongoDB.
Si le compte a une seule région d’écriture.
Si le compte n’avait jamais désactivé Synapse Link pour un conteneur.

Si le compte utilise des clés gérées par le client, une identité managée (affectée par l’utilisateur ou par le système) doit être déclarée dans la stratégie d’accès Key Vault et doit être définie en tant qu’identité par défaut sur le compte.

Autorisations

Pour effectuer la migration, vous avez besoin d’autorisation Microsoft.DocumentDB/databaseAccounts/write pour le compte en cours de migration.

Tarification après la migration

Après la migration de votre compte en mode de sauvegarde continue, le coût peut changer par rapport au mode de sauvegarde périodique. Le choix du niveau 30 jours par rapport au niveau 7 jours aura également une influence sur le coût de la sauvegarde. Pour en savoir plus, consultez Tarification du mode de sauvegarde continue.

Migrer à l’aide du portail

Procédez comme suit pour migrer votre compte de la sauvegarde périodique vers le mode de sauvegarde continue :

Connectez-vous au portail Azure.
Accédez à votre compte Azure Cosmos DB et ouvrez le volet Sauvegarder et restaurer. Sélectionnez l’onglet Stratégies de sauvegarde, puis sélectionnez modifier. Une fois que vous avez choisi le mode continu cible, sélectionnez Enregistrer.
Lorsque la migration est en cours, la fenêtre contextuelle affiche Mise à jour des paramètres de stratégie de sauvegarde. Si vous sélectionnez cette notification, vous pouvez voir Mise à jour au niveau du compte et Migration pour la stratégie de sauvegarde sur la vue d’ensemble du compte. Une fois l’opération terminée, la stratégie de sauvegarde bascule vers le niveau choisi du mode continu. Le moment de la migration dépend de la taille des données de votre compte.

Migrer à l’aide de PowerShell

Installez la dernière version d’Azure PowerShell ou une version supérieure à 6.2.0.
Pour utiliser le mode Continous7Days pour le provisionnement ou la migration, vous devez utiliser la préversion de l’extension cosmosdb. Utilisez Install-Module -Name Az.CosmosDB -AllowPrerelease.

Ensuite, effectuez les étapes suivantes :

Connectez-vous à votre compte Azure :
```
Connect-AzAccount
```

Migrez votre compte du mode de sauvegarde périodique vers le mode continu avec le niveau continuous30days ou continuous7days. Si la valeur du niveau n’est spécifiée, elle est supposée être continuous30days :

Update-AzCosmosDBAccount ` 
   -ResourceGroupName "myrg" ` 
   -Name "myAccount" `
   -BackupPolicyType "Continuous"

   Update-AzCosmosDBAccount ` 
   -ResourceGroupName "myrg" ` 
   -Name "myAccount" `
   -BackupPolicyType "Continuous" `
   -ContinuousTier "Continuous7Days"

Migrer en utilisant l’interface CLI

Installez la dernière version d’Azure CLI :

Si Azure CLI n’est pas déjà installé, consultez Installer Azure CLI. Vous pouvez aussi utiliser Azure Cloud Shell depuis le portail Azure.

Connectez-vous à votre compte Azure et exécutez la commande suivante pour migrer votre compte en mode continu :
```
az login
```

Migrez le compte vers le niveau continuous30days ou continuous7days. Si la valeur du niveau n’est spécifiée, elle est supposée être continuous30days :

az cosmosdb update -n <myaccount> -g <myresourcegroup> --backup-policy-type continuous

az cosmosdb update -g "my-rg" -n "my-continuous-backup-account" --backup-policy-type "Continuous" --continuous-tier "Continuous7Days"

Une fois la migration terminée, la sortie montre l’objet backupPolicy, qui inclut la propriété type avec la valeur Continuous.

 {
   "apiProperties": null,
   "backupPolicy": {
        "continuousModeProperties": {
                "tier": "Continuous7Days"
        },
        "migrationState": null,
        "type": "Continuous"
   },
      …
 }

Vérifier l’état de la migration

Exécutez la commande suivante et vérifiez les propriétés status et targetType de l’objet backupPolicy. L’état indique in-progress après le démarrage de la migration :

az cosmosdb show -n "myAccount" -g "myrg"

Une fois la migration terminée, le type de sauvegarde passe à Continue et montre le niveau choisi. Si le niveau n’a pas été spécifié, il est défini sur Continuous30Days. Exécutez à nouveau la même commande pour vérifier l’état :

az cosmosdb show -n "myAccount" -g "myrg"

Migrer du mode périodique au mode continu en utilisant un modèle Resource Manager

Pour migrer vers le mode de sauvegarde continue à l’aide d’un modèle ARM, recherchez la section backupPolicy de votre modèle et mettez à jour la propriété type. Par exemple, si votre modèle existant possède une stratégie de sauvegarde telle que l’objet JSON suivant :

"backupPolicy": {
   "type": "Periodic",
   "periodicModeProperties": {
   "backupIntervalInMinutes": 240,
   "backupRetentionIntervalInHours": 8
   }
}

Remplacez-la par l’objet JSON suivant :

"backupPolicy": { 
   "type": "Continuous", 
   "continuousModeProperties": { 
      "tier": "Continuous7Days" 
    } 
}

Ensuite, déployez le modèle à l’aide d’Azure PowerShell ou de l’interface CLI. L’exemple suivant montre comment déployer le modèle avec une commande CLI :

az deployment group create -g <ResourceGroup> --template-file <ProvisionTemplateFilePath>

Changer les niveaux du mode continu

Vous pouvez basculer entre Continuous30Days et Continous7Days dans Azure PowerShell, Azure CLI ou le portail Azure.

Dans le portail du compte Azure Cosmos DB donné, choisissez le volet Restauration jusqu’à une date et heure, sélectionnez le lien de modification en regard du mode de stratégie de sauvegarde pour afficher l’option Continu (30 jours) ou Continu (7 jours). Choisissez la cible requise, puis sélectionnez Enregistrer.

La commande Azure CLI suivante montre le basculement d’un compte existant vers Continous7Days :

az cosmosdb update \ 
    --resource-group "my-rg" \ 
    --name "my-continuous-backup-account" \ 
    --backup-policy-type "Continuous" \ 
    --continuous-tier "Continuous7Days"

La commande Azure PowerShell suivante montre le basculement d’un compte existant vers Continous7Days :

Update-AzCosmosDBAccount ` 
    -ResourceGroupName "myrg" ` 
    -Name "myAccount" `
    -BackupPolicyType Continuous `
    -ContinuousTier Continuous7Days

Vous pouvez aussi utiliser un modèle ARM dans une méthode similaire à l’utilisation d’Azure CLI et d’Azure PowerShell.

Notes

Quand vous passez du niveau 30 jours à 7 jours, la possibilité de restaurer plus de 7 jours dans l’historique est immédiatement non disponible. Quand vous passez du niveau 7 jours à 30 jours, vous ne pourrez pas restaurer plus de 7 jours immédiatement. Le point de restauration le plus ancien dans le temps peut être extrait des métadonnées du compte disponibles via Azure PowerShell ou Azure CLI. L’impact sur le prix de la bascule entre les niveaux 7 jours et 30 jours sera aussi immédiatement visible.

Que se passe-t-il pendant et après la migration ?

Lors de la migration du mode périodique en mode continu, vous ne pouvez pas exécuter les opérations du plan de contrôle qui effectuent des mises à jour ou des suppressions au niveau du compte. Par exemple, les opérations telles que l’ajout ou la suppression de régions, le basculement de compte, la mise à jour de la stratégie de sauvegarde, etc., ne peuvent pas être exécutées pendant la migration. Le temps de la migration dépend de la taille des données et du nombre de régions de votre compte. L’action de restauration sur les comptes migrés ne réussit qu’à partir du moment où la migration se termine correctement.

Vous pouvez restaurer votre compte une fois la migration terminée. Si la migration se termine à 13 h 00 PST, vous pouvez effectuer une restauration dans le temps à partir de 13 h 00 PST.

Forum aux questions

La migration se produit-elle uniquement au niveau du compte ?

Oui.

Quels comptes peuvent être ciblés pour la migration de sauvegarde ?

Actuellement, les comptes pour l’API pour NoSQL, l’API pour Table, Gremlin et l’API pour MongoDB, avec une région d’écriture unique, qui ont partagé, provisionné ou provisionné par mise à l’échelle automatique une migration de prise en charge de débit.

Les comptes activés avec plusieurs régions d’écriture ne sont pas pris en charge pour la migration.

Actuellement, les comptes avec Synapse Link activés, dont Synapse Link a été désactivé pour une ou plusieurs collections, ne peuvent pas migrer vers une sauvegarde continue.

La migration prend-elle du temps ? Quelle est la durée habituelle ?

La durée de la migration dépend largement de la taille des données et du nombre de régions de votre compte. Vous pouvez obtenir l’état de la migration à l’aide d’Azure CLI ou de commandes PowerShell. Pour les comptes volumineux avec des dizaines de téraoctets de données, la migration peut prendre jusqu’à quelques jours.

La migration entraîne-t-elle un impact sur la disponibilité ou un temps d’arrêt ?

Non, l’opération de migration a lieu en arrière-plan. Les requêtes des clients ne sont donc pas affectées. Cependant, nous devons effectuer des opérations de back-end pendant la migration, et cela peut prendre un certain temps si le compte est soumis à une charge importante.

Que se passe-t-il si la migration échoue ? Vais-je continuer à effectuer les sauvegardes périodiques ou à récupérer les sauvegardes continues ?

Une fois le processus de migration démarré, le compte passe en mode continu. Si la migration échoue, vous devez initier la migration jusqu’à ce qu’elle réussisse.

Comment faire une restauration à un horodatage avant/pendant/après la migration ?

Supposons que vous avez démarré la migration à t1 et que vous l’avez terminée à t5 : vous ne pouvez pas utiliser un horodatage de restauration entre t1et t5.

Supposons également que votre compte soit maintenant en mode continu. Pour restaurer à une date/heure postérieure à t5, effectuez la restauration en utilisant le portail Azure, l’interface CLI ou PowerShell, comme vous le feriez normalement avec un compte en mode continu. Cette requête de restauration libre-service ne peut être effectuée qu’une fois la migration terminée.

Pour restaurer à une date/heure antérieure à t1, vous pouvez ouvrir un ticket de support comme vous le feriez normalement avec le compte de sauvegarde périodique. Après la migration, vous avez jusqu’à 30 jours pour effectuer la restauration périodique. Pendant ces 30 jours, vous pouvez restaurer en fonction de la rétention/l’intervalle de sauvegarde de votre compte avant la migration. Par exemple, si la sauvegarde a été configurée pour conserver 24 copies à des intervalles de 1 heure, vous pouvez restaurer à n’importe quel point dans le temps entre (t1 – 24 hours) et t1.

Quelles opérations du plan de contrôle au niveau du compte sont bloquées pendant la migration ?

Les opérations comme l’ajout/suppression d’une région, le basculement, la modification de la stratégie de sauvegarde et les changements de débit entraînant un déplacement des données, sont bloquées pendant la migration.

Si la migration échoue pour un problème sous-jacent, est-ce qu’elle bloque toujours l’opération de plan de contrôle jusqu’à ce qu’elle soit retentée et terminée correctement ?

L’échec de la migration ne bloque pas les opérations du plan de contrôle. Si la migration échoue, il est recommandé de réessayer jusqu’à ce qu’elle réussisse avant d’effectuer d’autres opérations de plan de contrôle.

Est-il possible d’annuler la migration ?

Il n’est pas possible d’annuler la migration, car ce n’est pas une opération réversible.

Existe-t-il un outil qui peut aider à estimer la durée de la migration en fonction de l’utilisation des données et du nombre de régions ?

Il n’existe pas d’outil pour estimer le temps. Nos tests et nos mises à l’échelle indiquent qu’un seul compte de région avec 1 To de données prend environ 90 minutes.

Pour les comptes à plusieurs régions, calculez la taille totale des données en tant que Number_of_regions * Data_in_single_region.

Il est recommandé de tester la fonctionnalité de mode de sauvegarde continue pour voir qu’elle fonctionne comme prévu avant de migrer les comptes de production. La migration est une opération unidirectionnelle et elle n’est pas réversible.

Étapes suivantes

Pour en savoir plus sur le mode de sauvegarde continue, consultez les articles suivants :

Présentation du mode de sauvegarde continue avec une limite de restauration dans le temps.
Modèle de ressource du mode de sauvegarde continue.
Restaurez un compte à l’aide du portail Azure, de PowerShell, de l’interface CLI ou d’Azure Resource Manager.

Partager via

Migrer un compte Azure Cosmos DB du mode de sauvegarde périodique vers le mode de sauvegarde continue

Autorisations

Tarification après la migration

Migrer à l’aide du portail

Migrer à l’aide de PowerShell

Migrer en utilisant l’interface CLI

Vérifier l’état de la migration

Migrer du mode périodique au mode continu en utilisant un modèle Resource Manager

Changer les niveaux du mode continu

Que se passe-t-il pendant et après la migration ?

Forum aux questions

La migration se produit-elle uniquement au niveau du compte ?

Quels comptes peuvent être ciblés pour la migration de sauvegarde ?

La migration prend-elle du temps ? Quelle est la durée habituelle ?

La migration entraîne-t-elle un impact sur la disponibilité ou un temps d’arrêt ?

Que se passe-t-il si la migration échoue ? Vais-je continuer à effectuer les sauvegardes périodiques ou à récupérer les sauvegardes continues ?

Comment faire une restauration à un horodatage avant/pendant/après la migration ?

Quelles opérations du plan de contrôle au niveau du compte sont bloquées pendant la migration ?

Si la migration échoue pour un problème sous-jacent, est-ce qu’elle bloque toujours l’opération de plan de contrôle jusqu’à ce qu’elle soit retentée et terminée correctement ?

Est-il possible d’annuler la migration ?

Existe-t-il un outil qui peut aider à estimer la durée de la migration en fonction de l’utilisation des données et du nombre de régions ?

Étapes suivantes

Commentaires

Ressources supplémentaires

Partager via

Migrer un compte Azure Cosmos DB du mode de sauvegarde périodique vers le mode de sauvegarde continue

Autorisations

Tarification après la migration

Migrer à l’aide du portail

Migrer à l’aide de PowerShell

Migrer en utilisant l’interface CLI

Vérifier l’état de la migration

Migrer du mode périodique au mode continu en utilisant un modèle Resource Manager

Changer les niveaux du mode continu

Que se passe-t-il pendant et après la migration ?

Forum aux questions

La migration se produit-elle uniquement au niveau du compte ?

Quels comptes peuvent être ciblés pour la migration de sauvegarde ?

La migration prend-elle du temps ? Quelle est la durée habituelle ?

La migration entraîne-t-elle un impact sur la disponibilité ou un temps d’arrêt ?

Que se passe-t-il si la migration échoue ? Vais-je continuer à effectuer les sauvegardes périodiques ou à récupérer les sauvegardes continues ?

Comment faire une restauration à un horodatage avant/pendant/après la migration ?

Quelles opérations du plan de contrôle au niveau du compte sont bloquées pendant la migration ?

Si la migration échoue pour un problème sous-jacent, est-ce qu’elle bloque toujours l’opération de plan de contrôle jusqu’à ce qu’elle soit retentée et terminée correctement ?

Est-il possible d’annuler la migration ?

Existe-t-il un outil qui peut aider à estimer la durée de la migration en fonction de l’utilisation des données et du nombre de régions ?

Comme le mode de sauvegarde continue est maintenant en disponibilité générale, recommandez-vous quand même de restaurer une copie de votre compte ? Recommandez-vous d’essayer la migration sur la copie avant de décider de migrer le compte de production ?

Étapes suivantes

Commentaires

Ressources supplémentaires