Как организовать инкрементальный бэкап S3?

Question

[Vitaly Karasik]

Заказчик попросил ежедневный бэкап объектов из S3.
Я за пару минут написал

aws s3 sync s3://origin-bucket/folder s3://backup-bucket/folder-CURRENT_TIMESTAMP

Но потом призадумался. Заказчик мечтает
- о чем-то инкрементальном
- да еще хорошо бы зазиппованный архив (для простоты скажем что хранятся документы, и хочется возможности откатиться к нужной версии, "как в Git").

Насколько понимаю, эти пожелания выполнить непросто - первое по причине отсутствия простой возможноcти фильтровать объекты по дате, а второе - так как для этого придется скачивать файлы на локальную машину.
Я думаю включить versioning в S3 для бэкапа. Или есть более элегантное решение?

UPDATE: большое спасибо всем ответившим! Вы заставили меня подумать, и я понял, что надо использовать S3 versioning and replication, вместо того чтобы изобретать велосипед со скриптами и cronjobs.

Comments

[Сергей Горностаев]

С какой целью нужен заказчику такой бэкап?

[Ромзес Панагиотис]

Заказчик мечтает
- о чем-то инкрементальном
- да еще хорошо бы зазиппованный архив (для простоты скажем что хранятся документы, и хочется возможности откатиться к нужной версии, "как в Git").

Звучит, как особые требования. Если решение "из коробки" (versioning) недостаточно, то, мне кажется, нужно искать специальный софт.

[Vitaly Karasik]

Сергей Горностаев, чтобы иметь возможность вернуться к старой версии документа.

Answer 1

[Ромзес Панагиотис]

Как чисто "наколенный" вариант, использовать:

EC2 инстанс с запускаемым софтом:
1. Монтирование S3 (source, target) в качестве папки: goofys или s3fs.
2. В качестве резервирующего ПО: Bup для дедупликации. Умеет подобно Git...
На входе папка исходного бакета, а на выходе - целевая.

Сам не пробовал. Просто как идея.

Comments

[Vitaly Karasik]

Спасибо, но даже для меня это слишком олдскульно.

[Vitaly Karasik]

UPDATE: большое спасибо всем ответившим! Вы заставили меня подумать, и я понял, что надо использовать S3 versioning and replication, вместо того чтобы изобретать велосипед со скриптами и cronjobs.

Answer 2

[rPman]

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

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

p.s. убери из требований zip архив (точнее не храни его так, формируй по требованию), тогда резервирование можно оптимизировать на уровне файлов или даже файловой системы (например btrfs позволяет получать диф снапшота на лету в виде файла и вносить эти изменения в другом месте)

Comments

[Ромзес Панагиотис]

С дедупликацией данных заморочки типа

потребуется загрузить с aws порядка трех петабайт данных

и

Чтобы не хранить и не пробегать по всей истории, каждый раз когда делаешь бакап

неактуальны.

убери из требований zip архив

В требованиях такого нет.

[rPman]

да еще хорошо бы зазиппованный архив

[Ромзес Панагиотис]

rPman, да, упустил.

[Ромзес Панагиотис]

По-моему, версионность в zip архивах - это архаизм.

[Vitaly Karasik]

UPDATE: большое спасибо всем ответившим! Вы заставили меня подумать, и я понял, что надо использовать S3 versioning and replication, вместо того чтобы изобретать велосипед со скриптами и cronjobs.

[rPman]

Vitaly Karasik, не забудь посчитать по тарифам компании сколько будет стоить бакап, поддержание и восстановление