Partager via

Tutoriel : Restaurer des bases de données SAP HANA sur une machine virtuelle Azure à l’aide d’Azure CLI

  • Article

Ce tutoriel explique comment restaurer une instance de base de données SAP HANA et une instance réplication du système SAP HANA (HSR) en utilisant 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. Ce document explique comment restaurer une base de données SAP HANA sauvegardée sur une machine virtuelle Azure à l’aide d’Azure CLI. Vous pouvez également effectuer ces étapes à l’aide du portail Azure.

Notes

  • La récupération d’emplacement d’origine (OLR) n’est actuellement pas prise en charge pour la réplication HSR.
  • La restauration sur l’instance HSR n’est pas prise en charge. Toutefois, la restauration uniquement sur l’instance HANA est prise en charge.

Utilisez Azure Cloud Shell pour exécuter les commandes CLI.

Ce tutoriel part du principe que vous disposez d’une base de données SAP HANA s’exécutant 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 SAP HANA dans Azure à l’aide de l’interface CLI pour sauvegarder votre base de données SAP HANA, vous utiliserez les ressources suivantes :

  • Un groupe de ressources nommé saphanaResourceGroup.
  • Un coffre nommé saphanaVault.
  • Conteneur protégé nommé VMAppContainer;Compute;saphanaResourceGroup;saphanaVM.
  • Élément/base de données sauvegardé nommé saphanadatabase;hxe;hxe.
  • Ressources dans la région westus2.

Si vous souhaitez en savoir plus sur les configurations et les scénarios pris en charge, veuillez consulter la matrice de prise en charge des sauvegardes SAP HANA.

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 l’applet de commande az backup recoverypoint list :

Choisissez un type de base de données :

Pour afficher les points de récupération disponibles, exécutez la commande suivante :

az backup recoverypoint list --resource-group saphanaResourceGroup \
    --vault-name saphanaVault \
    --container-name VMAppContainer;Compute;saphanaResourceGroup;saphanaVM \
    --item-name saphanadatabase;hxe;hxe \
   --output table

La liste des points de récupération se présente comme suit :

Name                      Time                               BackupManagementType   Item Name               RecoveryPointType
-------------------       ---------------------------------  ---------------------  ----------------------  ------------------
7660777527047692711       2019-12-10T04:00:32.346000+00:00   AzureWorkload          SAPHanaDtabase;hxe;hxe  Full
7896624824685666836       2019-12-15T10:33:32.346000+00:00   AzureWorkload          SAPHanaDtabase;hxe;hxe  Differential
DefaultRangeRecoveryPoint                                    AzureWorkload          SAPHanaDtabase;hxe;hxe  Log

Comme vous pouvez le voir, 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 l’applet de 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 SAP HANA qui se trouve dans la même région.
  • L’instance cible doit être inscrite auprès du même coffre que la source ou un autre coffre dans la même région.
  • Sauvegarde Azure ne peut pas identifier deux instances de SAP HANA différentes sur la même machine virtuelle. Ainsi, il est impossible de restaurer des données d’une instance vers une autre sur la même machine virtuelle.

Restaurer une base de données

Sauvegarde Azure peut restaurer des bases de données SAP HANA 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 l’applet de 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 l’applet de 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 de SAP HANA 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.

Dans ce tutoriel, vous allez restaurer à 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. Ce tutoriel utilise le point de restauration nommé 7660777527047692711.

À l’aide du nom du point de restauration et du mode de restauration ci-dessus, nous allons créer l’objet de configuration de récupération avec la cmdlet az backup recoveryconfig show. Examinons ce que signifie chacun des autres paramètres de cette applet de commande :

  • --target-item-name : il s’agit du nom qu’aura la base de données restaurée. Ici, nous avons utilisé le nom restored_database.
  • --target-server-name : il s’agit du nom d’un serveur SAP HANA 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. Dans ce tutoriel, nous allons restaurer la base de données sur le serveur SAP HANA que nous avons protégé, nommé hxehost.
  • --target-server-type : pour la restauration des bases de données SAP HANA, vous devez utiliser HANAInstance.

Choisissez un type de base de données :

Pour démarrer l’opération de restauration, exécutez la commande suivante :


