Восстановление объектов BLOB в Azure до определенного момента времени с помощью REST API Azure Data Protection

2025-06-17

В этой статье описывается, как восстановить блобы при помощи Azure Backup через REST API. Вы также можете восстановить объекты BLOB Azure с помощью портала Azure, Azure PowerShell, Azure CLI.

Это важно

Прежде чем приступить к восстановлению Azure BLOB с помощью Azure Backup, ознакомьтесь с важными моментами.

Предпосылки

В этой статье рассматривается, что у вас есть резервная копия, настроенная для одной или нескольких учетных записей хранения. Узнайте, как настроить резервную копию для данных блочных BLOB-объектов , если она не настроена.

Чтобы проиллюстрировать действия по восстановлению в этой статье, мы будем ссылаться на большие двоичные объекты в учетной записи хранения с именем msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d, защищенной с помощью существующего хранилища TestBkpVault резервных копий в группе testBkpVaultRG ресурсов.

Подготовка к восстановлению объектов Blob в Azure

Теперь можно выполнить операцию восстановления для операционных резервных копий и архивных резервных копий объектов BLOB в Azure.

Выберите уровень резервного копирования:

Оперативное резервное копирование
Резервное копирование в защищенном хранилище

Получить допустимый временной диапазон для восстановления

Так как оперативное резервное копирование больших двоичных объектов выполняется непрерывно, нет отдельных точек восстановления. Вместо этого нам нужно получить допустимый временной диапазон, в рамках которого блобы могут быть восстановлены до любого момента времени. В этом примере мы проверяем допустимые диапазоны времени для восстановления в течение последних 30 дней.

Диапазоны времени для восстановления могут быть перечислены с помощью API find restorable time range. Это API POST, которое активирует операцию для вычисления диапазона непрерывных резервных копий для бинарных объектов в учетной записи хранилища.

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DataProtection/backupVaults/{vaultName}/backupInstances/{backupInstanceName}/findRestorableTimeRanges?api-version=2021-01-01

В нашем примере это преобразуется в

POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupInstances/msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d/findRestorableTimeRanges?api-version=2021-01-01

Создание текста запроса для получения допустимых диапазонов времени для восстановления

Чтобы активировать операцию для вычисления допустимых диапазонов времени, ниже приведены компоненты текста запроса.

Имя	Тип	Описание
sourceDatastoreType	RestoreSourceDataStoreType	Хранилище данных, содержащее данные для восстановления
Время начала	Струна	Время начала для запроса на вывод диапазонов восстановления. Формат ISO 8601.
время окончания	Струна	Время окончания для запроса на вывод диапазонов восстановления. Формат ISO 8601.

Пример текста запроса для получения допустимого диапазона времени

Следующий текст запроса определяет свойства, необходимые для получения диапазонов времени непрерывных данных, которые можно восстановить. Так как резервные копии BLOB-объектов находятся в учетной записи хранения, хранилище данных — "Операционный". Вы можете дать время начала и окончания, которое помогает сузить процесс поиска и вернуть доступный диапазон времени.

{
  "sourceDataStoreType": "OperationalStore",
  "startTime": "",
  "endTime": ""
}

Ответы для получения допустимых диапазонов времени

После отправки запроса POST ответ равен 200(ОК) с временем начала и окончания диапазона, доступным для восстановления в течение указанного времени начала и окончания запроса.

Имя	Тип	Описание
200(ОК)	AzureBackupFindRestorableTimeRangesResponseResource	ХОРОШО
Другие коды состояния	CloudError	Ответ на ошибку, описывающий, почему операция завершилась сбоем.

Пример ответа для получения допустимых диапазонов времени

HTTP/1.1 200 OK
Content-Length: 379
Content-Type: application/json
Expires: -1
Pragma: no-cache
X-Content-Type-Options: nosniff
x-ms-request-id:
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-writes: 1199
x-ms-correlation-request-id: a2b7c2d9-01f5-499a-b521-55da4862c79a
x-ms-routing-request-id: CENTRALUSEUAP:20210708T184646Z:4996a2bf-2df8-48a7-9b53-a552466a27f7
Cache-Control: no-cache
Date: Thu, 08 Jul 2021 18:46:45 GMT
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET

{
  "id": "msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d",
  "type": "Microsoft.DataProtection/backupVaults/backupInstances/findRestorableTimeRanges",
  "properties": {
    "restorableTimeRanges": [
      {
        "startTime": "2021-07-06T18:46:45.947728Z",
        "endTime": "2021-07-08T18:46:45.9932408Z",
        "objectType": "RestorableTimeRange"
      }
    ],
    "objectType": "AzureBackupFindRestorableTimeRangesResponse"
  }
}

После того как точка во времени для восстановления в ту же учетную запись хранения определена, существует несколько вариантов восстановления.

Вариант 1. Восстановление всех больших двоичных объектов до точки во времени

При использовании этой опции все блоки данных BLOB в учетной записи хранения восстанавливаются, возвращая их к выбранной точке во времени. Учетные записи хранения, содержащие большие объемы данных или испытывающие высокую степень изменений, могут потребовать больше времени на восстановление.

Создание тела запроса для восстановления всех блобов на определенный момент времени

Основные моменты, которые следует помнить в этом сценарии:

Восстановление происходит с той же учетной записью хранения, что означает, что целевой объект для восстановления совпадает с источником данных. Это отражается в разделе сведений о целевом объекте восстановления ниже.
Это непрерывные резервные копии, поэтому время восстановления — это точка во времени, а не отдельная точка восстановления.
Все блобы восстановлены
Исходное хранилище данных, где находятся резервные копии, является той же учетной записью хранения. Поэтому исходное хранилище данных — "Операционный" хранилище данных.

{
  "restoreRequestObject": {
    "objectType": "AzureBackupRecoveryTimeBasedRestoreRequest",
    "restoreTargetInfo": {
      "objectType": "RestoreTargetInfo",
      "recoveryOption": "FailIfExists",
      "restoreLocation": "westus",
      "datasourceInfo": {
        "datasourceType": "Microsoft.Storage/storageAccounts/blobServices",
        "objectType": "Datasource",
        "resourceID": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
        "resourceLocation": "westus",
        "resourceName": "msblobbackup",
        "resourceType": "Microsoft.Storage/storageAccounts",
        "resourceUri": ""
      }
    },
    "sourceDataStoreType": "OperationalStore",
    "recoveryPointTime": "2021-07-08T00:00:00.0000000Z"
  }
}

Вариант 2. Восстановление нескольких контейнеров до определенного момента во времени

С помощью этого параметра можно выбрать до 10 контейнеров для восстановления или восстановления части BLOB по префиксу. Вы можете указать до 10 лексикографических диапазонов блобов в рамках одного контейнера или между несколькими контейнерами, чтобы вернуть эти блобы в предыдущее состояние на определенный момент времени. В случае использования префиксов ниже приведены некоторые моменты, которые следует учитывать:

Для отделения имени контейнера от префикса объекта BLOB можно использовать слэш (/).
Начало указанного диапазона является инклюзивным, однако указанный диапазон является эксклюзивным.

Узнайте больше о использовании префиксов для восстановления диапазонов blob.

Составьте тело запроса для восстановления выбранных контейнеров или нескольких блобов на момент времени

Основные моменты, которые следует помнить в этом сценарии:

Восстановление происходит с той же учетной записью хранения, что означает, что целевой объект для восстановления совпадает с источником данных. Это отражается в разделе сведений о целевом объекте восстановления ниже.
Это непрерывные резервные копии, поэтому время восстановления — это точка во времени, а не отдельная точка восстановления.
Некоторые элементы в учетной записи хранения были восстановлены. Они могут быть контейнерами или блобами с шаблонным префиксом.
Исходное хранилище данных, т. е. место хранения резервных копий, совпадает с учетной записью хранения. Поэтому исходное хранилище данных — "Операционный" хранилище данных.

{
  "restoreRequestObject": {
    "objectType": "AzureBackupRecoveryTimeBasedRestoreRequest",
    "restoreTargetInfo": {
      "objectType": "ItemLevelRestoreTargetInfo",
      "recoveryOption": "FailIfExists",
      "restoreLocation": "westus",
      "restoreCriteria": [
        {
          "objectType": "RangeBasedItemLevelRestoreCriteria",
          "minMatchingValue": "Container1",
          "maxMatchingValue": "Container10-0"
        }
      ],
      "datasourceInfo": {
        "datasourceType": "Microsoft.Storage/storageAccounts/blobServices",
        "objectType": "Datasource",
        "resourceID": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
        "resourceLocation": "westus",
        "resourceName": "msblobbackup",
        "resourceType": "Microsoft.Storage/storageAccounts",
        "resourceUri": ""
      }
    },
    "sourceDataStoreType": "OperationalStore",
    "recoveryPointTime": "2021-07-08T00:00:00.0000000Z"
  }
}

Получите соответствующую точку восстановления

Чтобы получить список всех доступных точек восстановления для экземпляра резервного копирования, используйте API list recovery points.

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DataProtection/backupVaults/{vaultName}/backupInstances/{backupInstanceName}/recoveryPoints?api-version=2021-07-01

Подготовьте тело запроса для выполнения восстановления из сохранённой резервной копии.

Ниже приведен текст запроса для восстановления контейнера bash 2 из хранилища резервной копии.

{
  "objectType": "AzureBackupRecoveryPointBasedRestoreRequest",
  "sourceDataStoreType": "VaultStore",
  "restoreTargetInfo": {
    "objectType": "itemLevelRestoreTargetInfo",
    "recoveryOption": "FailIfExists",
    "dataSourceInfo": {
      "objectType": "Datasource",
      "resourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/Blob-Backup/providers/Microsoft.Storage/storageAccounts/azclitestrestore2",
      "resourceName": "azclitestrestore2",
      "resourceType": "Microsoft.Storage/storageAccounts",
      "resourceLocation": "not specified",
      "resourceUri": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/Blob-Backup/providers/Microsoft.Storage/storageAccounts/azclitestrestore2",
      "datasourceType": "Microsoft.Storage/storageAccounts/blobServices",
      "resourceProperties": {}
    },
    "restoreCriteria": [
      {
        "objectType": "ItemPathBasedRestoreCriteria",
        "itemPath": "bash2",
        "isPathRelativeToBackupItem": true,
        "subItemPathPrefix": null
      }
    ],
    "restoreLocation": "eastus2euap"
  },
  "recoveryPointId": "33fdef0e0e2e4594b63092ae9a56f58d"
}

Если вы хотите восстановить блобы с определёнными префиксами, укажите список префиксов в качестве значения для subItemPathPrefix. Вот пример восстановления блобов, начинающихся с префиксов dd, ee или ff, в контейнере-2 вашей резервной учетной записи хранилища.

   {
        "is_path_relative_to_backup_item": true,
        "item_path": "container2",
        "object_type": "ItemPathBasedRestoreCriteria",
        "sub_item_path_prefix": [
          "dd",
          "ee",
          "ff"
        ]
      }

Проверка запросов на восстановление

После подготовки текста запроса его можно проверить с помощью api восстановления. Как и API проверки для резервного копирования, это операция POST .

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DataProtection/backupVaults/{vaultName}/backupInstances/{backupInstanceName}/validateRestore?api-version=2021-01-01

В нашем примере мы получим следующее:

POST "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupInstances/msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d/validateRestore?api-version=2021-01-01"

Текст запроса для этого API POST подробно описан здесь. Мы создали то же самое в приведенном выше разделе для сценариев восстановления всех блобов и восстановления нескольких элементов. Мы будем использовать то же самое для активации операции проверки.

Ответ на запросы о проверке восстановления

Запрос проверки восстановления — это асинхронная операция. Это означает, что такая операция создает другую операцию, которая должна отслеживаться отдельно.

Она возвращает два ответа: 202 (принято), когда создается другая операция, и 200 (ОК), когда эта операция завершается.

Имя	Тип	Описание
200 OK (Запрос выполнен успешно)		Состояние запроса проверки
202 Принято		Принято

Пример ответа на восстановление проверки-запроса

После отправки операции POST начальный ответ будет 202 Accepted с заголовком Azure-asyncOperation.

HTTP/1.1 202 Accepted
Content-Length: 0
Expires: -1
Pragma: no-cache
Retry-After: 10
Azure-AsyncOperation: https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExOzVlNzMxZDBiLTQ3MDQtNDkzNS1hYmNjLWY4YWEzY2UzNTk1ZQ==?api-version=2021-01-01
X-Content-Type-Options: nosniff
x-ms-request-id:
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-writes: 1199
x-ms-correlation-request-id: bae60c92-669d-45a4-aed9-8392cca7cc8d
x-ms-routing-request-id: CENTRALUSEUAP:20210708T205935Z:f51db7a4-9826-4084-aa3b-ae640dc78af6
Cache-Control: no-cache
Date: Thu, 08 Jul 2021 20:59:35 GMT
Location: https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationResults/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExOzVlNzMxZDBiLTQ3MDQtNDkzNS1hYmNjLWY4YWEzY2UzNTk1ZQ==?api-version=2021-01-01
X-Powered-By: ASP.NET

