Назад | Перейти на главную страницу

Стратегии резервного копирования AWS S3 - как мне подойти к резервному копированию корзин S3?

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

Меня больше всего беспокоит использование ключей API на сервере и то, как неавторизованный человек может каким-либо образом использовать сервер, получить ключи и использовать их для уничтожения всех данных в корзинах S3.

  1. Какие стратегии мне следует применить, чтобы свести к минимуму возможное раскрытие моих ключей API?
  2. Каков был бы надежный подход к резервному копированию террабайтов ресурсов S3 с учетом ограниченного бюджета?

Первое, что приходит в голову, это то, что передача данных в S3 и из S3 довольно затратна. Если вы выполняете резервное копирование часто (как и должно быть), затраты могут выйти из-под контроля только с комиссией за перевод. Тем не менее, чтобы ответить на ваш вопрос, резервное копирование должно выполняться с отдельного защищенного сервера, единственная задача которого в жизни - выполнять резервное копирование. Никакого apache, удаленный доступ только через SSH с аутентификацией по ключу и т. Д. Если вы сделаете это и убедитесь, что только несколько избранных людей имеют доступ к серверу, ваши ключи должны быть в полной безопасности. Если ты действительно параноик, вы можете pgp-encrypt файл, содержащий ваши ключи - однако проблема с этим подходом заключается в том, что он требует, чтобы вы вводили кодовую фразу при каждом запуске задания резервного копирования. Вероятно, это не то, на что вы хотите подписаться, верно?

Услышав о вашем ограниченном бюджете, я не могу не думать, что вам лучше изменить свою стратегию хранения. Я не уверен, какова ситуация с вашим сервером, но не могли бы вы разместить файлы локально на сервере, а затем просто использовать S3 для резервного копирования? Есть отличный скрипт резервного копирования под названием двуличие которые могут выполнять сжатые, зашифрованные, инкрементные резервные копии на S3 (среди нескольких других типов внутреннего хранилища).

[Edit] Если вы закончите хостинг на S3 и сделаете резервную копию на локальный диск, похоже, что есть «If-Modified-Since» заголовок в S3 API, который поможет выполнять инкрементное резервное копирование. Для таких резервных копий вам, скорее всего, понадобится что-то домашнее, хотя это не будет слишком сложно. Просто используйте SimpleDB / BerleleyDB / etc для хранения метаинформации о файлах, для которых вы создали резервную копию, вместе с указателем на их место на диске. Хранение метаинформации в БД также позволит быстро выполнить проверку резервных копий, а также создание отчетов о заданиях резервного копирования.

Даже у меня была такая же проблема, я написал простой сценарий bash, чтобы сделать это за меня, но я отлично работаю в одном регионе, он не работает с несколькими регионами, вот сценарий http://geekospace.com/back-up-and-restore-the-database-between-two-aws-ec2-instances/