Резервное копирование и восстановление EC2 инстансов с помощью AWS Backup

Использование штатного функционала AWS для бэкапов довольно простое и, в то же время, функциональное. Однако, в нем есть некоторые неочевидные моменты, которые желательно знать перед тем, как отдать резервные копии на откуп AWS. В данной статье мы рассмотрим настройку Backup plan для EC2 инстансов и восстановление инстанса в случае необходимости.

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

Итак, чтобы крепче спать, не переживая о сохранности данных, мы заходим в консоль AWS и в поиске вводим AWS Backup, после чего переходим в него.

1. В первую очередь проверяем вкладку Vaults - это наши хранилища для бэкапов. По умолчанию там уже есть одно хранилище, Default - можно его и использовать. При необходимости, можно создать дополнительные хранилища - основная ситуация, когда это может потребоваться (помимо красивой и упорядоченной структуры) - необходимость разграничения доступов, т.к. каждый Vault является отдельной сущностью со своими правами на доступ к нему. Есть и другие причины, но мы на них сейчас задерживаться не будем.
2. После этого, идем настраивать сам план резервного копирования в Backup plans > Create backup plan. Тут, для наглядности, выбираем Build a new plan и начинаем настройку.
3. Backup plan name - имя плана резервного копирования. Лучше использовать что-то осмысленное.
4. Tags - при необходимости ставим нужные.
5. Далее, Backup rule name - тоже используем что-то осмысленное.
6. Backup vault - собственно, хранилище для тех бэкапов, которые этот план будет создавать.
7. Backup frequency - частота бэкапов. Помимо привычных daily, weekly, monthly есть возможность указать необходимую для вас частоту с помощью cron expression. Однако, не могу не упомянуть, что AWS cron по структуре немного отличается от привычного всем нам cron в unix системах. Впрочем, информацию об этом найти довольно легко.
8. Теперь настраиваем окно для бэкапов. Start time - время запуска плана. Однако, если вы укажете начало в 00:00 - это совсем не означает, что резервная копия начнет создаваться ровно в это время, потому что у нас есть следующий пункт.
9. Start within - тут мы указываем временной промежуток, в рамках которого и произойдет резервное копирование. Минимальное значение - 1 час, соответственно, в нашем кейсе задача на бэкап запустится в промежутке с 00:00 до 01:00.
10. Complete within - это время, за которое бэкап должен завершиться. Минимальное значение - 2 часа, и означает это что если backup rule не успеет за два часа сделать бэкап, то он будет помечен как неуспешный и задача отменяется до следующего раза. В большинстве случаев 2 часов более чем достаточно, но можно выставить побольше.
11. Point-in-time recovery - в нашем кейсе этот пункт мы не включаем, но в некоторых случаях очень полезный функционал.
12. Cold storage - имеет смысл при необходимости держать бэкапы более 90 дней для экономии на стоимости хранения резервных копий.
13. Total retention period - время, на протяжении которого будут храниться наши бэкапы.
14. Оставшиеся пункты меню опциональны и в нашем случае не нужны, нажимаем Create plan.
15. Далее, Resource assignment name. Опять же, лучше указать что-то осмысленное - prod, stage, websites.
16. IAM role - можно оставить роль по умолчанию. Отдельная роль нужна в более сложных кейсах, которые мы сегодня не рассматриваем.
17. Define resource selection. Тут оставляем Include all resource types, чтобы при необходимости использовать этот план на всё, что угодно.
18. Refine selection using tags - назначаем теги для плана. Это, пожалуй, самый удобный способ добавлять инстансы в план резервного копирования. Например, мы добавляем в теги env - Equals - prod и любой инстанс, которому мы проставим тег env - prod автоматически попадет под условия этого плана резервного копирования.
19. Нажимаем Assign resources и наш план готов.
20. И последнее, что нам нужно - проставить теги на те инстансы, которые мы хотим бэкапить этим планом. Просто переходим во вкладку EC2, выбираем нужный инстанс, вкладку Tags - Manage tags - Add new tag. В нашем примере мы указываем key - env, value - prod.

Вот и всё, этого достаточно для того, чтобы инстанс попал под условия плана резервного копирования.

Теперь же мы рассмотрим, как нам восстановить инстанс, бэкап которого мы настроили до этого.

Для этого мы, в первую очередь, открываем нужный инстанс в консоли AWS и запоминаем (а лучше записываем) два основных момента, которые нам в дальнейшем понадобятся - Instance ID и Public IPv4 address. Для случаев, когда ваш инстанс не использует внешний IP - достаточно будет ID.

1. Заходим в консоль AWS Backup
2. Там нам необходимо зайти во вкладку Protected resources и выбрать тот инстанс, который нам нужно восстановить.
3. Зайдя в необходимый инстанс, мы увидим там все существующие точки восстановления, в зависимости от того, какой срок хранения мы указали в backup rule.
4. Выбрав необходимый нам снапшот и нажав Restore, мы попадаем в меню восстановления. Здесь у нас по умолчанию уже выбраны все параметры инстанса as-is, т.е. ничего менять не нужно. За исключением случаев, если при восстановлении инстанса мы хотим попутно поменять какой-то из этих параметров. Но проверить эти параметры на соответствие существующему инстансу все-таки очень рекомендуется.
5. Далее, в Restore role выбираем Default role и обязательно ставим чекбокс на копирование тэгов, иначе можно забыть проставить нужный тэг на восстановленный инстанс.
6. В пункте Advanced settings можно всё оставить по умолчанию и нажать Restore backup. При этом запустится задача на восстановление бэкапа.
7. После того, как задача по восстановлению закончит работу, мы получим два идентичных сервера. Именно для этого мы запоминали ID нужного нам.
8. Теперь мы останавливаем либо удаляем совсем старый сервер. Я рекомендую все-таки сначала остановить, а удалять уже после того, как мы будем уверены, что он нам больше не нужен. После остановки старого сервера нам нужно присвоить его внешний ip адрес, на который настроены все DNS записи, новому серверу. Для этого мы идем в AWS EC2, пункт Elastic IPs и находим там нужный нам ip адрес и нажимаем Associate Elastic IP address. Там мы выставляем параметры следующим образом - в пункте Instance мы выбираем восстановленный инстанс, в Private IP address будет только один вариант, собственно, текущий внутренний адрес сервера. И обязательно ставим чекбокс в пункте Reassociation, т.к. мы будем переназначать уже привязанный адрес, а не только что созданный. После этого нажимаем Associate и через пару минут наш новый сервер, который мы восстановили из бэкапа, будет иметь внешний адрес старого сервера, что позволит нам сэкономить кучу времени на замене всех DNS записей. Разумеется, если ваш инстанс не использует внешний IP - этот пункт можно пропустить.
9. Ещё один опциональный пункт, который не совсем относится к теме нашей статьи, но упомянуть о нем все-таки стоит - если с этим сервером идет взаимодействие приложений по внутреннему IP адресу, то в этих приложениях нужно будет указать новый внутренний адрес, т.к. переназначить его, как в случае с внешним IP, нельзя.

Вот и всё, мы восстановили сервер из резервной копии, данные спасены, пользователи счастливы.

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, для достижения которых вам может понадобится наша экспертиза, просто напишите нам,

• client@softwarecats.dev,
• https://t.me/alex_zarubin,
• или через любую форму на сайте.

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