az backup recoveryconfig show --resource-group saphanaResourceGroup \
    --vault-name saphanaVault \
    --container-name VMAppContainer;Compute;saphanaResourceGroup;saphanaVM \
    --item-name saphanadatabase;hxe;hxe \
    --restore-mode AlternateWorkloadRestore \
    --rp-name 7660777527047692711 \
    --target-item-name restored_database \
    --target-server-name hxehost \
    --target-server-type HANAInstance \
    --workload-type SAPHANA \
    --output json

La réponse à la requête ci-dessus est un objet de configuration de récupération qui ressemble à ceci :

{"restore_mode": "AlternateLocation", "container_uri": " VMAppContainer;Compute;saphanaResourceGroup;saphanaVM ", "item_uri": "SAPHanaDatabase;hxe;hxe", "recovery_point_id": "7660777527047692711", "item_type": "SAPHana", "source_resource_id": "/subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/saphanaResourceGroup/providers/Microsoft.Compute/virtualMachines/saphanavm", "database_name": null, "container_id": null, "alternate_directory_paths": null}

À présent, pour restaurer la base de données, exécutez l’applet de 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --restore-config recoveryconfig.json \
    --output table

La sortie se présente ainsi :

Name                                  Resource
------------------------------------  -------
5b198508-9712-43df-844b-977e5dfc30ea  SAPHANA

La réponse vous donnera le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de l’applet de commande az backup job show.

Restaurer et remplacer

Pour restaurer à l’emplacement d’origine, nous allons utiliser OrignialWorkloadRestore 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.

Pour ce tutoriel, nous allons choisir le point dans le temps précédent « 28-11-2019-09:53:00 » pour la restauration. 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 l’applet de 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --container-name VMAppContainer;Compute;saphanaResourceGroup;saphanaVM \
    --item-name saphanadatabase;hxe;hxe \
    --restore-mode OriginalWorkloadRestore \
    --log-point-in-time 28-11-2019-09:53:00 \
    --output json

La réponse à la requête ci-dessus est un objet de configuration de récupération qui ressemble à ceci :

{"restore_mode": "OriginalLocation", "container_uri": " VMAppContainer;Compute;saphanaResourceGroup;saphanaVM ", "item_uri": "SAPHanaDatabase;hxe;hxe", "recovery_point_id": "DefaultRangeRecoveryPoint", "log_point_in_time": "28-11-2019-09:53:00", "item_type": "SAPHana", "source_resource_id": "/subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/saphanaResourceGroup/providers/Microsoft.Compute/virtualMachines/saphanavm", "database_name": null, "container_id": null, "alternate_directory_paths": null}"

À présent, pour restaurer la base de données, exécutez l’applet de 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --restore-config recoveryconfig.json \
    --output table

La sortie se présente ainsi :

Name                                  Resource
------------------------------------  --------
5b198508-9712-43df-844b-977e5dfc30ea  SAPHANA

La réponse vous donnera le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de l’applet de commande az backup job show.

Restaurer dans la 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --container-name VMAppContainer;compute;hanasnapshotcvtmachines;hanasnapcvt01 \
    --item-name SAPHanaDatabase;h10;h10 \
    --restore-mode AlternateWorkloadRestore \
    --from-full-rp-name 293170069256531 \
    --rp-name 293170069256531 \
    --target-server-name targethanaserver \
    --target-container-name VMAppContainer;compute;saphanaTargetRG;targethanaserver \
    --target-item-name h10 \
    --target-server-type HANAInstance \
    --workload-type SAPHANA \
    --target-resource-group saphanaTargetRG \
    --target-vault-name targetVault \
    --backup-management-type AzureWorkload

Voici la réponse à la commande ci-dessus, qui aboutit à la création d’un objet de configuration de récupération :

{
  "alternate_directory_paths": null,
  "container_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/saphanaTargetRG/providers/Microsoft.RecoveryServices/vaults/targetVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;saphanaTargetRG;targethanaserver",
  "container_uri": "VMAppContainer;compute;hanasnapshotcvtmachines;hanasnapcvt01",
  "database_name": "SAPHanaDatabase;h10;h10",
  "filepath": null,
  "item_type": "SAPHana",
  "item_uri": "SAPHanaDatabase;h10;h10",
  "log_point_in_time": null,
  "recovery_mode": null,
  "recovery_point_id": "293170069256531",
  "restore_mode": "AlternateLocation",
  "source_resource_id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/saphanaResourceGroup/providers/Microsoft.Compute/virtualMachines/hanasnapcvt01",
  "workload_type": "SAPHanaDatabase"
}

