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

Мне нужен совет или рекомендации по резервному копированию корзины 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? Хочу услышать ваше мнение.
Полезные ссылки:


person Sergey Alekseev    schedule 24.07.2013    source источник
comment
Примите stackoverflow.com/a/40033265/1586965   -  person samthebest    schedule 12.01.2020


Ответы (8)


Первоначально опубликовано в моем блоге: 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://your-bucket-name /home/ubuntu/s3/your-bucket-name/

Преимущества:

  • Масштабируемость - поддерживает огромные ведра 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 configure

aws configure

Подготовка

Подготовим локальный каталог резервного копирования 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 the current date and time

echo '-----------------------------'
date
echo '-----------------------------'
echo ''

# Echo script initialization
echo 'Syncing remote S3 bucket...'

# Actually run the sync command (replace {BUCKET_NAME} with your S3 bucket name)
/usr/bin/aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

# Echo script completion
echo 'Sync complete'

Не забудьте заменить {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 output

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

$ crontab -e

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

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

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

m h  dom mon dow   command

Следующая команда настраивает 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, следуя этому руководству < / а>.

person Elad Nava    schedule 03.10.2015
comment
Я оставил вопрос в вашем блоге, но мне интересно, есть ли способ синхронизировать метаданные? - person Devology Ltd; 17.05.2018
comment
@Devology Ltd, К сожалению, мне не довелось поработать с метаданными объекта S3. Судя по быстрому поиску в Google, не похоже, что awscli поддерживает автоматическую синхронизацию в команде aws s3 sync. Похоже, вам, возможно, придется реализовать это вручную. - person Elad Nava; 18.05.2018
comment
Спасибо, @Ekad Nava - я ценю, что вы подтвердили то, что, как я считал, так и есть. - person Devology Ltd; 18.05.2018
comment
Это фантастика, @EladNava, спасибо за то, что поделился, все еще актуально в 2020 году! - person user1130176; 17.01.2020
comment
этот ответ не подходит, когда у вас есть миллионы файлов. Это становится очень дорогим, медленным, а иногда и невозможным - из-за ограничений файловой системы. - person Psychozoic; 14.05.2020
comment
@Psychozoic, если вы выбираете файловую систему с настраиваемым ограничением inode (например, ext4) и можете предоставить достаточно большой размер тома EBS, возможно резервное копирование любого количества / размера файлов, но это действительно может стать дорогостоящим. Вам не обязательно выполнять синхронизацию с сервером EC2, вместо этого вы можете синхронизироваться с локальным компьютером. Но вы всегда будете платить за полосу пропускания AWS. - person Elad Nava; 15.05.2020

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

person Viccari    schedule 24.07.2013
comment
@SergeyAlekseev Если Glacier - это то, что вам подойдет, очень быстро настроить правило жизненного цикла для ведра, которое автоматически архивирует ваши файлы в ледник. Они по-прежнему будут отображаться в корзине (в веб-интерфейсе), но класс хранилища изменится со стандартного на ледниковый. Я перемещаю обработанные файлы из своей основной корзины в готовую, а в готовой корзине есть правило жизненного цикла, которое архивирует все, что старше 1 дня. Это файлы данных, к которым я, вероятно, никогда больше не прикоснусь, но их нужно сохранить для клиента. - person Dan; 26.07.2013
comment
Я не думаю, что 99.999999999% - достаточная причина для использования полного стека aws при хранении / резервном копировании. Я не говорю об оставшихся 0,0000000001%, но более того, если происходит что-то очень неожиданное, неловко, когда весь ваш бизнес где-то лежит. Неожиданно это может быть война США с конкретной страной, полный взлом Amazon (см. Sony) и т. Д. И т. Д. - person Augustin Riedinger; 04.03.2015
comment
Я вернусь к @AugustinRiedinger по этому поводу: проблема S3 может быть по определению чем-то, чего вы не знаете (например, правительственными проблемами), что может опровергнуть гипотезы, на которых основаны номера SLA S3, такие как 99,99 ... Если вы делаете что-либо в долгосрочной перспективе, включая резервное копирование данных, диверсификация является хорошей практикой, если не обязательным условием. - person lajarre; 04.03.2015
comment
Я определенно согласен с тем, что ваши баллы действительны. Но, исходя из вариантов, предоставленных OP (почти все из них, включая альтернативы AWS проблеме), я не думаю, что проблема S3 будет такой же широкой, как вы, ребята, расширяетесь. Тем не менее, приятно видеть некоторые более широкие мысли. - person Viccari; 04.03.2015
comment
Отличные и действенные предложения по вариантам резервного копирования. Однако, как указал Виккари в своем ответе, проблема №1 не должна иметь силы из-за высокой прочности. Чтобы избежать удаления файлов (проблема №2), вам следует правильно настроить AWS Identity and Access Management, чтобы у пользователей не было разрешений на удаление чего-либо важного. Если вы боитесь, что что-то случайно будет удалено, решение не в том, что вы дублируете данные, а в том, чтобы защитить данные от случайного удаления IMO. - person user2124655; 17.02.2016
comment
Старый ответ, но мне кажется, что мне нужно упомянуть недавние (-истые) события. В тот день, когда Amazon взломал Интернет, технический специалист случайно удалил огромную часть своих серверов S3. Даже в течение этих 24 часов проблема была в доступности. Не потеря данных. Абсолютно никакой потери данных не было, даже с учетом удаленного большого количества серверов, и им все же удалось выполнить условия своего SLA. - person Oberst; 05.07.2017
comment
№1 по-прежнему является потенциальной проблемой (проблема s3). Я видел, как взаимодействие с S3 завершалось неудачно из-за ошибок в инструментах - например, я видел, как инструмент aws cli не мог скопировать все соответствующие файлы с помощью команды «синхронизировать». Это соответствует духу ошибки №1, которая на самом деле является проблемой на стороне AWS, не зависящей от меня, а не проблемой, связанной с долговечностью S3. - person vacri; 20.03.2019
comment
@Viccari AWS говорит: Как и в любой другой среде, лучше всего иметь резервного копирования и защиты от злонамеренного или случайного удаления. Для данных S3 эта передовая практика включает в себя безопасные разрешения доступа, межрегиональную репликацию, управление версиями и работающее, регулярно тестируемое резервное копирование. Самая важная часть: ... иметь резервную копию и создать ее .... Для меня это означает, что у вас должна быть резервная копия и вы можете также поставить на место ... Итог: я бы не отбрасывал озабоченность №1. - person rsl; 12.09.2019
comment
@rsl Совершенно верно, но только что упомянутая вами рекомендация касается злонамеренного или случайного удаления. Это не похоже на проблему S3, как говорится в исходном вопросе, на что и направлен мой ответ. - person Viccari; 14.09.2019
comment
@Viccari Я понимаю вашу точку зрения. Это зависит от того, считаете ли вы, что существует 0% вероятность того, что S3 может случайно удалить некоторые из ваших объектов. Это определенно сделало бы это проблемой S3, и вы были бы очень грустным человеком, так как вас предупредили (см. Мой предыдущий комментарий). Во всяком случае, я продолжаю комментировать это с одной стороны - из вашего исходного ответа я чувствую, что вы не поощряете резервное копирование (также как и управление версиями). Я убежден в обратном, и AWS говорит то же самое. - person rsl; 15.09.2019
comment
Извините, если это натолкнулось на это. Я думаю, что резервное копирование необходимо по нескольким причинам, но я бы не подумал, что проблема с S3 находится в верхней части списка причин. Кроме того, этому ответу сейчас 6 лет, может быть, время показало, что я ошибаюсь? :) - person Viccari; 16.09.2019

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

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

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

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

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

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

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

