Поделиться через


Восстановление данных из объекта Blob на архивном уровне

Хотя объект BLOB находится на уровне доступа к архиву, он считается в автономном режиме и не может быть прочитан или изменен. Чтобы считывать или изменять данные в архивном BLOB-объекте, необходимо сначала восстановить BLOB-объект, переведя его на подключенный (горячий или холодный) уровень. Восстановить BLOB-объект, хранящийся на архивном уровне, можно двумя способами:

Восстановление большого двоичного объекта с архивного уровня может занять несколько часов. Корпорация Майкрософт рекомендует архивировать большие blob-объекты, чтобы обеспечить оптимальную производительность при повторном копировании. Для восстановления большого количества мелких двоичных объектов может потребоваться дополнительное время из-за затрат на обработку каждого объекта. Максимум 10 ГиБ данных на учетную запись хранения может быть восстановлено в течение часа с использованием приоритетного извлечения.

Чтобы узнать, как реанимировать архивированный объект BLOB в сетевой слой, см. статью Восстановление архивированного объекта BLOB в сетевой слой.

Приоритет восстановления

При восстановлении BLOB-объекта можно задать приоритет для операции регидратации с помощью необязательного заголовка x-ms-rehydrate-priority в операции Установка уровня BLOB или Копирование BLOB. Для восстановления доступны перечисленные ниже варианты приоритета.

  • Стандартный приоритет: запрос на повторное восстановление обрабатывается в том порядке, в который он был получен, и может занять до 15 часов для объектов размером до 10 ГБ.
  • Высокий приоритет: запрос на повторное восстановление имеет приоритет по сравнению со стандартными запросами приоритета и может завершиться менее чем за один час для объектов размером менее 10 ГБ.

Чтобы проверить приоритет выполнения операции восстановления во время её выполнения, вызовите Get Blob Properties, чтобы получить значение заголовка x-ms-rehydrate-priority. Свойство приоритета регидратации возвращает значение либо Standard либо High.

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

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

Приоритет восстановления для ожидающей операции невозможно понизить со значения Высокий до Стандартный. Помните, что обновление параметра приоритета восстановления может повлиять на выставление счетов.

Сведения о настройке и обновлении параметра приоритета восстановления см. в разделе "Повторное восстановление архивированного большого двоичного объекта" на онлайн-уровне.

Дополнительная информация о различиях в ценах между стандартным и высоким приоритетом запросов на восстановление данных см. в разделе "Цены на хранилище BLOB-объектов Azure".

Копирование архивного большого двоичного объекта на подключенный уровень

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

Архивный BLOB-объект необходимо копировать в новый BLOB-объект с другим именем или с другим контейнером. Перезаписать исходный BLOB-объект, скопировав его сам в себя, невозможно.

Копируя объект BLOB из архивного уровня в уровень онлайн, вы можете избежать уплаты за досрочное удаление, которая взимается, если переводите объект с архивного уровня до истечения требуемого 180-дневного периода. Дополнительные сведения см. в разделе Архивный уровень доступа.

Этот параметр также имеет смысл, если в учетной записи хранения действует политика управления жизненным циклом, и daysAfterLastTierChangeGreaterThan условие не добавляется в каждое tierToArchive действие политики. В этом случае восстановление большого двоичного объекта с помощью операции Set Blob Tier может привести к сценарию, когда политика жизненного цикла перемещает большой двоичный объект обратно на архивный уровень после повторного разархивирования, так как время последнего изменения выходит за пределы порогового значения, установленного для политики. Операция копирования покидает исходный большой двоичный объект на уровне архива и создает новый большой двоичный объект с другим именем и новым временем последнего изменения, поэтому нет риска, что регидратированный большой двоичный объект будет перемещен на архивный уровень политикой жизненного цикла.

Копирование большого двоичного объекта из архивного уровня хранения может занять несколько часов в зависимости от выбранного приоритета восстановления данных. За кулисами операция копирования BLOB-объектов считывает архивный исходный BLOB-объект, чтобы создать новый активный BLOB-объект на выбранном целевом уровне. Новый большой двоичный объект может отображаться при перечислении больших двоичных объектов в родительском контейнере до завершения операции восстановления, но его уровень будет установлен для архивирования. Данные недоступны до тех пор, пока операция чтения из исходного блоба в архивном уровне не будет завершена и содержимое блоба не будет записано в новый целевой блоб на онлайн уровне. Новый большой двоичный объект является независимой копией, поэтому изменение или удаление не влияет на исходный большой двоичный объект на уровне архива.

Чтобы узнать, как повторно восстановить большой двоичный объект, переместив его на онлайн-уровень, см. раздел "Повторное восстановление большого двоичного объекта с помощью операции копирования".

Это важно

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

Повторное копирование архивного большого двоичного объекта путем копирования его на уровень назначения через Интернет поддерживается только в той же учетной записи хранения только для версий служб до 2021-02-12. Начиная с версии службы 2021-02-12, вы можете восстановить заархивированный BLOB-объект, скопировав его в другую учетную запись хранения, если целевая учетная запись находится в том же регионе, что и исходная учетная запись. Реактивация данных между учетными записями хранения позволяет вам отделить производственные данные от резервных копий, сохраняя их в раздельных учетных записях. Изоляция архивированных данных в отдельной учетной записи также может помочь снизить затраты от непреднамеренного восстановления.

Целевой объект BLOB для операции копирования должен находиться на уровне доступа в сети (горячем или холодном). Вы не можете скопировать архивный объект BLOB в целевой объект BLOB, который также находится в архивном уровне.