Utilisez cette configuration de récupération dans l’applet de 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --recovery-config recoveryconfig.json \
    --use-secondary-region \
    --output table

Le résultat sera comme suit :

Name                                  Operation           Status      Item Name            Backup Management Type    Start Time UTC                    Duration
------------------------------------  ------------------  ----------  -------------------  ------------------------  --------------------------------  --------------
00000000-0000-0000-0000-000000000000  CrossRegionRestore  InProgress  H10 [hanasnapcvt01]  AzureWorkload             2021-12-22T05:21:34.165617+00:00  0:00:05.665470

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 sous un chemin d’accès spécifié, vous pouvez placer ces fichiers sur n’importe quel ordinateur SAP HANA sur lequel 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.

Pour ce tutoriel, nous allons choisir le point dans le temps précédent 28-11-2019-09:53:00 vers lequel effectuer la restauration, ainsi que l’emplacement de vidage des fichiers de sauvegarde comme /home/saphana/restoreasfiles sur le même serveur SAP HANA. 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 l’applet de commande az backup recoverypoint show-log-chain, qui liste les intervalles de sauvegardes de chaîne de journaux non interrompues.

À l’aide du nom du point de restauration ci-dessus et du mode de restauration, créons l’objet de configuration de récupération avec l’applet de commande az backup recoveryconfig show. Examinons ce que signifie chacun des autres paramètres de cette applet de commande :

  • --target-container-name : il s’agit du nom d’un serveur SAP HANA qui est correctement inscrit auprès d’un coffre Recovery Services et qui se trouve dans la même région que la base de données à restaurer. Dans ce tutoriel, nous allons restaurer la base de données sous forme de fichiers sur le serveur SAP HANA que nous avons 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 saphanaResourceGroup \
    --vault-name saphanaVault \
    --container-name VMAppContainer;Compute;saphanaResourceGroup;saphanaVM \
    --item-name saphanadatabase;hxe;hxe \
    --restore-mode RestoreAsFiles \
    --log-point-in-time 28-11-2019-09:53:00 \
    --rp-name DefaultRangeRecoveryPoint \
    --target-container-name VMAppContainer;Compute;saphanaResourceGroup;saphanaVM \
    --filepath /home/saphana/restoreasfiles \
    --output json

La réponse à la requête ci-dessus est un objet de configuration de récupération qui ressemble à ceci :

{
  "alternate_directory_paths": null,
  "container_id": "/Subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/saphanaResourceGroup/providers/Microsoft.RecoveryServices/vaults/SAPHANAVault/backupFabrics/Azure/protectionContainers/VMAppContainer;Compute;SAPHANA;hanamachine",
  "container_uri": "VMAppContainer;compute;saphana;hanamachine",
  "database_name": null,
  "filepath": "/home/",
  "item_type": "SAPHana",
  "item_uri": "SAPHanaDatabase;hxe;hxe",
  "log_point_in_time": "04-07-2020-09:53:00",
  "recovery_mode": "FileRecovery",
  "recovery_point_id": "DefaultRangeRecoveryPoint",
  "restore_mode": "AlternateLocation",
  "source_resource_id": "/subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/saphanaResourceGroup/providers/Microsoft.Compute/virtualMachines/hanamachine"
}

À présent, pour restaurer la base de données sous forme de fichiers, exécutez l’applet de commande az restore restore-azurewl. Pour utiliser cette commande, nous allons entrer la sortie JSON ci-dessus qui est enregistrée dans un fichier nommé recoveryconfig.json.

az backup restore restore-azurewl --resource-group saphanaResourceGroup \
    --vault-name saphanaVault \
    --restore-config recoveryconfig.json \
    --output json

La sortie se présente ainsi :

