Бөлісу құралы:

Восстановление BLOB-объектов с архивного уровня

  • Мақала

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

Обработка события при восстановлении BLOB-объекта

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

Сетка событий Azure вызывает Событие Microsoft.Storage.BlobTierChanged при завершении восстановления BLOB-объектов:

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

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

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

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

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

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

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

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

См. также