Я ищу совет или передовой опыт для резервного копирования корзины S3.
Резервное копирование данных из S3 предназначено для предотвращения потери данных по следующим причинам:

1. S3 проблема
2. проблема, когда я случайно удаляю эти данные из S3

После некоторого расследования я вижу следующие варианты:

1. Используйте управление версиями http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
2. Копирование из одной корзины S3 в другую с помощью AWS SDK
3. Резервное копирование в Amazon Glacier http://aws.amazon.com/en/glacier/
4. Резервное копирование на рабочий сервер, для которого создается резервная копия.

Какой вариант выбрать и насколько безопасно хранить данные только на S3? Хочу услышать ваше мнение.
Некоторые полезные ссылки:

• Документация по защите данных
• Часто задаваемые вопросы о защите данных

Первоначально опубликовано в моем блоге: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Периодически синхронизируйте сегмент S3 с сервером EC2

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

s3cmd
Сначала s3cmdвыглядело очень многообещающе. Однако после того, как я попробовал его на моем огромном ведре S3, он не смог масштабироваться, из-за ошибки Segmentation fault. Тем не менее, он отлично работал с небольшими ведрами. Поскольку это не сработало для огромных ведер, я решил найти альтернативу.

s4cmd
Более новая, многопоточная альтернатива s3cmd. Это выглядело даже более многообещающе, однако я заметил, что он продолжал повторно загружать файлы, которые уже присутствовали в локальной файловой системе. Это не то поведение, которого я ожидал от команды синхронизации. Он должен проверить, существует ли удаленный файл локально (проверка хэша / размера файла будет аккуратной), и пропустить его при следующем запуске синхронизации в том же целевом каталоге. Я открыл проблему ( bloomreach / s4cmd / # 46 ), чтобы сообщить об этом странном поведении. А пока я решил найти другую альтернативу.

awscli
И тут я нашел awscli. Это официальный интерфейс командной строки Amazon для взаимодействия с различными облачными сервисами, включая S3.

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

$ aws s3 sync s3: // имя-вашего-ведра / home / ubuntu / s3 / имя-вашего-ведра /

Льготы:

• Масштабируемость - поддерживает огромные ведра S3
• Многопоточность - быстрее синхронизирует файлы за счет использования нескольких потоков.
• Умный - синхронизирует только новые или обновленные файлы
• Быстро - благодаря многопоточности и интеллектуальному алгоритму синхронизации

Случайное удаление

Удобно, что syncкоманда не удаляет файлы в папке назначения (локальной файловой системе), если они отсутствуют в источнике (корзина S3), и наоборот. Это идеально подходит для резервного копирования S3 - в случае удаления файлов из корзины, повторная синхронизация не удалит их локально. И если вы удалите локальный файл, он также не будет удален из исходного сегмента.

Настройка awscli в Ubuntu 14.04 LTS

Начнем с установки awscli. Есть несколько способов сделать это, однако мне показалось, что проще всего установить его через apt-get.

$ sudo apt-get install awscli

Конфигурация

Затем нам нужно настроить awscliс помощью нашего идентификатора ключа доступа и секретного ключа, которые вы должны получить от IAM , создав пользователя и присоединив политику AmazonS3ReadOnlyAccess . Это также помешает вам или любому, кто получает доступ к этим учетным данным, удалить ваши файлы S3. Обязательно введите свой регион S3, например us-east-1.

$ aws настроить

Подготовка

Подготовим локальный каталог резервного копирования S3, желательно в формате /home/ubuntu/s3/{BUCKET_NAME}. Обязательно замените {BUCKET_NAME}свое настоящее имя сегмента.

$ mkdir -p / home / ubuntu / s3 / {BUCKET_NAME}.

Начальная синхронизация

Давайте продолжим и синхронизируем ведро в первый раз с помощью следующей команды:

$ aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

Предполагая, что корзина существует, учетные данные и регион AWS верны, а целевая папка действительна, awscliначнется загрузка всей корзины в локальную файловую систему.

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

Настройка Cron Job

Идите вперед и создайте sync.shфайл в /home/ubuntu/s3:

$ nano /home/ubuntu/s3/sync.sh

Скопируйте и вставьте следующий код в sync.sh:

#! / bin / sh

# Отображение текущей даты и времени

эхо '-----------------------------'
Дата
эхо '-----------------------------'
эхо ''

# Инициализация эхо-скрипта
echo 'Синхронизация удаленного сегмента S3 ...'

# Фактически запустите команду синхронизации (замените {BUCKET_NAME} на имя вашей корзины S3)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Завершение эхо-скрипта
echo "Синхронизация завершена"

Не забудьте заменить {BUCKET_NAME} на имя вашего сегмента S3 дважды на протяжении всего сценария.

Совет от профессионалов: вы должны использовать /usr/bin/awsссылку на awsдвоичный файл, так как crontabвыполняет команды в ограниченной среде оболочки и не сможет найти исполняемый файл самостоятельно.

Затем убедитесь, что chmodскрипт может быть выполнен crontab.

$ sudo chmod + x /home/ubuntu/s3/sync.sh

Давайте попробуем запустить скрипт, чтобы убедиться, что он действительно работает:

$ /home/ubuntu/s3/sync.sh

Результат должен быть похож на этот:

Затем давайте отредактируем текущего пользователя, crontabвыполнив следующую команду:

$ crontab -e

Если это ваш первый запуск crontab -e, вам необходимо выбрать предпочтительный редактор. Рекомендую выбрать, так nanoкак с ним проще всего работать новичкам.

Частота синхронизации

Нам нужно указать, crontabкак часто запускать наш сценарий и где он находится в локальной файловой системе, написав команду. Формат этой команды следующий:

mh dom mon dow команда

Следующая команда настраивает crontabзапуск sync.shсценария каждый час (задается параметрами минута: 0 и час: *) и направляет выходные данные сценария в sync.logфайл в нашем s3каталоге:

0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log

Вы должны добавить эту строку в конец crontabредактируемого файла. Затем сохраните файл на диск, нажав Ctrl + W, а затем Enter . После этого вы можете выйти nano, нажав Ctrl + X . crontabтеперь будет запускать задачу синхронизации каждый час.

Совет от профессионала: вы можете убедиться, что ежечасное задание cron выполняется успешно /home/ubuntu/s3/sync.log, проверив его содержимое на предмет даты и времени выполнения и проверив журналы, чтобы увидеть, какие новые файлы были синхронизированы.

Все готово! Теперь ваша корзина S3 будет автоматически синхронизироваться с вашим сервером EC2 каждый час, и все будет в порядке. Обратите внимание, что со временем, когда ваша корзина S3 станет больше, вам, возможно, придется увеличить размер тома EBS вашего сервера EC2, чтобы разместить новые файлы. Вы всегда можете увеличить размер тома EBS, следуя этому руководству .

Принимая во внимание связанную ссылку, в которой объясняется, что S3 имеет надежность 99,999999999%, я бы отбросил ваше беспокойство №1. Шутки в сторону.

Теперь, если № 2 является допустимым вариантом использования и вызывает у вас реальную озабоченность, я бы определенно остановился на вариантах № 1 или № 3. Какой из них? Это действительно зависит от некоторых вопросов:

• Нужны ли вам какие-либо другие функции управления версиями или только для предотвращения случайной перезаписи / удаления?
• Доступны ли дополнительные расходы, связанные с версией?
• Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Это нормально для тебя?

Если ваше хранилище не очень велико, я бы придерживался управления версиями. Таким образом, вам не понадобится дополнительный код / ​​рабочий процесс для резервного копирования данных в Glacier, в другие ведра или даже на любой другой сервер (что действительно плохой выбор, IMHO, пожалуйста, забудьте об этом).

Вы можете сделать резервную копию данных S3, используя следующие методы

1. Запланируйте процесс резервного копирования с помощью AWS datapipeline. Это можно сделать двумя способами, указанными ниже:

   а. Использование copyActivity для datapipeline, с помощью которого вы можете копировать из одного ведра s3 в другое ведро s3.

   б. Использование ShellActivity команд datapipeline и "S3distcp" для рекурсивного копирования рекурсивных папок s3 из корзины в другую (параллельно).

2. Используйте управление версиями внутри корзины S3 для поддержки разных версий данных

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

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

Как насчет использования легко доступной функции межрегиональной репликации в самих бакетах S3? Вот несколько полезных статей об этой функции

• https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/
• http://docs.aws.amazon.com/AmazonS3/latest/UG/cross-region-replication.html

Вы могли подумать, что сейчас есть более простой способ просто хранить какие-то инкрементные резервные копии в области различий.

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

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

Хотя этот вопрос был опубликован некоторое время назад, я подумал, что важно упомянуть защиту от удаления MFA с другими решениями. OP пытается решить проблему случайного удаления данных. Многофакторная аутентификация (MFA) здесь проявляется в двух разных сценариях:

1. Безвозвратное удаление версий объекта: разрешите удаление MFA для управления версиями корзины.

2. Случайное удаление самого сегмента. Настройте политику сегмента, запрещающую удаление без аутентификации MFA.

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

Вот сообщение в блоге по этой теме с более подробной информацией.

Если у нас слишком много данных. Если у вас уже есть ведро, тогда в первый раз синхронизация займет слишком много времени. В моем случае у меня было 400 ГБ. В первый раз это заняло 3 часа. Так что я думаю, что мы можем сделать реплику хорошим решением для резервного копирования S3 Bucket.