В следующей таблице показано поведение операции копирования BLOB-объектов в зависимости от уровней исходного и целевого BLOB-объекта.

Источник горячего уровня Источник холодного уровня Источник уровня архивации
Пункт назначения горячего уровня данных Поддерживается Поддерживается Поддерживается в разных учетных записях в одном регионе с версией 2021-02-12 и более поздними версиями. Поддерживается в той же учетной записи хранения только для более ранних версий. Требуется восстановление объекта данных.
Назначение уровня "Холодный" Поддерживается Поддерживается Поддерживается в разных учетных записях в одном регионе с версией 2021-02-12 и более поздними версиями. Поддерживается в той же учетной записи хранения только для более ранних версий. Требуется восстановление больших двоичных объектов.
Назначение уровня архивации Поддерживается Поддерживается Не поддерживается

Восстановление из дополнительного региона

Если вы настроили свою учетную запись хранения для использования геоизбыточного хранилища с доступом к чтению (RA-GRS), вы можете использовать операцию копирования BLOB-объектов для восстановления BLOB-объектов во вторичном регионе в другую учетную запись хранения, расположенную в том же регионе. См. Восстановление из дополнительного региона.

Дополнительные сведения см. в разделе Доступ на чтение для данных в дополнительном регионе.

Изменение уровня доступа BLOB-объекта на подключенный уровень

Второй вариант восстановления большого двоичного объекта из архивного уровня в онлайн-уровень заключается в изменении уровня большого двоичного объекта путем вызова Set Blob Tier. С ее помощью можно изменить уровень архивного BLOB-объекта на горячий или холодный.

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

Чтобы узнать, как восстановить объект, изменив его уровень на онлайн-уровень, см. Реидратация объекта путем изменения его уровня.

Осторожность

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

Чтобы избежать этого сценария, добавьте daysAfterLastTierChangeGreaterThan условие в tierToArchive действие политики. Кроме того, вы можете восстановить архивированный блоб, скопировав его, как описано в разделе Копирование архивированного блоба в онлайн-уровень. При выполнении операции копирования создается новый экземпляр блоба с обновленным временем последнего изменения, поэтому он не задействует политику управления жизненным циклом.

Проверка состояния операции повторного восстановления BLOB-объектов

Во время операции повторной гидратации объектов BLOB можно вызвать операцию Get Blob Properties, чтобы проверить их состояние. Сведения о том, как проверить состояние операции восстановления, см. в разделе "Проверка состояния операции восстановления".

Обработка события при повторной гидратации BLOB-объекта

Регенерация архивного большого двоичного объекта может занять до 15 часов, и неэффективно снова и снова опрашивать Получить свойства BLOB-объекта, чтобы определить, завершена ли регенерация. Корпорация Майкрософт рекомендует использовать сетку событий Azure для записи события, которое возникает при завершении восстановления для повышения производительности и оптимизации затрат.

Служба Azure Event Grid вызывает событие Microsoft.Storage.BlobTierChanged при завершении восстановления блоба:

  • Событие Microsoft.Storage.BlobTierChanged возникает при изменении уровня блоба. В контексте восстановления больших двоичных объектов это событие возникает, когда уровень доступа целевого большого двоичного объекта успешно изменяется с архивного уровня на один из онлайн-уровней (горячий, прохладный или холодный). Чтобы изменить уровень хранения архивного BLOB-объекта, можно воспользоваться операцией установки уровня BLOB, или с помощью операции копирования скопировать архивный BLOB-объект в новый целевой BLOB-объект на уровне онлайн доступа.

Сведения о том, как записать событие при повторной гидратации и отправить его в обработчик событий функции Azure, см. в статье Запуск функции Azure в ответ на событие восстановления BLOB-объектов.

Дополнительные сведения об обработке событий в хранилище BLOB-объектов см. в статье Reacting to Azure Blob storage events and Azure Blob Storage as Event Grid source.

Цены и выставление счетов

Операция восстановления с командой Установить уровень BLOB оплачивается за транзакции чтения данных и объем извлечения данных. Высокоприоритетное восстановление имеет более высокие затраты на восстановление данных и затраты на получение данных по сравнению со стандартным приоритетом. Реидратация с высоким приоритетом отображается как отдельная позиция на вашем счете. Если запрос с высоким приоритетом на возврат архивного объекта BLOB размером менее 10 ГБ занимает более пяти часов, плата по ставке быстрого извлечения не будет взиматься. Однако стандартные тарифы на извлечение по-прежнему применяются.

Копирование архивного большого двоичного объекта на онлайн-уровень с Copy Blob оплачивается за транзакции чтения данных и размер извлеченных данных. При создании целевого большого двоичного объекта на онлайн-уровне взимается плата за транзакции записи данных. Плата за раннее удаление не применяется при копировании в онлайн-объект хранения, так как исходный объект хранения остается неизмененным на уровне архива. Плата за получение с высоким приоритетом применяется, если выбрано.

Блобы на уровне архива должны храниться не менее 180 дней. Удаление или изменение уровня архивного объекта до истечения 180-дневного периода вызывает плату за досрочное удаление. Например, если большой двоичный объект перемещается на архивный уровень, а затем удаляется или перемещается на горячий уровень через 45 дней, плата за раннее удаление будет взиматься, эквивалентная 135 (180 минус 45) дней хранения этого большого двоичного объекта на уровне архива. Дополнительные сведения см. в разделе Архивный уровень доступа.

Дополнительные сведения о ценах на блочные BLOB-объекты и восстановление данных см. в ценах на службу хранилища Azure. Дополнительные сведения о расходах на передачу исходящих данных см. в разделе "Сведения о ценах на передачу данных".

См. также