Стратегия резервного копирования Amazon EC2

У меня есть пара настроек веб-сервера / сервера БД с использованием Amazon EC2. В настоящее время я делаю ежедневные снимки всей моей системы и дисков EBS, которые содержат все мои файлы приложений, файлы БД, исходный код и резервные копии БД. У меня есть консольное приложение, которое запускает создание резервных копий по расписанию. Мои изображения являются изображениями EBS.

Я работаю над заданием, которое снимает мои снимки через столько дней. Я предполагаю, что мой вопрос заключается в следующем: должен ли я / я также запланировать полное задание изображения / EBS? Таким образом, если сервер выходит из строя или поврежден, я могу просто запустить последний образ, а затем применить последний снимок.

Поскольку я работаю над своей стратегией резервного копирования, я использую Jungle Disc для резервного копирования дисков с данными.

Мои рекомендации:

1. Всегда документируйте и / или пишите сценарии настройки каждого нового экземпляра, чтобы вы могли воспроизвести установку программного обеспечения и конфигурацию системы в случае потери экземпляра. Проверьте это, запустив новый экземпляр и выполнив процедуру. Вы можете использовать пользовательский частный AMI, если установка занимает много времени и вам нужно быстро запускать экземпляры, но сам AMI должен быть построен с использованием документированной и / или скриптовой процедуры.

2. Храните важные данные на отдельном томе EBS, а не на корневом томе EBS. Это имеет много преимуществ, в том числе упрощение переноса ваших данных на новые экземпляры (например, на основе разных AMI) и упрощение получения копий ваших данных в других экземплярах (например, со снимками и новыми томами).

3. Создавайте регулярные снимки томов данных EBS. Если возможно / применимо, используйте такой инструмент, как мой ec2-compatibility-snapshot, чтобы повысить вероятность того, что вы делаете снимок согласованной файловой системы / базы данных. Выполните резервное копирование данных вне AWS / EC2, поскольку ваша учетная запись AWS является единственной точкой отказа.

4. Время от времени создавайте снимки корневого тома EBS в важных экземплярах. Хотя это может помочь вам в случае сбоя экземпляра или тома EBS, эта часть не так критична из-за № 1 и № 2 выше. Основная причина, по которой я это делаю, заключается в том, что создание моментальных снимков снижает риск сбоя самого корневого тома EBS.

Частота отказов тома EBS напрямую связана с количеством блоков, которые были изменены в этом томе с момента последнего снимка EBS.

Должен ли я / я также запланировать полный образ / задачу EBS?

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

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

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Он выполняет только одно действие за цикл, например, снимает или удаляет снимок, потому что он должен помещаться в cron каждый час, чтобы избежать перегрузки десятками снимков одновременно, если у вас много EBS, как и у меня.

Мы используем простую, но мощную стратегию резервного копирования: создавайте новый AMI на основе запуска экземпляров EC2 EBS два раза в день и удаляйте «старые» AMI. С помощью API (CreateImage) вы можете установить флажок не перезагружать экземпляр при создании нового AMI или, если вы используете программный raid - ssh для экземпляра до вызова API CreateIImage, и заморозить файловую систему с помощью «fsfreeze» в большинстве популярных файловых систем на новых ядрах или xfs_freeze, если Вы используете старое ядро ​​и XFS.

Созданная «резервная копия» AMI запоминает все подключенные к исходным дискам EBS запущенных экземпляров (по ссылкам на созданные моментальные снимки) и, в случае использования программных рейдов с несколькими дисками, позволяет восстанавливать новый экземпляр в любом АЗ просто с помощью одного вызова API или через Интернет. -интерфейс.