Как сделать резервную копию AWS S3 Bucket без контроля версий исходного хранилища [закрыто]

Есть ли способ восстановиться после случайного удаления Amazon S3 Bucket?

У нас есть критическая информация в наших корзинах, и мне нужно уменьшить риск случайного или злонамеренного удаления самой корзины.

Я знаю, что могу синхронизировать всю корзину локально, но это не слишком удобно, если размер моей корзины составляет 100 ГБ.

Есть идеи по резервному копированию?

Другой подход заключается в том, чтобы включить поддержку версий S3 в вашем ведре. Затем вы можете восстановить удаленные файлы и т. Д. См. Документацию S3, чтобы узнать, как включить эту функцию.

Использование сторонних инструментов, таких как BucketExplorer, делает работу с версиями довольно простой (против непосредственного вызова API).

Вы также можете включить удаление многофакторной аутентификации для своих корзин S3, что немного усложнит случайное удаление;)

Подробнее о многофакторной аутентификации Удалить
больше при удалении объектов

Вы можете использовать s3cmd http://s3tools.org/s3cmd

Таким образом, для резервного копирования ведро называется mybucket

s3cmd mb s3://mybucket_backup
s3cmd --recursive cp s3://mybucket s3://mybucket_backup

Это не дешевое решение, но если ваши корзины действительно важны, вот как вы это делаете: загружайте экземпляр Amazon EC2 и периодически синхронизируйте его содержимое.

Amazon EC2 является их провайдером виртуализации. Вы можете раскрутить экземпляры Linux, Windows и т. Д. И запускать все, что захотите. Вы платите за час, и вы получаете довольно большое место для хранения локально для этого сервера. Например, я использую экземпляр «большого» размера, который поставляется с 850 ГБ локального дискового пространства.

Самое интересное, что он находится в той же сети, что и S3, и вы получаете неограниченные переводы между S3 и EC2. Я использую программное обеспечение Jungle Disk за 20 долларов на экземпляре Windows EC2, которое позволяет мне получить доступ к моим корзинам S3, как если бы они были папками локального диска. Затем я могу сделать запланированные командные файлы, чтобы скопировать материал из S3 и на мое локальное дисковое пространство EC2. Вы можете автоматизировать его, чтобы хранить почасовые резервные копии, если хотите, или если вы хотите играть в азартные игры, настроить JungleDisk (или его эквиваленты в Linux) для синхронизации один раз в час или около того. Если кто-то удаляет файл, у вас есть хотя бы несколько минут, чтобы вернуть его из EC2. Я бы порекомендовал делать регулярные резервные копии по сценарию - легко сохранять резервные копии в течение нескольких дней, если вы сжимаете их на том объемом 850 ГБ.

Это действительно полезно для доставки журналов SQL Server, но я также вижу, как это будет способствовать достижению вашей цели.

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

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

Другое возможное решение - скопировать ваше ведро в зону Европы в S3. Это может сохраниться после вашего случайного удаления достаточно долго для восстановления.

Чтобы немного изменить ответ Брента (отлично); вам не нужно поддерживать работу экземпляра. Создайте EC2 AMI, который извлекает ваши данные, синхронизирует их с томом EBS, снимает этот том и выключает себя.

Вы также можете поддерживать том в рабочем состоянии, но для резервного копирования его снимка должно быть достаточно. Если ваш пользовательский AMI делает все это (включая отключение после того, как это сделано) без взаимодействия, тогда вашему скрипту 'backup' нужно просто 'ec2run -n 1 -t m1.small ami-' и запустить и забыть.