Проверьте заголовок Azure-AsyncOperation простым запросом GET. При успешном выполнении запроса возвращается значение 200 ОК с ответом на состояние успешности.

 GET https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExOzVlNzMxZDBiLTQ3MDQtNDkzNS1hYmNjLWY4YWEzY2UzNTk1ZQ==?api-version=2021-01-01

{
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExOzVlNzMxZDBiLTQ3MDQtNDkzNS1hYmNjLWY4YWEzY2UzNTk1ZQ==",
  "name": "ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExOzVlNzMxZDBiLTQ3MDQtNDkzNS1hYmNjLWY4YWEzY2UzNTk1ZQ==",
  "status": "Succeeded",
  "startTime": "2021-07-08T20:59:35.0060264Z",
  "endTime": "2021-07-08T20:59:57Z"
}

Запросы на инициирование восстановления

Операция активации восстановления — это API POST . Все сведения об операции восстановления триггера описаны здесь.

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DataProtection/backupVaults/{vaultName}/backupInstances/{backupInstanceName}/restore?api-version=2021-01-01

В нашем примере мы получим следующее:

POST "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupInstances/msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d/restore?api-version=2021-01-01"

Создание текста запроса для операций восстановления

После проверки запросов можно использовать тот же текст запроса для активации запроса восстановления с незначительными изменениями.

Пример тела запроса для восстановления всех блобов

Единственное изменение из текста запроса validate-restore — удаление объекта restoreRequest в начале.

{
  "objectType": "AzureBackupRecoveryTimeBasedRestoreRequest",
  "restoreTargetInfo": {
    "objectType": "RestoreTargetInfo",
    "recoveryOption": "FailIfExists",
    "restoreLocation": "westus",
    "datasourceInfo": {
      "datasourceType": "Microsoft.Storage/storageAccounts/blobServices",
      "objectType": "Datasource",
      "resourceID": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
      "resourceLocation": "westus",
      "resourceName": "msblobbackup",
      "resourceType": "Microsoft.Storage/storageAccounts",
      "resourceUri": ""
    }
  },
  "sourceDataStoreType": "OperationalStore",
  "recoveryPointTime": "2021-07-08T00:00:00Z"
}

Пример тела запроса для восстановления элементов или нескольких бинарных объектов

Единственное изменение из текста запроса validate-restore — удаление объекта restoreRequest в начале.

{
  "objectType": "AzureBackupRecoveryTimeBasedRestoreRequest",
  "restoreTargetInfo": {
    "objectType": "ItemLevelRestoreTargetInfo",
    "recoveryOption": "FailIfExists",
    "restoreLocation": "westus",
    "restoreCriteria": [
      {
        "objectType": "RangeBasedItemLevelRestoreCriteria",
        "minMatchingValue": "Container1",
        "maxMatchingValue": "Container2"
      }
    ],
    "datasourceInfo": {
      "datasourceType": "Microsoft.Storage/storageAccounts/blobServices",
      "objectType": "Datasource",
      "resourceID": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
      "resourceLocation": "westus",
      "resourceName": "msblobbackup",
      "resourceType": "Microsoft.Storage/storageAccounts",
      "resourceUri": ""
    }
  },
  "sourceDataStoreType": "OperationalStore",
  "recoveryPointTime": "2021-07-08T00:00:00.0000000Z"
}

Ответ на запросы о запуске восстановления

Запрос на восстановление триггера — это асинхронная операция. Это означает, что такая операция создает другую операцию, которая должна отслеживаться отдельно.

Имя	Тип	Описание
200 OK (Запрос выполнен успешно)		Статус запроса на восстановление
202 Принято		Принято

Пример ответа на запрос о запуске восстановления

После отправки операции POST начальный ответ будет 202 Accepted с заголовком Azure-asyncOperation.