{
  "eTag": null,
  "id": "/Subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/SAPHANARESOURCEGROUP/providers/Microsoft.RecoveryServices/vaults/SAPHANAVault/backupJobs/608e737e-c001-47ca-8c37-57d909c8a704",
  "location": null,
  "name": "608e737e-c001-47ca-8c37-57d909c8a704",
  "properties": {
    "actionsInfo": [
      "Cancellable"
    ],
    "activityId": "7ddd3c3a-c0eb-11ea-a5f8-54ee75ec272a",
    "backupManagementType": "AzureWorkload",
    "duration": "0:00:01.781847",
    "endTime": null,
    "entityFriendlyName": "HXE [hxehost]",
    "errorDetails": null,
    "extendedInfo": {
      "dynamicErrorMessage": null,
      "propertyBag": {
        "Job Type": "Restore as files"
      },
      "tasksList": [
        {
          "status": "InProgress",
          "taskId": "Transfer data from vault"
        }
      ]
    },
    "jobType": "AzureWorkloadJob",
    "operation": "Restore",
    "startTime": "2020-07-08T07:20:29.336434+00:00",
    "status": "InProgress",
    "workloadType": "SAPHanaDatabase"
  },
  "resourceGroup": "saphanaResourceGroup",
  "tags": null,
  "type": "Microsoft.RecoveryServices/vaults/backupJobs"
}

La réponse vous donnera le nom du travail. Vous pouvez utiliser ce nom pour effectuer le suivi de l’état du travail à l’aide de l’applet de commande az backup job show.

Les fichiers qui sont vidés dans le conteneur cible sont :

  • Fichiers de sauvegarde de base de données
  • Fichiers catalogue
  • Fichiers de métadonnées JSON (pour chaque fichier de sauvegarde impliqué)

En règle générale, un chemin d’accès de partage réseau, ou le chemin d’un partage de fichiers Azure monté lorsqu’il est spécifié comme chemin de destination, permet un accès plus facile à ces fichiers par d’autres ordinateurs du même réseau ou avec le même partage de fichiers Azure monté sur ces fichiers.

Notes

Pour restaurer les fichiers de sauvegarde de base de données sur un partage de fichiers Azure monté sur la machine virtuelle inscrite cible, assurez-vous que le compte racine dispose des autorisations de lecture ou d’écriture sur le partage de fichiers Azure.

En fonction du type de point de restauration choisi (Limite dans le temps ou Différentielle et complète), vous verrez un ou plusieurs dossiers créés dans le chemin de destination. Le dossier nommé Data_<date and time of restore> contient les sauvegardes complètes, l’autre dossier nommé Log contient les sauvegardes de fichiers journaux et d’autres sauvegardes (notamment les sauvegardes différentielles et incrémentielles).

Notes

Si vous avez sélectionné Restaurer à un point dans le temps, les fichiers journaux (vidés sur la machine virtuelle cible) peuvent parfois contenir des journaux au-delà du point dans le temps choisi pour la restauration. Sauvegarde Azure le fait pour s’assurer que les sauvegardes de fichier journal pour tous les services HANA sont disponibles pour une restauration cohérente et réussie jusqu’au point dans le temps choisi.

Notes

Si vous ne souhaitez pas restaurer toute la chaîne, mais uniquement un sous-ensemble de fichiers, suivez les étapes décrites ici.

