Стратегия резервного копирования Amazon EC2
У меня есть пара настроек веб-сервера / сервера БД с использованием Amazon EC2. В настоящее время я делаю ежедневные снимки всей моей системы и дисков EBS, которые содержат все мои файлы приложений, файлы БД, исходный код и резервные копии БД. У меня есть консольное приложение, которое запускает создание резервных копий по расписанию. Мои изображения являются изображениями EBS.
Я работаю над заданием, которое снимает мои снимки через столько дней. Я предполагаю, что мой вопрос заключается в следующем: должен ли я / я также запланировать полное задание изображения /EBS? Таким образом, если сервер выходит из строя или поврежден, я могу просто запустить последний образ, а затем применить последний снимок.
Поскольку я работаю над своей стратегией резервного копирования, я использую Jungle Disc для резервного копирования дисков с данными.
3 ответа
Мои рекомендации:
Всегда документируйте и / или создавайте сценарии настройки каждого нового экземпляра, чтобы можно было воспроизвести установку программного обеспечения и конфигурацию системы в случае потери экземпляра. Проверьте это, запустив новый экземпляр и выполнив процедуру. Вы можете использовать пользовательский частный AMI, если установка занимает много времени и вам нужно быстро запускать экземпляры, но сам AMI должен быть построен с использованием документированной и / или скриптовой процедуры.
Храните важные данные на отдельном томе EBS, а не на корневом томе EBS. Это имеет много преимуществ, в том числе упрощение переноса данных на новые экземпляры (например, на основе разных AMI) и упрощение получения копий ваших данных в других экземплярах (например, со снимками и новыми томами).
Создавайте регулярные снимки томов данных EBS. Если это возможно / применимо, используйте такой инструмент, как мой ec2-compatibility-snapshot, чтобы повысить вероятность того, что вы делаете снимок согласованной файловой системы / базы данных. Выполните резервное копирование данных вне AWS/EC2, поскольку ваша учетная запись AWS является единственной точкой отказа.
Время от времени создавайте снимки корневого тома EBS в важных экземплярах. Хотя это может помочь вам в случае сбоя экземпляра или тома EBS, эта часть не так критична из-за № 1 и № 2 выше. Основная причина, по которой я это делаю, заключается в том, что создание моментальных снимков снижает риск сбоя самого корневого тома EBS.
Частота отказов тома EBS напрямую связана с количеством блоков, которые были изменены в этом томе с момента последнего снимка EBS.
Должен ли я / я также запланировать полный образ / задачу EBS?
да, это желательно. Однажды это спасло меня, потому что мне приходилось много раз сбрасывать из-за проблем с ядром, пока загрузочный диск больше не был читаем, и я просто загрузился с последнего снимка.
Если вам интересно, я написал класс Java, чтобы сделать снимок всех подключенных томов EBS, а также удалить их через определенное время. В настоящее время я делаю резервное копирование каждую неделю, а через две недели отказываюсь от третьего.
Он выполняет только одно действие за цикл, например, снимает или удаляет снимок, потому что он должен помещаться в cron ежечасно, чтобы избежать перегрузки десятками снимков одновременно, если у вас много EBS, как и у меня.
Мы используем простую, но мощную стратегию резервного копирования: создайте новый AMI на основе запуска экземпляров EC2 EBS два раза в день и удалите "старые" AMI. С помощью API (CreateImage) вы можете установить флажок не перезагружать экземпляр при создании нового AMI или, если вы используете программный raid - ssh для экземпляра перед вызовом API CreateIImage, и заморозить файловую систему с помощью "fsfreeze" в большинстве популярных файловых систем на новых ядрах или xfs_freeze, если Вы используете старое ядро и XFS.
Созданный "резервный" AMI запоминает все подключенные к исходным дискам EBS запущенных экземпляров (по ссылкам на созданные моментальные снимки) и, в случае использования программных рейдов с несколькими дисками, позволяет восстановить новый экземпляр в любом АЗ просто с помощью одного вызова API или через Интернет. -интерфейс.