Стратегии резервного копирования для корзины AWS S3


92

Я ищу совет или передовой опыт для резервного копирования корзины 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? Хочу услышать ваше мнение.
Некоторые полезные ссылки:


Пожалуйста, примите stackoverflow.com/a/40033265/1586965
samthebest

Ответы:


63

Первоначально опубликовано в моем блоге: 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.

AWSCLI

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

$ 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 настроить

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

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

вывод 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, следуя этому руководству .


Я оставил вопрос в вашем блоге, но мне интересно, есть ли способ синхронизировать метаданные?
Devology Ltd

@Devology Ltd, К сожалению, мне не довелось поработать с метаданными объекта S3. Судя по быстрому поиску в Google, не похоже, что awscliподдержка автоматически синхронизирует это в aws s3 syncкоманде. Похоже, вам придется реализовать это вручную.
Элад Нава

Спасибо, @Ekad Nava - я признателен, что вы подтвердили то, что я считал именно так.
Devology Ltd

1
Это фантастика, @EladNava, спасибо за то, что поделился, все еще актуально в 2020 году!
user1130176

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

30

Принимая во внимание связанную ссылку, в которой объясняется, что 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, пожалуйста, забудьте об этом).


4
@SergeyAlekseev Если Glacier - это то, что вам подходит, очень быстро настроить правило жизненного цикла для ведра, которое автоматически архивирует ваши файлы в glacier. Они по-прежнему будут отображаться в корзине (в веб-интерфейсе), но класс хранилища изменится со стандартного на ледниковый. Я перемещаю обработанные файлы из своей основной корзины в корзину «готовой», и в этой корзине есть правило жизненного цикла, которое архивирует все, что старше 1 дня. Это файлы данных, к которым я, вероятно, никогда больше не прикоснусь, но их нужно сохранить для клиента.
Дэн

28
Я не думаю, что 99.999999999% - достаточная причина для использования полного стека aws при хранении / резервном копировании. Я не говорю об оставшихся 0,0000000001%, но более того, если происходит что-то весьма неожиданное, будет неловко держать где-то весь ваш бизнес. Совершенно неожиданно, это может быть война США с конкретной страной, полностью взломанный Amazon (см. Sony) и т. Д. И т. Д.
Августин Ридингер,

11
Я вернусь к @AugustinRiedinger по этому поводу: "проблема S3" по определению может быть чем-то, чего вы не знаете (например, правительственными проблемами), что может опровергнуть гипотезы, на которых основаны номера SLA S3, такие как 99.99 ... Делая что-либо в долгосрочной перспективе, включая резервное копирование данных, диверсификация является хорошей практикой, если не обязательным условием
lajarre

2
Я определенно согласен с тем, что ваши баллы действительны. Но, исходя из вариантов, предоставленных OP (почти все из них, включая альтернативы AWS проблеме), я не думаю, что «проблема S3» будет такой же широкой, как вы, ребята, расширяетесь. Тем не менее, приятно видеть некоторые более широкие мысли.
Viccari, 04

4
Старый ответ, но я чувствую, что мне нужно упомянуть недавние (-ишние) события. «В тот день, когда Amazon сломал Интернет», технический специалист случайно удалил огромную часть своих серверов S3. Даже в течение этих 24 часов проблема была в доступности. Не потеря данных. Абсолютно никакой потери данных не было, даже с учетом того, что было удалено большое количество серверов, и им все же удалось хорошо выполнить свое SLA
Оберст

14

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

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

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

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

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

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

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


@David: Как Дэвид предложил в своем решении ниже, что может быть сценарий, который выполняет резервное копирование ведра s3 ежедневно или еженедельно. Этого можно легко достичь с помощью моей первой точки (AWS datapipeline - которая дает вам возможность планировать процесс резервного копирования - ежедневно , еженедельно и т. д.). Я бы порекомендовал посмотреть на aws datapipeline.
Варун

Это выглядит многообещающе, поскольку не полагается на устаревшие подходы, которые не позволяют максимально эффективно использовать облако (читайте: crons). Data Pipeline также имеет автоматические повторы и является управляемой (бессерверной) службой.
Фелипе Альварес,

13

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


Что если вы удалите файл в одном регионе, он не должен реплицироваться в другом?
michelem

S3 не реплицирует удаления, проверьте эту ссылку docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

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

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

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


Согласовано. Интересно, что когда вы копаетесь в S3 (даже CRR - встроенный в репликацию), там есть большие дыры для аварийного восстановления. Вы не можете, например, когда-либо восстановить корзину, истории версий файлов, метаданные (особенно даты последнего изменения) и т. Д. Все доступные в настоящее время сценарии восстановления являются частичными.
Paul Jowett

7

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

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

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

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

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


0

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


Я собираюсь переместить около 7 ТБ в ведро и пытаюсь найти лучший вариант ... Я думаю, мне нужно что-то получше, чем синхронизация. Мне интересно, может ли использование конвейера для копирования данных в версию ледника GCS обеспечить лучшую общую безопасность?
Брендон Уэйтли

AWS DataSync может быть здесь вариантом.
Фелипе Альварес,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.