Déplacez ces fichiers restaurés sur le serveur SAP HANA sur lequel vous souhaitez les restaurer en tant que base de données. Effectuez ensuite ces étapes pour restaurer la base de données :

  1. Définissez des autorisations sur le dossier/répertoire dans lequel les fichiers de sauvegarde sont stockés à l’aide de la commande suivante :

    chown -R <SID>adm:sapsys <directory>

  2. Exécutez l’ensemble de commandes suivant en tant que <SID>adm.

    su - <sid>adm

  3. Générez le fichier catalogue pour la restauration. Extrayez le BackupId du fichier de métadonnées JSON pour la sauvegarde complète et qui sera utilisé ultérieurement dans l’opération de restauration. Assurez-vous que les sauvegardes complètes et celles de fichiers journaux se trouvent dans des dossiers différents et supprimez les fichiers catalogue et les fichiers de métadonnées JSON dans ces dossiers.

    hdbbackupdiag --generate --dataDir <DataFileDir> --logDirs <LogFilesDir> -d <PathToPlaceCatalogFile>

    Dans la commande ci-dessus :

    • <DataFileDir> : le dossier qui contient les sauvegardes complètes
    • <LogFilesDir> – dossier qui contient les sauvegardes de fichiers journaux, les sauvegardes différentielles et incrémentielles (le cas échéant)
    • <PathToPlaceCatalogFile> : le dossier dans lequel le fichier catalogue généré doit être placé

  4. Restaurez à l’aide du fichier catalogue qui vient d’être généré via HANA Studio ou exécutez la requête de restauration HDBSQL avec ce catalogue nouvellement généré. Les requêtes HDBSQL sont répertoriées ci-dessous :

    • Pour restaurer à une limite dans le temps :

      Si vous créez une base de données restaurée, exécutez la commande HDBSQL pour créer une base de données <DatabaseName>, puis arrêtez la base de données pour la restauration. Toutefois, si vous restaurez uniquement une base de données existante, exécutez la commande HDBSQL pour arrêter la base de données.

      Exécutez ensuite la commande suivante pour restaurer la base de données :

      RECOVER DATABASE FOR <DatabaseName> UNTIL TIMESTAMP '<TimeStamp>' CLEAR LOG USING SOURCE '<DatabaseName@HostName>'  USING CATALOG PATH ('<PathToGeneratedCatalogInStep3>') USING LOG PATH (' <LogFileDir>') USING DATA PATH ('<DataFileDir>') USING BACKUP_ID <BackupIdFromJsonFile> CHECK ACCESS USING FILE
      • <DatabaseName> : nom de la nouvelle base de données ou de la base de données existante que vous souhaitez restaurer
      • <Timestamp> : horodatage exact de la limite de restauration dans le temps
      • <DatabaseName@HostName> : nom de la base de données dont la sauvegarde est utilisée pour la restauration et l’hôte/le nom du serveur SAP HANA sur lequel réside cette base de données. L’option USING SOURCE <DatabaseName@HostName> spécifie que la sauvegarde de données (utilisée pour la restauration) est celle d’une base de données avec un SID ou un nom différent de celui de la machine SAP HANA cible. Il n’est donc pas nécessaire de spécifier les restaurations effectuées sur le même serveur HANA à partir duquel la sauvegarde est effectuée.
      • <PathToGeneratedCatalogInStep3> : chemin du fichier catalogue généré à l’étape 3
      • <DataFileDir> : le dossier qui contient les sauvegardes complètes
      • <LogFilesDir> : dossier qui contient les sauvegardes de fichiers journaux, les sauvegardes différentielles et incrémentielles (le cas échéant)
      • <BackupIdFromJsonFile> : BackupId extrait à l’étape 3

    • Pour restaurer une sauvegarde complète ou différentielle particulière :

      Si vous créez une base de données restaurée, exécutez la commande HDBSQL pour créer une base de données <DatabaseName>, puis arrêtez la base de données pour la restauration. Toutefois, si vous restaurez uniquement une base de données existante, exécutez la commande HDBSQL pour arrêter la base de données :

      RECOVER DATA FOR <DatabaseName> USING BACKUP_ID <BackupIdFromJsonFile> USING SOURCE '<DatabaseName@HostName>'  USING CATALOG PATH ('<PathToGeneratedCatalogInStep3>') USING DATA PATH ('<DataFileDir>')  CLEAR LOG
      • <DatabaseName> : nom de la nouvelle base de données ou de la base de données existante que vous souhaitez restaurer
      • <Timestamp> : horodatage exact de la limite de restauration dans le temps
      • <DatabaseName@HostName> : nom de la base de données dont la sauvegarde est utilisée pour la restauration et l’hôte/le nom du serveur SAP HANA sur lequel réside cette base de données. L’option USING SOURCE <DatabaseName@HostName> spécifie que la sauvegarde de données (utilisée pour la restauration) est celle d’une base de données avec un SID ou un nom différent de celui de la machine SAP HANA cible. Il n’est donc pas nécessaire de spécifier les restaurations effectuées sur le même serveur HANA à partir duquel la sauvegarde est effectuée.
      • <PathToGeneratedCatalogInStep3> : chemin du fichier catalogue généré à l’étape 3
      • <DataFileDir> : le dossier qui contient les sauvegardes complètes
      • <LogFilesDir> : dossier qui contient les sauvegardes de fichiers journaux, les sauvegardes différentielles et incrémentielles (le cas échéant)
      • <BackupIdFromJsonFile> : BackupId extrait à l’étape 3

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/Backint 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}

Étape suivante