person Varun    schedule 07.11.2014
comment
@David: Как Дэвид предложил в своем решении ниже, что может быть скрипт, который выполняет резервное копирование корзины s3 ежедневно или еженедельно. Этого можно легко достичь с помощью моей первой точки (AWS datapipeline - которая дает вам возможность планировать процесс резервного копирования - ежедневно , еженедельно и т. д.). Я бы порекомендовал поискать на aws datapipeline. - person Varun; 12.01.2015
comment
Это выглядит многообещающе, поскольку не полагается на устаревшие подходы, которые не позволяют максимально эффективно использовать облако (читайте: crons). Data Pipeline также имеет автоматические повторы и является управляемой (бессерверной) службой. - person Felipe Alvarez; 01.06.2020
comment
Такое резервное копирование не поможет, если S3 станет недоступным. Редко, но бывает. - person fjsj; 25.06.2021

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

person Adrian Teh    schedule 14.10.2016
comment
Что если вы удалите файл в одном регионе, он не должен реплицироваться в другом? - person michelem; 03.05.2020
comment
S3 не реплицирует удаления, проверьте эту ссылку docs.aws.amazon.com/AmazonS3/latest/dev/. - person ᐅdevrimbaris; 21.05.2020

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

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

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

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

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

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

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

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

Вот более подробная запись в блоге по этой теме. .

person user1590603    schedule 16.06.2018

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

person Ankit Kumar Rajpoot    schedule 23.11.2019
comment
Я собираюсь переместить около 7 ТБ в ведро и пытаюсь найти лучший вариант ... Я думаю, мне нужно что-то получше, чем синхронизация. Мне интересно, может ли использование конвейера для копирования данных в версию ледника GCS обеспечить лучшую общую безопасность? - person Brendon Whateley; 01.05.2020
comment
AWS DataSync может быть здесь вариантом. - person Felipe Alvarez; 01.06.2020

Поскольку эта тема была создана давно и актуальна до сих пор, вот несколько обновленных новостей:

Внешнее резервное копирование

Ничего не изменилось, вы по-прежнему можете использовать интерфейс командной строки или любой другой инструмент для планирования копирования в другом месте (в AWS или за его пределами).

Для этого есть инструменты, и предыдущие ответы были очень конкретными.

Внутреннее резервное копирование

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

Пример возможной конфигурации при удалении файла:

  1. Файл отмечен как удаленный (все еще доступен, но невидим для обычных операций)
  2. Файл перемещен в Glacier через 7 дней
  3. Файл удален через 30 дней

Сначала вам нужно активировать управление версиями и перейти к настройке жизненного цикла. Довольно прямолинейно: только предыдущие версии и удаление - это то, что вам нужно. Панель жизненного цикла S3

Затем определите свою политику. Вы можете добавить столько действий, сколько захотите (но каждый переход будет вам платным). Хранить в Glacier меньше 30 дней нельзя. Панель действий жизненного цикла S3

person Clément Duveau    schedule 26.01.2021