Привет, Хабр! Меня зовут Артем Токарь, я младший инженер технической поддержки в К2 Кибербезопасность. Наша команда работает в составе Центра экспертизы по комплексному сервису К2Тех и занимается администрированием средств защиты информации. В том числе мы защищаем сайты заказчиков от веб‑атак — стоим на границе между приложениями и теми, кто к ним обращается.

Я расскажу, как мы искали способ бэкапить свой WAF так, чтобы не разориться на облаке и при потенциальном откате не потерять несколько дней ручной работы.

Спойлер: все дело в том, что именно бэкапить. Если сохранять только те данные, которые часто меняются, резервные копии перестают стоить как чугунный мост. Например, терабайтные снапшоты можно легко заменить архивом на 50 мегабайт, который снимается за 50 секунд.

Заказчик, которому стало тесно

Наш заказчик — крупный интегратор. Он разворачивает и обслуживает веб‑инфраструктуру для самых разных клиентов. Грубо говоря, он стоит между конечным пользователем веб‑ресурса и его разработчиком, но за безопасность всей этой инфраструктуры во многом отвечаем мы.

Количество доменов за нашим WAF уже давно стало трехзначным. Причем домен здесь не всегда означает один сайт. Там может висеть двадцать‑тридцать приложений. Большинство доменов относятся к продакшену, а оставшиеся — тестовые среды. Однако защищать нужно всю инфраструктуру без исключения, поскольку тестовые стенды тоже доступны из внешнего контура. Для этого мы используем WAF SolidWall.

Сперва наш заказчик использовал SolidWall на вендорской инсталляции вместе с Anti‑DDoS решением: трафик шел на их ноды, там фильтровался и уходил дальше. Схема рабочая, однако со временем задачи усложнялись, и решать их в рамках прежней модели анализа трафика становилось все труднее. Заказчик рос, количество доменов увеличивалось, поэтому в августе 2025 года мы решили развернуть собственную инсталляцию SolidWall в K2 Cloud.

В пользу SolidWall были веские аргументы. Для нас было важно перенести правила со старой инсталляции. Система очень гибкая, но настройка требует определенных навыков, поэтому обычно ее разворачивает сам вендор. У нашей команды уже был опыт администрирования WAF, и мы спокойно взяли эту задачу на себя. Вендор нас поддержал: предоставил образы и помог с развертыванием.

Инсталляцию собрали с серьезным запасом. Обычной отказоустойчивости, когда упавшую ноду подхватывает соседняя, нам оказалось мало, поэтому конфигурацию сделали катастрофоустойчивой: три воркера функционируют одновременно в режиме active‑active‑active, управление ими осуществляется кластером из двух нод управления, где одна нода является мастером, вторая — резервной.

Почему снапшотов нам мало (или, точнее, слишком много)

Для обеспечения отказоустойчивости и повышенной доступности инфраструктуры мы всегда сохраняем возможность отката на последнюю рабочую версию. Конечно, можно просто снять копии со всех виртуальных машин, но вопрос в том, сколько это будет стоить.

В нашем случае речь идет о совокупном объеме данных, суммарный объем которых измеряется в терабайтах. Если делать частые снапшоты, расходы получатся баснословными. Полные копии виртуальных машин мы все равно создаем, но реже — как базовую страховку.

Еще одна проблема заключается в том, что WAF относится к тем средствам защиты, которые требуют постоянной настройки. Мы корректируем разрешающие правила, подключаем новые домены и добавляем приложения практически ежедневно.

Для нового домена по умолчанию действует общий конфиг с базовым набором правил. Универсальные настройки нередко дают ложные срабатывания, поэтому для каждого домена постепенно формируется собственная конфигурация на основе реального трафика. Это кропотливый процесс, который крайне сложно полностью автоматизировать: на практике каждый домен заводится и настраивается вручную.

А теперь представьте ситуацию: в понедельник утром сделан облачный бэкап. Всю неделю я вручную настраиваю конфиги под новые приложения, а в пятницу происходит сбой в базе данных. Откатываться до понедельника нельзя, так как мы потеряем все доработки. Не откатываться — значит рисковать доступностью и корректностью работы защищаемых ресурсов.

Идеального решения у этой дилеммы нет. В таких обстоятельствах приходится выбирать между скоростью восстановления и сохранением накопленного прогресса. Именно такую ситуацию я и пытался исключить.

Заказчик попросил твердую гарантию: что бы ни произошло с инсталляцией, результаты настройки и обучения WAF не должны пропасть.

Итого, требования к бэкапу получились следующими: создавать его часто и быстро, не влиять на продовый трафик, сохранять все необходимые настройки и при этом укладываться в бюджет. Сложнее всего, конечно, выглядело сочетание первого и последнего пунктов. Нужно было придумать, как регулярно создавать резервные копии и не платить за хранение дополнительных терабайтов данных.

Перекресток трех дорог

Готового решения этой задачи не было даже у самого вендора. Как в известной сказке, я стоял перед камнем на распутье с тремя надписями. Налево пойдешь — штатное приложение, направо — API‑выгрузка, прямо — куда‑то в базу данных. По очереди и пошел.

Штатное приложение

У вендора есть собственное приложение для выгрузки конфигурации. Нюанс в том, что оно выгружает по одному домену за раз. Чтобы прогнать через него весь наш парк, вручную потребуется примерно два часа на экспорт и еще столько же на импорт.

API

