Я ищу резервные копии различных каталогов и файлов с сервера Linux на AWS Glacier. Я пытаюсь разобраться в деталях, как с этим справиться.
Я хочу загружать файлы постепенно. По сути, если файл не изменился, я не хочу снова загружать его в Glacier, если он там уже существует. Я думаю, что разобрался с этой частью. Поскольку вы не можете получить мгновенные списки архивов в вашем хранилище Glacier, я буду вести локальную базу данных загруженных файлов, чтобы иметь возможность определять, что существует в хранилище, а что нет. Это позволит мне делать инкрементные резервные копии (загружать только отсутствующие или измененные файлы).
В соответствии с (http://aws.amazon.com/glacier/faqs/):
Архивы, хранящиеся в Amazon Glacier, неизменяемы, т. Е. Архивы можно выгружать и удалять, но нельзя редактировать или перезаписывать.
Итак, что произойдет, если я загружу файл / архив, а затем файл изменится локально, и в следующий раз, когда я сделаю резервную копию, как Glacier справится с этим, поскольку он не может перезаписать файл новой версией?
AWS взимает 0,03 доллара США за гигабайт за удаление архивов, возраст которых составляет менее 3 месяцев. Поскольку я делаю резервную копию локального сервера, я хочу удалить архивы, которые больше не существуют локально. Как лучше всего это организовать. Используйте локально сохраненный архивный инвентарь, чтобы определить, какие данные больше не существуют, и если им больше 3 месяцев, удалить их из Glacier? Это кажется простым, но есть ли лучший подход к этому?
Вы можете загружать либо отдельные файлы в виде архивов, либо быть более эффективным, сгруппировав свои файлы в файлы TAR или ZIP перед загрузкой. Идея файлов TAR / ZIP привлекательна, потому что она упрощает ее и требует меньших затрат на хранение, но мне интересно, как бы я поступил с инкрементными загрузками. Если загружен zip-файл размером 20 МБ, содержащий 10 000 файлов, и один из этих файлов изменен локально, нужно ли мне загружать еще один zip-файл размером 20 МБ? Теперь мне нужно съесть затраты на хранение двух копий почти всего в этих zip-файлах ... Кроме того, как я буду справляться с удалением вещей в ZIP-файле, которые больше не существуют локально? Поскольку я не хочу удалять весь zip-файл, теперь я беру плату за хранение файлов, которых больше не существует.
Может, я все это слишком много думаю. Каков самый простой способ ответить на эти вопросы?
Не знаю, важно это или нет, но я использую PHP SDK для этого сценария резервного копирования. Кроме того, я не хочу сначала загружать в корзину S3, а затем делать резервную копию корзины в Glacier, поскольку теперь мне придется платить за хранилище S3 и плату за передачу.
Итак, что произойдет, если я загружу файл / архив, а затем файл изменится локально, и в следующий раз, когда я сделаю резервную копию, как Glacier справится с этим, поскольку он не может перезаписать файл новой версией?
По Ледник FAQ:
Вы храните данные в Amazon Glacier в виде архива. Каждому архиву присваивается уникальный идентификатор архива, который позже можно использовать для извлечения данных. Архив может представлять собой один файл или вы можете объединить несколько файлов для загрузки в один архив. Вы загружаете архивы в хранилища. Хранилища - это коллекции архивов, которые вы используете для организации своих данных.
Это означает, что каждому загружаемому вами файлу присваивается уникальный идентификатор. Загрузите один и тот же файл дважды, и каждая копия файла получит свой собственный идентификатор. Это дает вам возможность при желании восстановить предыдущие версии файла.
Используйте локально сохраненный архивный инвентарь, чтобы определить, какие данные больше не существуют, и если им больше 3 месяцев, удалить их из Glacier? Это кажется простым, но есть ли лучший подход к этому?
Это, вероятно, лучший подход, чтобы избежать дополнительной платы за удаление данных возрастом менее 3 месяцев. Но вам нужно отслеживать и удалять не только данные, которых больше не существует. Как упоминалось выше, каждый раз, когда файл изменяется и вы повторно загружаете его в Glacier, вы получаете новый идентификатор файла. В конечном итоге вы захотите удалить и более старые версии файла, если вы не хотите, чтобы возможность восстановления этих старых версий.
Если загружен zip-файл размером 20 МБ, содержащий 10 000 файлов, и один из этих файлов изменен локально, нужно ли мне загружать другой zip-файл размером 20 МБ? Теперь мне нужно съесть затраты на хранение 2 копий почти всего в этих zip-файлах ... Кроме того, как я буду справляться с удалением вещей в ZIP-файле, которые больше не существуют локально? Поскольку я не хочу удалять весь zip-файл, теперь я беру плату за хранение файлов, которых больше не существует.
Это компромисс, который вам действительно нужно решить для себя. Вы заархивируете / заархивируете все, а затем будете вынуждены отслеживать эти файлы и все в них, или вам стоит загружать файлы по отдельности, чтобы вы могли очищать их по отдельности, поскольку они больше не нужны.
Вы можете рассмотреть несколько других подходов:
Однако, несмотря на все это, Glacier может быть не лучшим подходом для ваших нужд. Glacier действительно предназначен для архивирования данных, которое отличается от простого резервного копирования серверов. Если вы просто хотите делать инкрементные резервные копии сервера, то лучше использовать S3 вместо Glacier. Используя такой инструмент, как Двойственность или rdiff-резервное копирование (в сочетании с чем-то вроде s3fs) даст вам возможность делать инкрементные резервные копии в корзину S3 и очень легко управлять ими. Я использовал rdiff-backup на нескольких Linux-системах на протяжении многих лет и обнаружил, что он работает довольно хорошо.
Вот инструмент командной строки для * nix, который поддерживает загрузку только измененных файлов, замену локально измененных файлов и удаление локально удаленных файлов из Glacier. https://github.com/vsespb/mt-aws-glacier
В качестве альтернативы вы можете использовать что-то вроде Двойственность, а затем загрузите созданные им архивы.
У этого есть несколько преимуществ:
Самый простой способ использовать Duplicity с Glacier: