Мы начинаем проект, который предполагает хранение больших объемов данных в S3. S3 хорошо масштабируется, и мы ожидаем, что в корзине будет до 5 ТБ и миллиона файлов. Хотя я могу доверять Amazon в хранении данных, я действительно не думаю, что в программном обеспечении не может быть абсолютно никаких ошибок.
У нас есть механизм EBS-снапшотов, чтобы можно было восстановить состояние EBS-тома до его предыдущего состояния. Но как мы можем вернуть ведро в его состояние, скажем, за 3 дня до этого?
UPD.
Вопрос вызвал совершенно новые мысли о том, как сделать резервную копию своего весь облачная инфраструктура? Какой у вас план аварийного восстановления? »Как сделать резервную копию Route53? Настройки CloudFront? Сколько времени потребуется для восстановления после ошибки скрипта или потери доступа к корневой консоли?
В зависимости от того, какие данные вы храните, вас может не интересовать резервное копирование данных из S3. Например, если у вас есть общие ресурсы веб-сайта, копии которых у вас уже есть в репозитории в другом месте, вам, вероятно, не нужно делать резервные копии ресурсов, которые находятся в S3.
Иногда вы можете использовать S3 для хранения пользовательских загрузок. Они могли исходить из EC2 или могли попасть прямо в S3. Имеет смысл использовать управление версиями объектов, чтобы иметь возможность восстанавливаться после ошибок сценария или пользователей, удаляющих файлы, но передумавших. http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html
Насколько я понимаю, управление версиями осуществляется на уровне объекта, поэтому, если вы хотите «вернуться к тому, как ваша корзина выглядела 3 дня назад», вам нужно будет создать сценарий, который мог бы проверять все версии и даты и запрашивать правильную версию. для каждого объекта. Это можно было бы сделать, просто для этого сначала потребуется немного усилий на уровне приложения.
Вы можете изучить другие методы, такие как синхронизация всех объектов корзины S3 с другой службой (сторонним сервером или EC2 с поддержкой EBS). Это может быть ваш дневной или еженедельный снимок. Этот метод требует дополнительных затрат, обслуживания и усилий, поэтому может быть не лучшим решением, особенно для 5 ТБ данных.
В зависимости от того, как далеко вы хотите зайти, вся такая информация должна быть написана в сценариях и в файлах конфигурации. Для этих файлов конфигурации необходимо создать резервную копию. Это касается DEVOPS и концепции инфраструктуры как кода.
На этот вопрос сложно ответить. Что за ошибка скрипта? Первый вопрос касается одного примера (сценарий, удаляющий файл, который находится на S3), но есть еще много других.
Вы можете заглянуть в SimianArmy https://github.com/Netflix/SimianArmy
Simian Army - это набор инструментов, которые помогут вашему облаку работать в отличной форме. Chaos Monkey, первый член, представляет собой инструмент обеспечения отказоустойчивости, который помогает гарантировать, что ваши приложения могут выдерживать случайные сбои экземпляров.
Что касается доступа к «корневой консоли», если вы говорите о доступе к вашей ОС или к вашим EC2… все это должно быть написано через Puppet / Chef или подобное, и поэтому ваши машины «выбрасываются». В них нет ничего особенного, они не содержат индивидуальных данных пользователя, и вы можете включить или отключить их, не затрагивая вашу систему.
Если вы говорите о доступе к консоли AWS, вам нужно будет сделать такие вещи, как электронная почта или позвонить, чтобы получить доступ, или могут возникнуть перебои, которые вам нужно учитывать.