Под капотом упомянутого приложения лежат API‑запросы, и я подумал: раз есть API, можно автоматизировать выгрузку всех доменов сразу.

Я погрузился в документацию, которую запросил у поддержки SolidWall, но выяснилось, что штатного механизма массовой выгрузки там не предусмотрено. Тогда я свернул на окольную тропу. Поскольку приложение работает локально, можно было попытаться перехватить его HTTP‑запросы, а затем прогнать их в цикле по идентификаторам приложений и самостоятельно собрать выгрузку. Здесь важно подчеркнуть два момента. Во‑первых, вся работа велась исключительно на тестовом стенде и никак не затрагивала продакшен. Во‑вторых, этот сценарий не был описан в документации, поэтому приходилось изрядно изощряться.

Около двух недель я проверял эту гипотезу, но в итоге пришел в тупик. Добиться нужной скорости не удалось, и результат меня не устроил.

База данных

Правильное направление подсказал мой техлид, бросив фразу в духе: «Да хоть бы и базу данных выгружать». И, знаете, в этом что‑то было.

Я снова обратился к поддержке вендора и спросил: «У вас же есть механизм миграции между версиями?».

Оказалось, что есть. Для одной из ранних версий существовал плейбук, с помощью которого специалисты вендора выгружали нужные разделы баз данных. Дело пошло: инженеры подсказывали, где хранятся необходимые данные, а я проверял процедуру на своей инсталляции, смотрел, какие разделы выгружаются и действительно ли в них есть все необходимое.

Почему выгрузка БД, а не API? Представьте магазин у дома. В нем есть все, что нужно, но вы зачем‑то едете туда через МКАД. Это API: запрос наматывает круги по сети, конвертирует профиль в JSON и отправляет его синхронными запросами к вам. При выгрузке базы никакого объезда не требуется: данные уже лежат на локальной машине — остается только забрать нужное. Такой метод гораздо эффективнее.

50 секунд и 50 мегабайт

Выяснилось, что все самое ценное — накопленные результаты обучения и настройки доменов — хранится в нескольких разделах PostgreSQL и MongoDB. Их общий объем составляет всего несколько десятков мегабайт.

Терабайтные снапшоты при этом никуда не делись: они остаются частью регулярного резервного копирования, но данные, которые накапливаются между ними, теперь можно сохранять отдельно, причем быстро и без существенных затрат.

Написанный мной скрипт выгружает всю нужную информацию и сразу ее архивирует за пятьдесят секунд. Импорт занимает еще столько же, и готовый бэкап весит около пятидесяти мегабайт. При необходимости такие копии можно создавать хоть каждую минуту.

Процесс восстановления теперь выглядит следующим образом. На уровне виртуализации мы откатываем только management‑ноды до последнего актуального снапшота. Это занимает около десяти минут и не прерывает обработку трафика: он продолжает проходить через worker‑ноды, которые мы не трогаем.

Чтобы исключить рассинхрон конфигураций при восстановлении из снапшота, мы временно изолируем management‑узлы от воркер‑нод на сетевом уровне. В этой изоляции management‑ноды стартуют со старыми настройками, после чего в базу загружается свежий архив правил. Мастер‑ноды пересчитывают хеши, применяют новые правила, и только после этого мы возвращаем связность — так все узлы начинают работу с гарантированно актуальными данными.

В результате весь процесс занимает от десяти до пятнадцати минут вместо пяти‑шести часов, которые потребовались бы на ручной перенос правил.

Запустить бэкап можно тремя способами:

1. Вручную, когда инженер сам зашел и снял копию.

2. По расписанию: служба под Linux следит за временной меткой и запускает экспорт n раз в сутки.

3. И аварийно, вот это самое интересное.

Аварийный бэкап создает отдельная самописная служба backup‑monitor. Сигналом для нее служит переключение мастер‑ноды кластера.

Здесь стоит разделить два процесса. Сам арбитр ничего не знает о резервном копировании. Его задача — перенести роль мастера на доступную ноду. Служба же замечает, что главной стала вторая нода. Поскольку такое происходит только при сбое первой, переключение воспринимается как сигнал немедленно создать резервную копию.

Все эти сценарии я долго проверял на изолированном стенде. Настроил множество доменов и моделировал как штатные, так и аварийные ситуации. Когда стало понятно, что логика работает, а все задуманные процессы выполняются корректно, мы приступили к внедрению в продакшен.

Когда штатного бэкапа хватает, а когда нет

В дополнение к основному механизму мы проработали сценарий мониторинга через Zabbix. Недавно наша команда поделилась опытом работы с этим решением — подробнее в статье. Система отслеживает время создания последнего архива и, если он старше заданного количества часов, генерирует предупреждение: «Бэкап не создается». Также мы автоматизировали отправку архивов в изолированное SFTP‑хранилище, но это уже детали.

Если свести всю эту историю к одному выводу, он будет звучать так: практически в любой системе есть пространство для оптимизации. Часто можно сэкономить ресурсы и время, и для этого вовсе не обязательно быть гуру разработки. Все описанное здесь появилось благодаря советам коллег, документации, поиску в интернете, нейросетям и упорству. Этого оказалось достаточно.

Когда инфраструктура разрастается, волей‑неволей приходится всерьез задумываться об оптимизации. И в первую очередь стоит смотреть на те части системы, которые меняются чаще всего. Нередко это базы данных и конфигурации: их можно и нужно сохранять регулярно, а тяжелые снапшоты пусть остаются базовой, но более редкой страховкой.