I've never sailed the Amazon,
I've never reached Brazil;
But the Don and Magdalena,
They can go there when they will!
Rudyard Kipling
С помощью облачного Amazon Relational Database Service (Amazon RDS) можно разворачивать базы данных и фокусироваться именно на работе с ними, не отвлекаясь на администрирование сервера или операционки. Сам вендор так и позиционирует эти облачные сервисы: “Amazon Relational Database Service (Amazon RDS) – это веб-сервис, который позволяет легко создавать, использовать и масштабировать реляционные базы данных в облаке. Он предоставляет экономичные масштабируемые ресурсы для стандартных реляционных БД и выполняет типовые задачи по администрированию баз данных.”
Для защиты данных, хранящихся на этих облачных инстансах, AWS умеет делать снимки состояния БД. А что если хочется реализовать разные политики хранения или выполнять репликацию этих снимков в другие учетные записи или другие регионы AWS Regions? С этими задачами справляется Veeam Backup for AWS.
Снапшоты как точки восстановления
Вот что делает Veeam Backup for AWS согласно настройкам политик бэкапа:
Во время бэкап-сессии он создает снапшот стораджа для каждого инстанса RDS, включенного в политику. Такие снапшоты являются независимыми точками восстановления для инстансов RDS.
Последовательные бэкап-сессии формируют цепочку из этих снапшотов: в ходе начальной сессии в нативный снапшот попадает инстанс целиком, а в ходе следующих сессий уже только измененные блоки.
При создании снапшота Veeam Backup for AWS назначает ему AWS-тэги, чьи ключи и значения содержат зашифрованные метаданные. Тэги, в частности, позволяют Veeam идентифицировать устаревшие снапшоты.
Если в настройках политики была включена репликация снапшотов, то Veeam Backup for AWS скопирует снапшот БД в выбранный регион AWS Region и в выбранную учетную запись. Плюс к этому, можно включить шифрование.
Примечание: Инстансы RDS на движке Amazon Aurora не поддерживаются .
В одну и ту же политику можно включить несколько инстансов RDS из разных регионов AWS Regions (но из одной и той же учетной записи AWS).
Кроме автоматизированного бэкапа, вы можете в любой момент сделать снимок состояния БД тут же, в консоли Veeam Backup for AWS. Поддерживаются еще и снапшоты, созданные AWS без участия Veeam - правда, для них будут доступны не все возможности восстановления.
Создание политики бэкапа
Создается новая политика с помощью визарда:
В консоли Veeam Backup for AWS выбираем Policies > RDS и нажимаем Add.
В консоли Veeam Backup for AWS выбираем Policies > RDS и нажимаем Add.
2. Задаем для новой политики имя - оно должно быть уникально и не превышать 255 символов в длину. Описание необязательно, но с ним как-то удобнее.
3. На шаге Sources идем в секцию IAM Role и там указываем роль, с чьими пермиссиями будет выполняться доступ к ресурсам и сервисам, а также создание нативных снимков. Можно выбрать роль из списка имеющихся или добавить в него нужную.
Полезно: Рекомендуется запустить автоматическую проверку пермиссий, кликнув Check permissions. Если выяснится, что каких-то пермиссий не хватает (они будут перечислены в поле Missing permissions), можно будет сразу их добавить - это удобно сделать в диалоге Grant permissions, который открывается по нажатию кнопки Grant.
4. Затем в секции Specify region кликаем Choose regions и формируем список нужных регионов, в конце не забываем нажать Apply:
5. После чего переходим к секции Resources и там указываем, с какими инстансами RDS будет работать наша политика.Сначала нажимаем Select resources to protect и выбираем, хотим ли мы бэкапить все инстансы (All resources) или только некоторые (Protect the following resources):
В первом случае Veeam Backup for AWS будет периодически (раз в день) делать рескан, проверяя, не появились ли новые инстансы в выбранных регионах - если таковые найдутся, то будут автоматически включены в эту политику резервного копирования. Впрочем, как правило, если у вас всё корректно настроено и работает, то любые изменения из инфраструктуры отображаются практически моментально.
Во втором случае вам нужно будет указать нужные инстансы вручную - тут тоже есть разные опции:
В списке Resource type можно выбрать вариант Tag - тогда будут бэкапиться только инстансы с определенным тэгом. (Соответственно, если, например, снять этот тэг с инстанса, то он перестанет бэкапиться.)
Можно воспользоваться полем поиска нужного ресурса.
Можно просто вывести весь список, кликнув Browse to select specific sources from the global list (тут, возможно, придется немного подождать, пока он будет построен; для ускорения процесса можно нажать Rescan) - и выбрать из него нужные ресурсы.
Примечание: Собственно, в первый раз, когда вы только выбрали регион, вы ничего еще не увидите в выпадающих списках ресурсов (так как в нашей базе никаких метаданых еще нет). То есть вышеупомянутые тэги вы выбрать тоже просто так не сможете. Нужно кликнуть Browse to select specific sources from the global list, таким образом инициировав запуск рескана и наполнение списка. Ну а в дальнейшем при создании политик для этого региона вы уже будете видеть актуальный список ресурсов.
После выбора нужных ресурсов надо нажать кнопку Protect.и убедиться, что выбранные инстансы и тэги занесены в список внизу окна.
Если хочется протектить большинство ресурсов - но не только лишь все - то можно выбрать All Resources и задать исключения (можно поступить аналогично и в варианте с тэгами).
Затем жмем Apply и переходим к следующему этапу.
6. На шаге Target можно настроить репликацию снапшотов БД в другие учетные записи или регионы AWS - для этого в секции Snapshots надо включить опцию Replicate snapshots. Затем в окошке Replication settings задаем настройки таргета для каждого сорса (выполняем маппинг между их регионами):
Выбираем регион сорса, кликаем Edit Region Mapping.
Идем в список аккаунтов для работы с таргетным регионом - Target account (это все IAM роли, добавленные в Veeam Backup for AWS) и выбираем роль IAM, чьи пермиссии будем использовать для сохранения снапшотов на таргет.
Примечание: Если вы выберете роль, созданную в другой учетной записи AWS, то снапшоты будут сохраняться в эту самую учетную запись.
Идем в список регионов Target region и выбираем, куда хотим копировать снапшоты.
Если хотим включить для них еще и шифрование, то зачекиваем галочку Enable encryption и из списка ключей выбираем мастер-ключи (CMKs) AWS Key Management Service (AWS KMS). Подробнее о ключах CMK написано здесь: AWS Documentation. Также указываем, как применять шифрование (опции в Key Usage ) - можно шифровать снапшоты для всех инстансов или только для зашифрованных сорсов.
Важно! Если исходный инстанс зашифрован, то шифрование на таргете для его снапшота включить обязательно, иначе репликация не пойдет.
Не забываем нажать Save, чтобы сохранить настройки.
Полезно: Можно настроить маппинг для всех сорсных регионов разом, нажав Set Mapping for All Regions и указав описанные выше настройки, которые станут общими для всех.
7. На этом же шаге можно настроить тэги для таргета (если вы хотите, чтобы у снапшота были кастомные тэги). Для этого нужно кликнуть Tags from source volumes will not be copied and custom tags will not be applied и перейти в окошко Tags Configurations.
В нем можно выбрать опцию Copy tags from source RDS instance (скопировать на созданный снапшот все тэги с сорса). Также можно кликнуть Add custom tags to created snapshots - это если вы хотите добавить кастомные тэги (но не более 5 штук). Новые тэги нужно ввести вручную, указав соответствующие Key и Value.
Примечание: Эти настройки распространяются также и на реплику.
8. С расписанием на шаге Schedule все интуитивно понятно - кроме, возможно, сценария с harmonized schedule, о нём расскажу подробнее чуть позже.
9. После этого на шаге Cost Estimation визард автоматически посчитает, во что вам обойдется резервное копирование с указанными настройками. Более подробно про это было рассказано здесь.
Примечание: Эта оценка будет сделана только в том случае, если было задано расписание на шаге Schedule.
10. В завершение процесса указываем, сколько повторных попыток выполнять, если с первой что-то пошло не так, а также кого и в каком случае уведомлять:
11. На заключительном этапе рекомендуется сделать предварительную проверку пермиссий, нажав permission check:
Если отчет покажет, что каких-то пермиссий не хватает, это можно тут же исправить:
Кликаем на линк Update role.
В окошке Grant permissions вводим одноразовый ключ пользователя IAM, уполномоченного задавать пермиссии для роли IAM, и жмем Apply.
Теперь все в порядке, наши инстансы RDS защищены новой политикой.
Гибкие настройки хранения
Если в разделе Schedules вы выбрали сразу несколько опций (например, задали расписания Daily и Weekly), то Veeam Backup for AWS применит так называемый механизм гармонизации. Суть его в том, что точки восстановления, которые создаются при более частом бэкапе (ежедневно, еженедельно или ежемесячно), переиспользуются при формировании цепочки точек с более редким интервалом. Например, администратор хочет бэкапить инстанс каждый день - и при этом ему нужна еще точка восстановления раз в неделю (которая, соответственно, будет храниться дольше). Тут мы и даем возможность настроить расписание таким образом, что Daily и Weekly запуск пересекутся - и в этот момент мы не будем создавать две точки восстановления, а создадим всего одну.
Такой подход помогает повысить производительность механизмов бэкапа и снизить затраты на хранение данных.
Чтобы задействовать механизм гармонизации, очевидно, нужно настроить как минимум два графика для бэкапа: один - для более частого создания новых точек восстановления, другой - с менее частым запуском - для организации хранения.
Применение гармонизированных расписаний происходит так:
Более "частым" точкам присваиваются пометки-флаги, соответствующие частоте создания таких точек: D - для точек, создаваемых ежедневно, W - еженедельно, M - ежемесячно и Y - ежегодно.
Когда отрабатывает политика с меньшей частотой\более длинным интервалом, в которой нами задано переиспользование "частой" точки, то этой выбранной точке присваивается еще один флаг - но это уже индикатор более длительного периода хранения. Для Veeam Backup for AWS это будет означать, что такая точка не подлежит удалению до окончания соответствующего срока.
Когда истечет срок хранения для всех расписаний, для которых использовалась точка, она будет удалена.
Пример
Допустим, бэкап-администратору нужна такая политика резервного копирования:
Снапшоты должны создаваться 3 раза в день, в цепочке должно быть не больше 3 таких ежедневных снапшотов.
Также необходимо иметь еженедельный снапшот, который должен храниться 2 недели.
Для реализации этого сценария создадим политику с двумя расписаниями - ежедневным и еженедельным:
В ежедневном графике (Daily schedule) надо указать, в котором часу будут создаваться снапшоты - пусть у нас это будет 3 раза в день по будням (7:00 AM, 9:00 AM, 11:00 AM; Working Days).
Также укажем, сколько ежедневных снапшотов нам нужно держать в цепочке (Snapshots to keep) - 3 штуки.
(Все эти настройки Veeam Backup for AWS будет иметь в виду и для второго расписания, еженедельного.)
Во втором, еженедельном расписании (Weekly schedule) укажем, который из наших ежедневных снапшотов мы хотим использовать для более длительного хранения, и зададим время этого самого более длительного хранения. Допустим, мы решили использовать снапшот, создаваемый в 7 утра понедельника, и нам нужно, как вы помните, чтобы он хранился 2 недели. Соответственно, выбираем 7:00 AM, Monday.Ну и в Snapshots to keep вводим 2 (в цепочке будет два W- снапшота).
Когда политика начнет работу, процесс пойдет так:
В понедельник, в 7:00 будет создана первая точка. Она получит флаг (D), поскольку появилась согласно Daily schedule. Но так как те же самые настройки ( 7:00 AM, Monday ) указаны и в Weekly schedule, то применится Weekly-график, и эта же точка получит и флаг (W).
В этот же понедельник будут созданы еще две ежедневные точки (9:00 и 11:00), которые получат только флаг (D).
3. Далее наступает вторник, и в 7:00 создается новая ежедневная точка, которая получает флаг (D).
И вроде бы получается, что лимит ежедневных точек в цепочке (3 штуки) превышен. Но у одной из этих точек есть еще флаг (W), означающий, что она входит в цепочку Weekly, поэтому удалить ее мы не можем - а можем только снять с нее флаг (D) и продолжим хранить эту точку 2 недели, как предписано.
4. Далее в этот же вторник запускается новая бэкап-сессия в 9:00 утра - и по ее окончании количество точек с флагом (D) опять-таки превысит заданную длину цепочки. Но тут у нас есть подходящий кандидат на удаление - это точка, которая была создана в 9:00 в понедельник, у нее ведь нет никаких других флагов, только флажок (D). Ее-то и удалит из цепочки Veeam Backup for AWS:
5. Veeam Backup for AWS продолжит работать всю эту и всю следующую неделю, удаляя старые ежедневные точки согласно флагам (D).
6. Когда наступит 3-я неделя, то в 7:00 утра понедельника у нас снова создастся точка с двумя флагами (D, W). При этом в цепочке еженедельных (W)-точек у нас уже 3 точки и, стало быть, одна из них лишняя - это самая старая точка. Тут Veeam Backup for AWS снимет с нее флаг (W), а раз она остается вообще без флагов, это значит, что ни в какой цепочке она уже не участвует, и ее можно смело удалять.
На сегодня, пожалуй, все - а процесс восстановления мы рассмотрим в следующий раз.
Что еще почитать и посмотреть
Статья на Хабре о развертывании и настройке решения Veeam Backup for AWS
Статья на Хабре о решениях для защиты облачных инфраструктур
Руководство пользователя Veeam Backup for AWS (на англ. языке)
Руководство по интеграции с Veeam Backup & Replication (на англ. языке)
