Учитывая archive_id, как я могу перемещать архив из AWS Glacier в S3 Bucket?

Question

Я написал архивную систему с Python Boto, которая содержит несколько файлов файлов tar и загружает их в Glacier. Все это отлично работает, и я храню все идентификаторы архива.

Я хотел протестировать загрузку большого архива (около 120 ГБ). Я начал поиск, но загрузка заняла> 24 часа, и в конце я получил 403, так как ресурс больше не был доступен и загрузка не удалась.

Если я архивировал прямо с моего сервера на ледник (пропуская S3), можно ли инициировать восстановление, которое восстанавливает архив в ведро S3, поэтому я могу взять более 24 часов, чтобы загрузить копию? Я ничего не видел в документах S3 или Glacier Boto.

В идеале я бы сделал это с Boto, но был бы открыт для других возможностей для сценариев. Кто-нибудь знает, как получить archiveId, я мог бы переместить архив из AWS Glacier в S3 Bucket? Если это невозможно, есть ли другие варианты, чтобы дать мне больше времени для загрузки больших файлов?

Спасибо!

http://docs.pythonboto.org/en/latest/ref/glacier.html http://docs.pythonboto.org/en/latest/ref/s3.html

Answer 1

Прямой интерфейс API Glacier и интеграция S3/Glacier не связаны друг с другом таким образом, который доступен пользователям AWS.

Если вы загружаете непосредственно на ледник, единственный способ вернуть данные - это вернуть его прямо из ледника.

И наоборот, если вы добавляете контент в Glacier через политики жизненного цикла S3, тогда нет открытого идентификатора архива Glacier, и единственный способ получить контент - это восстановить S3.

По существу, «вы» не являются клиентом Glacier, а «S3» является клиентом Glacier, когда вы используете интеграцию Glacier/S3. (На самом деле, это довольно хорошая ментальная модель - плата за хранение ледника даже выставляется по-разному - файлы, хранящиеся через интеграцию S3, оплачиваются вместе с другими сборами S3 на ежемесячном счете, а не с оплатой за ледник).

Путь к достижению того, что вы пытаетесь сделать непосредственно, состоит в том, чтобы сделать range retrievals, где вы только просите, чтобы ледник восстановил часть архива.

Еще одна причина, по которой вы можете выбрать поиск диапазона, - это управление тем, сколько данных вы загружаете с ледника Амазонки за данный период. Когда данные извлекаются из ледника Амазонки, сначала начинается поиск, который обычно завершается через 3-5 часов. Полученные данные затем доступны для скачивания в течение 24 часов. Поэтому вы можете получить архив по частям, чтобы управлять расписанием ваших загрузок. Вы также можете выполнить выбор диапазона, чтобы уменьшить или устранить ваши поисковые сборы.

^{— http://aws.amazon.com/glacier/faqs/}

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

Одно из преимуществ, которое я вижу в интеграции S3, состоит в том, что вы можете оставить свои данные «охлаждением» на S3 в течение нескольких часов/дней/недель, прежде чем вы поместите его «на лед» в леднике, что происходит автоматически ... так что вы можете получить его обратно с S3, не заплатив плату за загрузку, пока она не сидит на S3 в течение указанного вами времени, после чего автоматически переносится. Потенциальным недостатком является то, что он, кажется, вводит больше движущихся частей.

Answer 2

Использование политик жизненного цикла документа вы можете перемещать файлы непосредственно из S3 в леднике, и вы также можете восстановить те объекты обратно S3 с помощью restore метод boto.s3.Key объекта. Кроме того, см. this section документов S3 для получения дополнительной информации о том, как работает восстановление.