Restaurer des bases de données SQL sur une machine virtuelle Azure à l’aide d’Azure CLI
Azure CLI permet de créer et de gérer des ressources Azure à partir de la ligne de commande ou par le biais de scripts. Cet article explique comment restaurer une base de données SQL sauvegardée sur une machine virtuelle Azure à l’aide d’Azure CLI. Vous pouvez également effectuer ces actions à l’aide du portail Azure.
Utilisez Azure Cloud Shell pour exécuter les commandes CLI.
Cet article part du principe que vous avez une base de données SQL en cours d’exécution sur une machine virtuelle Azure qui est sauvegardée à l’aide de Sauvegarde Azure. Si vous avez appliqué la procédure de l’article Sauvegarder une base de données SQL dans Azure à l’aide de l’interface CLI pour sauvegarder votre base de données SQL, vous utiliserez les ressources suivantes :
- Un groupe de ressources nommé
SQLResourceGroup. - Un coffre nommé
SQLVault. - Conteneur protégé nommé
VMAppContainer;Compute;SQLResourceGroup;testSQLVM. - Élément/base de données sauvegardé nommé
sqldatabase;mssqlserver;master. - Ressources dans la région
westus.
Notes
Reportez-vous à la matrice de prise en charge des sauvegardes SQL pour en savoir plus sur les configurations et les scénarios pris en charge.
Afficher les points de restauration d’une base de données sauvegardée
Pour afficher la liste de tous les points de récupération d’une base de données, utilisez la commande az backup recoverypoint list comme suit :
az backup recoverypoint list --resource-group SQLResourceGroup \
--vault-name SQLVault \
--container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
--item-name sqldatabase;mssqlserver;master \
--output table
La liste des points de récupération apparaît comme suit :
Name Time BackupManagementType Item Name RecoveryPointType
------------------- --------------------------------- --------------------- ---------------------- ------------------
7660777527047692711 2019-12-10T04:00:32.346000+00:00 AzureWorkload sqldatabase;mssqlserver;master Full
7896624824685666836 2019-12-15T10:33:32.346000+00:00 AzureWorkload sqldatabase;mssqlserver;master Differential
DefaultRangeRecoveryPoint AzureWorkload sqldatabase;mssqlserver;master Log
La liste ci-dessus contient trois points de récupération : un pour la sauvegarde complète, un pour la sauvegarde différentielle et un pour la sauvegarde des journaux.
Notes
Vous pouvez également afficher les points de début et de fin de chaque chaîne de sauvegarde de journaux non interrompue à l’aide de la commande az backup recoverypoint show-log-chain.
Prérequis pour restaurer une base de données
Avant de restaurer une base de données, vérifiez que les prérequis suivants sont remplis :
- Vous pouvez restaurer la base de données uniquement sur une instance SQL qui se trouve dans la même région.
- L’instance cible doit être inscrite auprès du même coffre que la source.
Restaurer une base de données
Sauvegarde Azure peut restaurer des bases de données SQL s’exécutant sur des machines virtuelles Azure comme suit :
- Restaurer à une date ou une heure spécifique (à la seconde), en utilisant les sauvegardes de fichiers journaux. Sauvegarde Azure détermine automatiquement les sauvegardes différentielles complètes appropriées, et la chaîne des sauvegardes de fichiers journaux nécessaires pour restaurer en fonction de la date/heure sélectionnée.
- Restaurer en fonction d’une sauvegarde complète ou différentielle spécifique à un point de récupération spécifique.
Pour restaurer une base de données, utilisez la commande az restore restore-azurewl, qui nécessite entre autres un objet de configuration de récupération comme entrée. Vous pouvez générer cet objet à l’aide de la commande az backup recoveryconfig show. L’objet de configuration de récupération contient tous les détails nécessaires pour effectuer une restauration, notamment le mode de restauration : OriginalWorkloadRestore ou AlternateWorkloadRestore.
Notes
OriginalWorkloadRestore : restaure les données sur la même instance SQL que la source d’origine. Cette option remplace la base de données d’origine. AlternateWorkloadRestore : restaure la base de données vers un autre emplacement et conserve la base de données source d’origine.
Restaurer à un autre emplacement
Pour restaurer une base de données à un autre emplacement, utilisez AlternateWorkloadRestore comme mode de restauration. Vous devez ensuite choisir le point de restauration, qui peut être un point antérieur dans le temps ou l’un des points de restauration précédents.
Nous allons procéder à la restauration vers un point de restauration précédent. Affichez la liste des points de restauration pour la base de données et choisissez celui vers lequel vous souhaitez effectuer la restauration. Ici, utilisons le point de restauration avec le nom 7660777527047692711.
Avec le nom du point de restauration et du mode de restauration ci-dessus, créons l’objet de configuration de récupération avec la commande az backup recoveryconfig show. Vérifiez les paramètres restants dans cette commande :
- --target-item-name : nom à utiliser par la base de données restaurée. Dans ce scénario, nous avons utilisé le nom restored_database.
- --target-server-name : il s’agit du nom d’un serveur SQL qui est correctement inscrit auprès d’un coffre Recovery Services et se trouve dans la même région que la base de données à restaurer. Ici, vous restaurez la base de données sur le même serveur SQL que celui que vous avez protégé, nommé testSQLVM.
- --target-server-type : pour la restauration des bases de données SQL, vous devez utiliser SQLInstance.
az backup recoveryconfig show --resource-group SQLResourceGroup \
--vault-name SQLVault \
--container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
--item-name SQLDataBase;mssqlserver;master \
--restore-mode AlternateWorkloadRestore \
--rp-name 7660777527047692711 \
--target-item-name restored_database \
--target-server-name testSQLVM \
--target-server-type SQLInstance \
--workload-type SQLDataBase \
--output json
La réponse à la requête ci-dessus est un objet de configuration de récupération qui se présente comme suit :
{
"container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;SQLResourceGroup;testSQLVM",
"container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
"database_name": "MSSQLSERVER/restored_database",
"filepath": null,
"item_type": "SQL",
"item_uri": "SQLDataBase;mssqlserver;master",
"log_point_in_time": null,
"recovery_mode": null,
"recovery_point_id": "7660777527047692711",
"restore_mode": "AlternateLocation",
"source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
"workload_type": "SQLDataBase",
"alternate_directory_paths": []
}
À présent, pour restaurer la base de données, exécutez la commande az restore restore-azurewl. Pour utiliser cette commande, nous allons entrer la sortie JSON ci-dessus enregistrée dans un fichier nommé recoveryconfig.json.
az backup restore restore-azurewl --resource-group SQLResourceGroup \
--vault-name SQLVault \
--recovery-config recoveryconfig.json \
--output table
La sortie se présente comme suit :
Name Operation Status Item Name Backup Management Type Start Time UTC Duration
------------------------------------ ----------- ---------- --------------------------------- ------------------------ -------------------------------- --------------
be7ea4a4-0752-4763-8570-a306b0a0106f Restore InProgress master [testSQLVM] AzureWorkload 2022-06-21T03:51:06.898981+00:00 0:00:05.652967
La réponse vous fournit le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de la commande az backup job show.
Restaurer et remplacer
Pour restaurer à l’emplacement d’origine, nous allons utiliser OriginalWorkloadRestore comme mode de restauration. Vous devez ensuite choisir le point de restauration, qui peut être un point antérieur dans le temps ou l’un des points de restauration précédents.
À titre d’exemple, choisissons le point dans le temps précédent « 28-11-2019-09:53:00 » pour le restaurer. Vous pouvez spécifier ce point de restauration aux formats suivants : jj-mm-aaaa, jj-mm-aaaa-hh:mm:ss. Pour choisir un point dans le temps valide pour la restauration, utilisez la commande az backup recoverypoint show-log-chain, qui liste les intervalles de sauvegardes de chaîne de journaux non interrompues.
az backup recoveryconfig show --resource-group SQLResourceGroup \
--vault-name SQLVault \
--container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
--item-name sqldatabase;mssqlserver;master \
--restore-mode OriginalWorkloadRestore \
--log-point-in-time 20-06-2022-09:02:41 \
--output json
La réponse à la requête ci-dessus est un objet de configuration de récupération qui se présente comme suit :
{
"alternate_directory_paths": null,
"container_id": null,
"container_uri": "VMAppContainer;compute;petronasinternaltest;sqlserver-11",
"database_name": null,
"filepath": null,
"item_type": "SQL",
"item_uri": "SQLDataBase;mssqlserver;msdb",
"log_point_in_time": "20-06-2022-09:02:41",
"recovery_mode": null,
"recovery_point_id": "DefaultRangeRecoveryPoint",
"restore_mode": "OriginalLocation",
"source_resource_id": "/subscriptions/62b829ee-7936-40c9-a1c9-47a93f9f3965/resourceGroups/petronasinternaltest/providers/Microsoft.Compute/virtualMachines/sqlserver-11",
"workload_type": "SQLDataBase"
}
À présent, pour restaurer la base de données, exécutez la commande az restore restore-azurewl. Pour utiliser cette commande, nous allons entrer la sortie JSON ci-dessus enregistrée dans un fichier nommé recoveryconfig.json.
az backup restore restore-azurewl --resource-group sqlResourceGroup \
--vault-name sqlVault \
--recovery-config recoveryconfig.json \
--output table
La sortie se présente comme suit :
Name Operation Status Item Name Backup Management Type Start Time UTC Duration
------------------------------------ ----------- ---------- ------------------------------- ------------------------ -------------------------------- --------------
1730ec49-166a-4bfd-99d5-93027c2d8480 Restore InProgress master [testSQLVM] AzureWorkload 2022-06-21T04:04:11.161411+00:00 0:00:03.118076
La réponse vous fournit le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de la commande az backup job show.
Restaurer dans une région secondaire
Pour restaurer une base de données dans la région secondaire, spécifiez un coffre cible et un serveur situés dans la région secondaire, dans la configuration de restauration.
az backup recoveryconfig show --resource-group SQLResourceGroup \
--vault-name SQLVault \
--container-name VMAppContainer;compute;SQLResourceGroup;testSQLVM \
--item-name sqldatabase;mssqlserver;master \
--restore-mode AlternateWorkloadRestore \
--from-full-rp-name 293170069256531 \
--rp-name 293170069256531 \
--target-server-name targetSQLServer \
--target-container-name VMAppContainer;compute;SQLResourceGroup;targetSQLServer \
--target-item-name testdb_restore_1 \
--target-server-type SQLInstance \
--workload-type SQLDataBase \
--target-resource-group SQLResourceGroup \
--target-vault-name targetVault \
--backup-management-type AzureWorkload
La réponse est un objet de configuration de récupération qui apparaît comme suit :
{
"container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/targetVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;SQLResourceGroup;targetSQLServer",
"container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
"database_name": "MSSQLSERVER/sqldatabase;mssqlserver;testdb_restore_1",
"filepath": null,
"item_type": "SQL",
"item_uri": "SQLDataBase;mssqlserver;master",
"log_point_in_time": null,
"recovery_mode": null,
"recovery_point_id": "932606668166874635",
"restore_mode": "AlternateLocation",
"source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
"workload_type": "SQLDataBase",
"alternate_directory_paths": [],
}
Utilisez cette configuration de récupération dans la commande az restore restore-azurewl. Sélectionnez l’indicateur --use-secondary-region pour restaurer la base de données dans la région secondaire.
az backup restore restore-azurewl --resource-group SQLResourceGroup \
--vault-name testSQLVault \
--recovery-config recoveryconfig.json \
--use-secondary-region \
--output table
La sortie se présente comme suit :
Name Operation Status Item Name Backup Management Type Start Time UTC Duration
------------------------------------ ------------------ ---------- ------------------------- ------------------------ -------------------------------- --------------
0d863259-b0fb-4935-8736-802c6667200b CrossRegionRestore InProgress master [testSQLVM] AzureWorkload 2022-06-21T08:29:24.919138+00:00 0:00:12.372421
Notes
L’objectif RPO (objectif de point de récupération) pour que les données de sauvegarde soient disponibles dans la région secondaire est de 12 heures. Ainsi, quand vous activez la restauration CRR (restauration interrégionale), l’objectif RPO de la région secondaire est de 12 heures + la durée de la fréquence de journalisation (qui peut être définie à une valeur minimale de 15 minutes).
Restaurer sous forme de fichiers
Pour restaurer les données de sauvegarde sous forme de fichiers plutôt que sous forme de base de données, nous allons utiliser RestoreAsFiles comme mode de restauration. Choisissez ensuite le point de restauration, qui peut être un point antérieur dans le temps ou l’un des points de restauration précédents. Une fois les fichiers vidés dans un chemin d’accès spécifié, vous pouvez placer ces fichiers sur n’importe quelle machine SQL sur laquelle vous souhaitez les restaurer sous forme de base de données. Étant donné que vous pouvez déplacer ces fichiers sur n’importe quel ordinateur, vous pouvez désormais restaurer les données entre les abonnements et les régions.
Ici, choisissez le point dans le temps précédent 28-11-2019-09:53:00 à restaurer et l’emplacement où déposer les fichiers de sauvegarde comme /home/sql/restoreasfiles sur le même serveur SQL. Vous pouvez spécifier ce point de restauration dans l’un des formats suivants : jj-mm-aaaa ou jj-mm-aaaa-hh:mm:ss. Pour choisir un point dans le temps valide pour la restauration, utilisez la commande az backup recoverypoint show-log-chain, qui liste les intervalles de sauvegardes de chaîne de journaux non interrompues.
Avec le nom du point de restauration et du mode de restauration ci-dessus, créons l’objet de configuration de récupération avec la commande az backup recoveryconfig show. Vérifiez chacun des paramètres restants dans cette commande :
- --target-container-name : il s’agit du nom d’un serveur SQL qui est correctement inscrit auprès d’un coffre Recovery Services et se trouve dans la même région que la base de données à restaurer. Restaurons la base de données sous forme de fichiers sur le même serveur SQL que vous avez protégé, nommé hxehost.
- --rp-name : pour une limite de restauration dans le temps, le nom du point de restauration est DefaultRangeRecoveryPoint.
az backup recoveryconfig show --resource-group SQLResourceGroup \
--vault-name SQLVault \
--container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
--item-name sqldatabase;mssqlserver;master \
--restore-mode RestoreAsFiles \
--rp-name 932606668166874635 \
--target-container-name VMAppContainer;Compute;SQLResourceGroup;testSQLVM \
--filepath /sql/restoreasfiles \
--output json
La réponse à la requête ci-dessus est un objet de configuration de récupération qui se présente comme suit :
{
"alternate_directory_paths": null,
"container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupFabrics/Azure/protectionContainers/VMAppContainer;Compute;SQLResourceGroup;testSQLVM",
"container_uri": "VMAppContainer;compute;SQLResourceGroup;testSQLVM",
"database_name": null,
"filepath": "/sql/restoreasfiles",
"item_type": "SQL",
"item_uri": "SQLDataBase;mssqlserver;master",
"log_point_in_time": null,
"recovery_mode": "FileRecovery",
"recovery_point_id": "932606668166874635",
"restore_mode": "AlternateLocation",
"source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.Compute/virtualMachines/testSQLVM",
"workload_type": "SQLDataBase"
}
À présent, pour restaurer la base de données sous forme de fichiers, exécutez la commande az restore restore-azurewl. Pour utiliser cette commande, nous allons entrer la sortie JSON ci-dessus enregistrée dans un fichier nommé recoveryconfig.json.
az backup restore restore-azurewl --resource-group SQLResourceGroup \
--vault-name SQLVault \
--restore-config recoveryconfig.json \
--output json
La sortie se présente comme suit :
{
"eTag": null,
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SQLResourceGroup/providers/Microsoft.RecoveryServices/vaults/SQLVault/backupJobs/e9cd9e73-e3a3-425a-86a9-8dd1c500ff56",
"location": null,
"name": "e9cd9e73-e3a3-425a-86a9-8dd1c500ff56",
"properties": {
"actionsInfo": [
"1"
],
"activityId": "9e7c8ee4-f1ef-11ec-8a2c-3c52826c1a9a",
"backupManagementType": "AzureWorkload",
"duration": "0:00:04.304322",
"endTime": null,
"entityFriendlyName": "master [testSQLVM]",
"errorDetails": > [!NOTE]
> Information the user should notice even if skimmingnull,
"extendedInfo": {
"dynamicErrorMessage": null,
"propertyBag": {
"Job Type": "Restore as files"
},
"tasksList": [
{
"status": "InProgress",
"taskId": "Transfer data from vault"
}
]
},
"isUserTriggered": true,
"jobType": "AzureWorkloadJob",
"operation": "Restore",
"startTime": "2022-06-22T05:53:32.951666+00:00",
"status": "InProgress",
"workloadType": "SQLDataBase"
},
"resourceGroup": "SQLResourceGroup",
"tags": null,
"type": "Microsoft.RecoveryServices/vaults/backupJobs"
}
La réponse vous fournit le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de la commande az backup job show.
Notes
Si vous ne souhaitez pas restaurer toute la chaîne, mais uniquement un sous-ensemble de fichiers, suivez les étapes décrites ici.
Restauration avec plusieurs abonnements
Grâce à la restauration avec plusieurs abonnements (CSR), vous avez la possibilité de restaurer n’importe quel abonnement et tout coffre sous votre tenant (locataire) si des autorisations de restauration sont disponibles. Par défaut, une CSR est activée sur tous les coffres Recovery Services (coffres existants et nouvellement créés).
Notes
- Vous pouvez déclencher la restauration avec plusieurs abonnements à partir d’un coffre Recovery Services.
- La CSR est prise en charge uniquement pour des sauvegardes basées sur une diffusion en continu et n’est pas prise en charge pour des sauvegardes basées sur des instantanés.
- La restauration inter-région (CRR) avec CSR n’est pas prise en charge.
az backup vault create
Ajoutez le paramètre cross-subscription-restore-state qui vous permet de définir l’état CSR du coffre lors de la création et de la mise à jour du coffre.
az backup recoveryconfig show
Ajoutez le paramètre --target-subscription-id qui vous permet de fournir l’abonnement cible en tant qu’entrée lors du déclenchement de la restauration avec plusieurs abonnements pour des sources de données SQL ou HANA.
Exemple :
az backup vault create -g {rg_name} -n {vault_name} -l {location} --cross-subscription-restore-state Disable
az backup recoveryconfig show --restore-mode alternateworkloadrestore --backup-management-type azureworkload -r {rp} --target-container-name {target_container} --target-item-name {target_item} --target-resource-group {target_rg} --target-server-name {target_server} --target-server-type SQLInstance --target-subscription-id {target_subscription} --target-vault-name {target_vault} --workload-type SQLDataBase --ids {source_item_id}