HTTP/1.1 202 Accepted
Content-Length: 0
Expires: -1
Pragma: no-cache
Retry-After: 30
Azure-AsyncOperation: https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExO2Q1NDIzY2VjLTczYjYtNDY5ZC1hYmRjLTc1N2Q0ZTJmOGM5OQ==?api-version=2021-01-01
X-Content-Type-Options: nosniff
x-ms-request-id:
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-writes: 1197
x-ms-correlation-request-id: 8661209c-5b6a-44fe-b676-4e2b9c296593
x-ms-routing-request-id: CENTRALUSEUAP:20210708T204652Z:69e3fa4b-c5d9-4601-9410-598006ada187
Cache-Control: no-cache
Date: Thu, 08 Jul 2021 20:46:52 GMT
Location: https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationResults/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExO2Q1NDIzY2VjLTczYjYtNDY5ZC1hYmRjLTc1N2Q0ZTJmOGM5OQ==?api-version=2021-01-01
X-Powered-By: ASP.NET

Проверьте заголовок Azure-AsyncOperation простым запросом GET. При успешном выполнении запроса возвращается 200 ОК с идентификатором задания, который следует отслеживать для завершения запроса на восстановление.

GET https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExO2Q1NDIzY2VjLTczYjYtNDY5ZC1hYmRjLTc1N2Q0ZTJmOGM5OQ==?api-version=2021-01-01

{
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/providers/Microsoft.DataProtection/locations/westus/operationStatus/ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExO2Q1NDIzY2VjLTczYjYtNDY5ZC1hYmRjLTc1N2Q0ZTJmOGM5OQ==",
  "name": "ZmMzNDFmYWMtZWJlMS00NGJhLWE4YTgtMDNjYjI4Y2M5OTExO2Q1NDIzY2VjLTczYjYtNDY5ZC1hYmRjLTc1N2Q0ZTJmOGM5OQ==",
  "status": "Succeeded",
  "startTime": "2021-07-08T20:46:52.4110868Z",
  "endTime": "2021-07-08T20:46:56Z",
  "properties": {
    "jobId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupJobs/c4bd49a1-0645-4eec-b207-feb818962852",
    "objectType": "OperationJobExtendedInfo"
  }
}

Отслеживание вакансий

Запросы на восстановление триггера запускают задание восстановления, а результирующий идентификатор задания отслеживается с помощью API заданий GET.

Используйте простую команду GET для отслеживания JobId, заданного в приведенном выше ответе на восстановление триггера .

 GET /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupJobs/c4bd49a1-0645-4eec-b207-feb818962852?api-version=2021-01-01

{
  "properties": {
    "activityID": "4195ca6c-e02d-11eb-b0b1-70bc105e2242",
    "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
    "backupInstanceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupInstances/msblobbackup-f2df34eb-5628-4570-87b2-0331d797c67d",
    "policyId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupPolicies/BlobBackup-Policy",
    "dataSourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
    "vaultName": "BV-JPE-GRS",
    "backupInstanceFriendlyName": "msblobbackup",
    "policyName": "BlobBackup-Policy",
    "sourceResourceGroup": "RG-BlobBackup",
    "dataSourceName": "msblobbackup",
    "progressEnabled": false,
    "etag": "W/\"datetime'2021-07-08T20%3A48%3A36.6999667Z'\"",
    "sourceSubscriptionID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
    "dataSourceLocation": "westus",
    "startTime": "2021-07-08T20:44:19.5467125Z",
    "endTime": "2021-07-08T20:48:35.8297312Z",
    "dataSourceType": "Microsoft.Storage/storageAccounts/blobServices",
    "operationCategory": "Restore",
    "operation": "Restore",
    "status": "Completed",
    "isUserTriggered": true,
    "supportedActions": [
      ""
    ],
    "duration": "PT4M16.2830187S",
    "extendedInfo": {
      "sourceRecoverPoint": {
        "recoveryPointTime": "2021-07-08T00:00:00Z"
      },
      "recoveryDestination": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/RG-BlobBackup/providers/Microsoft.Storage/storageAccounts/msblobbackup",
      "subTasks": [
        {
          "taskId": 1,
          "taskName": "Trigger Restore",
          "taskStatus": "Completed"
        }
      ]
    }
  },
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourceGroups/TestBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/testBkpVault/backupJobs/c4bd49a1-0645-4eec-b207-feb818962852",
  "name": "c4bd49a1-0645-4eec-b207-feb818962852",
  "type": "Microsoft.DataProtection/BackupVaults/backupJobs"
}

Статус задания выше указывает, что задание восстановления завершено и все содержимое хранилища было восстановлено к указанному моменту времени.

Дальнейшие шаги

Обзор резервного копирования BLOB-объектов Azure.

Дополнительные сведения о REST API Azure Backup см. в следующих документах: