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