Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям.
В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA.
Не претендую на универсальный рецепт, но подробно опишу, как мы упростили восстановление тестовой среды, сэкономили время и перестали бояться, что важные данные потеряются после очередного сбоя. Разберу всё по шагам: как настраивали, что сработало, где пришлось доработать и какие выводы сделали в итоге. Если вам интересно, как внедрить надежный бэкап всех данных у себя в компании, встретимся под катом. Также под катом — ссылка на наш вебинар, по теме для тех, кому ближе видеоформат.
Как выбирали хранилище и почему остановились на S3
У клиента типичная для крупных проектов инфраструктура на базе VMware: виртуальные машины, на которых крутятся критически важные сервисы. Простои недопустимы, каждый сбой – риск для бизнеса. Если что-то идёт не так (а оно рано или поздно идет), у нас предусмотрен запасной план: резервная площадка в облаке Selectel.
Для хранения точек восстановления мы сознательно отказались от блочного хранилища и выбрали объектное — оно дает больше гибкости, лучше масштабируется и подходит под наш сценарий работы. В качестве такого и было выбрано S3-хранилище облака Selectel. На это решение повлияло несколько факторов:
желаемое количество точек восстановления. Их предполагается хранить достаточно много, чтобы иметь возможность вернутся к более ранним вариантам данных и настроек серверов;
в случае инцидента предполагался различный подход к дальнейшему доступу к данным и целиком серверам. Часть машин в случае отказа должны быть восстановлены целиком и продолжить свою работу, а с части машин нам достаточно только получить конкретные необходимые данные, что не требует запуска всего сервера полноценно;
требования к RTO тоже были нескромными. Чем быстрее, тем лучше, но с реальной оценкой объема машин при этом. Доступ к конкретным данным более критичен в нашем случае. Поэтому фактор удалённости целевого хранилища от целевой площадки тоже играл роль;
более разумное использование ресурсов, развернутых в облаке. Хотелось не только понимать, что у нас где работает, но и держать под контролем объёмы, чтобы итоговые счета выглядели чуть скромнее.
Цель: обеспечить отказоустойчивость, сократить время восстановления и защитить данные от потерь. Как именно это реализовано, от подключения облака до восстановления рабочей среды из бэкапа, рассказываю ниже. А для тех, кто предпочитает видеоформат, вот ссылка на вебинар.
Одно облако, два подключения и ноль сюрпризов
Наше ключевое подключение, в рамках продукта это одно целевое облако, которое включает в себя конфигурации подключений:
к целевой площадке, где в будущем будут восстанавливаться виртуальные машины,
и к объектному хранилищу, в нашем случае — S3 от Selectel, где будут храниться сами точки восстановления.
Решение Хайстекс Акура позволяет гибко управлять хранением бэкапов: можно включить или отключить консолидацию точек восстановления, задавать сроки их жизни и определять правила очистки. Благодаря этому администратор сам контролирует, какие данные будут доступны для отката и сколько места они займут в хранилище. Если консолидация включена, то система объединяет точку/точки цепочек бэкапов. Это позволяет экономить место на целевой площадке и на сто процентов придерживаться выбранной политики хранения точек восстановления, не оставляя более старые и неактуальные, тем самым экономя место. Если выключена – сохраняются все полные и инкрементальные копии цепочки восстановления.
После завершения конфигурации Акура проводит валидацию: проверяет соединение с облаком и хранилищем, убеждается, что всё доступно и можно начинать работу. На этом этапе инфраструктура готова к приему данных. Далее – установка агентов и запуск резервных копий.
Клиенты, агенты и первый шаг к защите
После подключения облака создаю клиента, не человека, а виртуального (🙂), — логическую сущность в интерфейсе, которая связывает облачную площадку с группой машин, подлежащих защите. Именно на этом этапе я определяю, с каким облаком он будет работать, и перехожу к настройке агентов.
Для того чтобы Акура могла получать данные, требуется агент. Контроллер может не иметь прямого доступа к исходным машинам, особенно если они изолированы или находятся под жесткими ограничениями безопасности. Напрямую зайти не всегда возможно и не всегда допустимо. Поэтому я всегда начинаю с установки и настройки репликационного агента. Скачать его можно прямо из визард (ничего лишнего, только нужные файлы и пошаговая инструкция по установке), а дальше всё зависит от сценария. Акура предлагает два типа агентов:
Внешние: разворачиваются отдельно и умеют работать с несколькими машинами сразу (например, VMware-агент может видеть весь хост или даже все хосты, объединенные в кластер).
Внутренние: ставятся внутрь операционной системы конкретной машины и работают на прямую из её окружения.
После установки репликационный агент сам выходит на контроллер, регистрируется и передает информацию о найденных им машинах. В ответ он получает инструкции, начинать ли защиту конкретной ВМ или пока просто отслеживать её доступность.
Дальше всё по привычному сценарию: в интерфейсе выбираю нужные машины, добавляю их в стратегию резервного копирования и отправляю команду на запуск защиты. При следующем обращении к контроллеру агент получает задание и начинает снимать снапшоты состояния, именно они потом передаются на контроллер, а оттуда — в целевое хранилище.
Всё это происходит односторонне и по защищенному протоколу. При этом сама машина никак не страдает и передача данных не влияет на ее работу. Репликация ведёт себя тихо и скромно: без лагов, без нагрузки, не мешает ни приложениям, ни людям. Я лично прогоняла этот процесс на разных конфигурациях, в большинстве случаев пользователь не замечает, что на фоне идет передача данных. В завершение Акура автоматически видит все исходные машины, но сами действия остаются на стороне пользователя, поэтому мне достаточно выбрать нужную машину, нажать кнопку — и всё.
Автоматизация репликаций, чтобы не вспоминать об этом в пятницу вечером
Дальше переходим к настройке политики репликаций — шаг, который определяет насколько мы будем соответствовать требованиям RPO. Акура позволяет задать расписание репликаций с нужной точностью, от непрерывных запусков друг за другом до спокойного интервала раз в несколько часов. Для тех, кто любит держать всё под контролем, есть экспертный режим: расписание можно задать через Unix Crontab. Акура сама следит за его выполнением, так что человеческий фактор «забыл сделать бэкап» — исключен.
Типов репликаций три, и у каждого своя логика
Полная: передается весь объем данных машины;
Инкрементальная: копируются только изменения с момента последней точки;
Синтетически полная: передаётся только дельта, а окончательная сборка реплики происходит уже на стороне хранилища. Это особенно удобно, если используется длинная цепочка точек восстановления и консолидация отключена. Такой подход снижает нагрузку на сеть и ускоряет откат, потому что не нужно каждый раз пересобирать всю историю изменений вручную.
Когда с типом репликации и расписанием определились, самое время настроить политику хранения (retention policy), и здесь ее можно выстроить под любые сценарии. Потому что политика хранения точек восстановления это не просто галочка в настройках, а инструмент, который позволяет тонко управлять жизненным циклом данных. Поэтому к этому этапу я подхожу с полной серьезностью и лёгкой тревожностью админа, который однажды уже искал «тот самый бэкап».
Удобно, что параметры retention можно задавать на любом уровне: для конкретной машины, для группы или сразу для всего клиента. Можно под каждую задачу — будь то dev, прод или DR — выстроить свою стратегию хранения. Это дает гибкость и контроль, в этом, как по мне, кроется настоящая сила системы.
Поэтому я обычно подхожу к этому максимально осознанно: сколько точек нужно хранить, как долго, в каких сценариях продлевать срок, а где, наоборот, ужимать до минимума — всё это напрямую влияет на инфраструктурную устойчивость и соответствие SLA.
Как хранятся точки восстановления
Для каждой машины Акура формирует точку восстановления в объектном хранилище, которая состоит минимум из двух компонентов: файл данных, содержащий содержимое диска, и файл базы соответствия, в котором хранится информация о структуре и связи с каждым реплицируемым диском.
Если объем данных большой, файлы автоматически разбиваются на части (чанки). Типовой размер одного чанка 50 ГБ, но это значение можно изменить в зависимости от конфигурации хранилища и ограничений платформы. Дополнительный плюс Акуры в том что нулевые блоки в хранилище не попадают. Вообще. В некоторых сценариях это дает ощутимую экономию: меньше занятого места, меньше расходов.
Затем, вся эта структура уезжает в S3-хранилище и хранится там красиво, без сюрпризов. Никакой магии, только упорядоченный хаос, в котором Акура ориентируется лучше, чем большинство разработчиков в своей папке downloads.
Как хранятся бэкапы в объектном хранилище
Перейдем к восстановлению. Акура поддерживает два основных сценария восстановления, и оба отлично вписываются в реальную работу, будь то полный откат стенда или просто извлечение нужного файла до того, как «что-то пошло не так». Оба варианта я использовала в бою, и не раз. Причём каждый раз всё срабатывало без сюрпризов, что в нашем деле уже выглядит как чудо. Так что это не какие-то теоретические возможности из условной презентации, а реально работающие механизмы, которые можно спокойно включать в операционные процессы, не перепроверяя сто раз подряд.
Вариант первый: восстановление виртуальной машины
Если нужно поднять машину полностью, я использую так называемый Cloud Site (CS) — полноценное восстановление из выбранной точки. Сначала создаю план восстановления — инструкция с параметрами конфигурации для целевой машины. Затем, добавляю user-data и скрипты, которые выполняются на старте (удобно, если нужно что-то прогреть или автозапустить) и определяю порядок подъема машин при необходимости.
Остается выбрать нужную точку восстановления и запустить процесс. Акура через визард подхватывает выбранные параметры и автоматически создает все необходимые ресурсы на целевой площадке.Через вспомогательный прокси-инстанс подтягиваются данные из хранилища, разворачивается окружение, и вот уже запущен инстанс, готовый к работе. Всё автоматом, без ручной возни с образами или API.
Вариант второй: восстановление отдельных файлов и папок
Когда нужен всего один файл, разворачивать целую ВМ избыточно. В таких случаях проще использовать файловое восстановление.
Выбираем нужную точку восстановления, Акура монтирует хранилище прямо из S3, никаких копирований, всё работает «на месте». В интерфейсе появляется дерево директорий: можно спокойно пройтись по структуре, выбрать нужный файл и скачать его за пару секунд.
Это особенно удобно, если нужно быстро достать что-то точечное, например отчёт, скрипт, забытый конфиг или тот самый лог, который всегда нужен, когда всё уже упало.
Иногда восстановление может пойти не по плану: сеть оборвалась, агент не ответил, точка не смонтировалась. Чтобы не гадать у Акуры предусмотрен механизм отображения событий, который показывает, на каком этапе что-то пошло не так. Это помогает быстро локализовать проблему, не копаясь вслепую.
Для более глубокой диагностики есть встроенные инструменты сбора логов и удобный поиск по ним. А если нужно понять, где тормозит процесс, в интерфейсе доступны сводные метрики, помогающие найти узкие места между исходной и целевой площадками.
Кроме базовых сценариев восстановления Акура поддерживает и альтернативные варианты. Например, можно просто выгрузить RAW-образ диска и использовать его в сторонней системе. Или, еще гибче, подключить диск из точки восстановления к любой существующей виртуальной машине. Это удобно, если нужно, скажем, восстановить базу данных из старой версии, не трогая основную ВМ.
А что делать, если восстановленная машина на целевой площадке уже поработала во время инцидента, и теперь нужно забрать с нее данные обратно? Акура и на этот случай предлагает несколько вариантов.
Можно выполнить failback, т. е. вернуть данные на исходную или альтернативную площадку. Или просто выгрузить RAW-образ диска уже работающей на целевой стороне машины и дальше использовать его по назначению.
Если же исходная площадка не поддерживает сценарий обратного восстановления – не беда. У Акуры есть отдельный инструмент миграции, который позволяет переносить окружения между множеством разных целевых площадок. Так что даже в самых нетривиальных сценариях остаетесь с рабочим вариантом на руках.
Что в итоге
Я не люблю эксперименты, вместо этого предпочитаю выстраивать систему, которой могу доверять в критической ситуации. Поэтому выше показала и рассказала о своем опыте не ради демонстрации скриншотов, а для разбора рабочего кейса боевой инфраструктуры. Все решения принимались с оглядкой на реальные критерии: безопасность, изоляцию, уровень доступа, ресурсы и бюджет.
Интеграция проходит без лишней суеты. В зависимости от условий выбирается подходящий тип агента, которые работают в одностороннем режиме, не нагружают систему и не мешают пользователям. Всё происходит фоном и незаметно.
Активация защиты происходит вручную, но дальше Акура работает самостоятельно: управляет репликациями, хранит данные, следит за процессами. Всё происходит автоматически и прозрачно, без необходимости постоянного вмешательства.
Если что-то идёт не так, система не молчит: события фиксируются, отображаются в интерфейсе, доступны логи и метрики. Всё наглядно, по делу и понятно, где искать проблему и как её решить. Для QA-инженеров это критически важно: когда что-то идёт не так, нет времени на гадание, нужно быстро понять, что сломалось и как это вернуть. Поэтому я не устану повторять, — это не просто «бэкап на всякий случай». Это продуманный, системный подход, выстроенный не для галочки, а чтобы реально работать в условиях продакшена. Цель проста – защитить данные, сократить простой, ускорить восстановление. И да, никакого наития, только полный контроль.