Бэкап Kubernetes для stateful-сервисов: выбор и тесты restore

Зачем вообще нужен бэкап Kubernetes для stateful-сервисов

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

В реальных инцидентах почти никогда не пропадает что-то одно. Часто одновременно страдают PersistentVolume (или данные на дисках), манифесты (Deployment/StatefulSet, Service, Ingress, RBAC), Secrets и ConfigMap, а также настройки вокруг: StorageClass, политики доступа, параметры сети. Если восстановить только PV, но забыть про секреты подключения или права, приложение не поднимется, хотя данные физически на месте.

Stateful-сервисы сложнее еще и из-за порядка запуска и согласованности. PostgreSQL с репликацией или Kafka требуют аккуратного возврата: важно, какие ноды стартуют первыми, как подхватываются тома и не возникнет ли split-brain. Поэтому бэкап здесь - не просто копирование файлов, а способ вернуться в предсказуемое состояние.

Полезно сразу разделять два сценария:

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

Бэкап Kubernetes закрывает типовые беды: случайное удаление namespace, ошибочный helm upgrade, сломанные права, потерю ноды со стейтом, порчу тома, миграцию в другой кластер. Но он не спасет от всего. Если данные внутри приложения зашифровал вредонос, и это успело попасть в бэкап, или если бэкапы не проверяются восстановлением, надежность останется иллюзией. Бэкап имеет смысл только вместе с понятным планом restore и регулярными проверками.

Что именно бэкапить: данные, конфигурации и зависимости

Бэкап Kubernetes для stateful-сервисов почти никогда не сводится к "снять копию тома". Для нормального восстановления нужны и данные, и то, как они подключались, и права, и несколько неочевидных зависимостей.

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

На практике удобно думать про три слоя:

• Ресурсы в namespace (Deployments, StatefulSets, Services, Ingress, ConfigMaps).
• CRD и связанные ресурсы (например, от операторов баз данных).
• Права и доступы (ServiceAccounts, Roles/RoleBindings, иногда ClusterRole/ClusterRoleBinding).

Secrets требуют отдельного внимания. Копировать их как есть можно, но важно понимать, как они защищены. Если в кластере включено шифрование Secrets, то без ключей (KMS или ключей API-сервера) восстановление может дать "битые" значения. Лучше, когда ключи живут отдельно от бэкапов и у них есть свой регламент ротации и восстановления.

С PV все зависит от хранилища. Если есть CSI-снапшоты, они дают быстрый возврат к точке во времени, но обычно только в пределах совместимого стораджа и часто внутри одного дата-центра. Если снапшотов нет, придется опираться на бэкап на уровне приложения (например, дампы) или на возможности самого хранилища.

Для баз данных почти всегда лучше сочетать подходы. Снапшот тома помогает с быстрым RTO, а логический дамп (pg_dump, mysqldump) дает переносимость и защиту от логических ошибок (например, случайного удаления таблицы). Рабочий пример: перед релизом вы делаете снапшот, а ночью снимаете логический дамп и проверяете, что он действительно восстанавливается.

Не забывайте про внешние зависимости: внешний S3-бакет, внешняя БД, LDAP, лицензии, DNS-записи. Их не "забэкапить" инструментом Kubernetes, но можно зафиксировать конфигурацию и точки доступа, а для внешних систем настроить свой бэкап и тест восстановления, чтобы цепочка не порвалась в день аварии.

Требования к стратегии: RPO, RTO и модель восстановления

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

RPO (Recovery Point Objective) простыми словами - "насколько свежими должны быть данные после восстановления". Если RPO 15 минут, значит в худшем случае вы теряете изменения за последние 15 минут.

RTO (Recovery Time Objective) - "сколько времени вы можете быть недоступны". Если RTO 1 час, то через час сервис должен снова работать, пусть сначала и в ограниченном режиме.

Определить RPO и RTO помогает разговор с бизнесом и командой эксплуатации: что больнее - потеря данных или простой. Для внутреннего Git и CI часто важнее RTO (быстро подняться), а для платежей или медицинских записей важнее RPO (не потерять транзакции).

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

В документах полезно зафиксировать минимум: целевой RPO/RTO по каждому критичному сервису, частоту снимков и сроки хранения (retention), фактическое время restore по тестам, а также кто и по какому сигналу запускает восстановление.

Дальше выбирается модель восстановления. "Бэкап Kubernetes" на уровне кластера (ресурсы, манифесты, Secrets, метаданные PVC) помогает быстро пересобрать сервисы, но не всегда гарантирует согласованность данных внутри томов. Бэкап на уровне хранилища (снимки томов, репликация) чаще дает более надежный путь для баз данных и очередей, но требует понимания связи с Kubernetes-объектами и порядка запуска.

DR-план нужен не только "крупным": достаточно одного критичного сервиса, чтобы второй кластер или другая площадка стали обязательными. Практичный ориентир такой: если простой в пределах одного дата-центра неприемлем, планируйте восстановление в другой зоне отказа или на отдельном кластере. Заранее решите, где лежат бэкапы и у кого к ним доступ.

Velero, Kasten, Portworx: чем они отличаются по смыслу

Velero, Kasten K10 и Portworx PX-Backup решают похожую задачу (бэкап Kubernetes и восстановление), но отличаются подходом. Если понять, что у каждого продукта является "ядром", выбрать проще.

Velero часто берут как базовый старт. Из коробки он хорошо забирает ресурсы Kubernetes (манифесты, namespaces, CRD при правильной настройке), а вот с данными на томах все зависит от окружения. Для снапшотов и корректной работы с конкретными хранилищами обычно нужны плагины (CSI, провайдер объектного хранилища и т.д.). Это гибко и обычно дешевле по лицензии, но требует аккуратной настройки и поддержки.

Kasten K10 рассчитан на более управляемую платформу бэкапов в enterprise: политики, расписания, отчеты, видимость по приложениям, ролевая модель, удобные сценарии восстановления. Его чаще выбирают там, где важны аудит, соответствие требованиям, делегирование задач командам и понятная операционная модель. Лицензия обычно дороже, зато меньше "сборки из деталей".

Portworx PX-Backup логичнее рассматривать, когда бэкап тесно связан со слоем хранения и важны storage-функции: консистентные снапшоты, перенос томов, миграции между кластерами. Это особенно удобно, если Portworx уже используется. Если нет, добавляется еще одна платформа, которую нужно сопровождать.

Оценивайте не только функциональность, но и стоимость владения: лицензирование, операционные затраты (обновления, плагины, разбор сбоев restore), интеграции со стораджем и требования к контролю (политики, RBAC, аудит).

Если у вас on-prem инфраструктура (например, в своем ЦОД) и важны прозрачные процессы и поддержка, закладывайте в выбор не только инструмент, но и ресурсы на регулярные тесты восстановления и сопровождение всей цепочки.

Как выбрать инструмент под ваш кластер: критерии без маркетинга

Выбор инструмента лучше начинать не с бренда, а с того, как устроены ваши данные и хранилище. Для stateful-сервисов решает не интерфейс, а то, как инструмент работает с томами, снапшотами и восстановлением в реальных авариях.

Сначала проверьте совместимость со storage-слоем. Если вы рассчитываете на быстрые восстановления через снапшоты, нужна поддержка CSI snapshot именно для ваших storage-классов (и реальная работа в вашем кластере, а не только в документации). Если снапшоты недоступны, заранее решите, что будет вместо них: файловое копирование, sidecar-агенты, интеграция со стораджем. Это напрямую влияет на RPO и время простоя.

Дальше смотрите на то, как устроены политики и восстановление. Важно, чтобы можно было задавать правила по namespace и меткам, исключать лишнее, восстанавливать данные томов согласованно и делать restore в другой namespace (для тестов) и в другой кластер (для DR и миграций). Плюс нужна понятная диагностика: что забэкапилось, что пропущено и почему.

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

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

Если сомневаетесь между вариантами, сделайте короткий пилот на одном критичном stateful-сервисе: одинаковый сценарий бэкапа и восстановления, одинаковые метрики. Обычно этого хватает, чтобы решение стало очевидным.

Где хранить бэкапы: S3-совместимое, NFS, on-prem и оффсайт

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

Объектное хранилище (S3-совместимое) обычно выигрывает для регулярных бэкапов: оно проще масштабируется, удобнее для версионирования и часто лучше защищается политиками неизменяемости. Файловое хранилище (NFS) удобно, когда нужен быстрый локальный доступ и простая интеграция, но оно чаще становится единой точкой отказа, особенно если находится рядом с тем же кластером.

Правило 3-2-1 в терминах Kubernetes можно понимать так: три копии (например, ежедневные, недельные и месячные), два типа носителя (объектное и файловое или архив), и одна копия вне площадки (другой ЦОД или отдельный провайдер).

Отдельная тема - учетные данные. Делайте бэкап-аккаунт в хранилище отдельным от боевых и давайте ему минимальные права. Хорошая практика - разнести учетные записи по средам (dev/stage/prod), чтобы тестовый скрипт не мог стереть прод.

По срокам хранения заранее договоритесь, что нужно для расследований и откатов: сколько хранить ежедневные, сколько недельные, нужны ли годовые архивы. Включайте версионирование и защиту от удаления/перезаписи (immutability или хотя бы запрет delete для бэкап-учетки), иначе один неверный rm превращает бэкапы в фикцию.

On-prem размещайте так, чтобы пережить сбой площадки: репозиторий не должен жить на тех же стойках и в той же зоне питания, что и кластер. Если есть второй сайт или отдельная площадка, репликация туда закрывает самый неприятный сценарий: "кластер и бэкапы умерли вместе".

Пошагово: как собрать рабочую стратегию бэкапа

Начните с инвентаря. Выпишите критичные namespace и сервисы со стейтом: базы данных, очереди, хранилища файлов, а также PV, которые к ним привязаны. Отдельно отметьте, какие данные можно восстановить из внешних систем (например, из реплик), а какие существуют только в кластере.

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

Часто достаточно простой схемы: ежедневный бэкап PV и ресурсов в критичных namespace, более частый бэкап только конфигураций (без томов), понятная ретенция (например, 7 дневных, 4 недельных, 6 месячных копий) и явный список исключений (dev, staging или конкретные label).

Затем настройте доступы. Создайте отдельный service account для бэкапа, выдайте ему только нужные роли и доступ к секретам хранилища. Проверьте, что у него нет лишних прав, а секреты не лежат в открытом виде в пайплайнах.

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

Закрепите все короткой документацией, иначе стратегия не живет. Обычно хватает одной страницы: что бэкапим, где лежат копии, как запустить бэкап и восстановление, и кто отвечает за шаги. Добавьте минимальный набор команд (backup, list, restore, verify), контакты дежурных, окна для тестового restore и критерий успеха (какие проверки должны пройти после восстановления).

Как тестировать восстановление: регулярные сценарии и метрики

Бэкап Kubernetes ценен ровно настолько, насколько вы умеете его восстанавливать. Тесты restore должны быть регулярными, одинаковыми по шагам и с понятными цифрами на выходе.

Самый безопасный старт - восстановление в отдельный namespace. Так вы проверяете, что создаются PV/PVC, поднимаются StatefulSet/Deployment, подтягиваются Secret и ConfigMap, а прод при этом не затрагивается. Удобно добавлять суффикс к именам ресурсов и временно отключать ingress, чтобы тест не превратился в случайный релиз.

Следующий уровень - тест на другом кластере. Это DR-сценарий, где всплывают проблемы с DNS, версиями CSI-драйвера, доступом к хранилищу и внешними зависимостями (внешняя БД, очереди, лицензии). Такой тест стоит делать хотя бы раз в квартал или после крупных изменений кластера.

Что именно валидировать после restore

Недостаточно увидеть, что поды стали Running. Проверьте консистентность данных на уровне приложения: для Postgres - контрольные запросы и сверка числа строк, для Kafka - чтение нескольких последних сообщений, для файлового сервиса - хэши пары эталонных файлов. Хорошее правило: валидируйте то, что важно бизнесу, а не то, что удобнее инженеру.

Метрики и автоматизация

Чтобы замерять реальный RTO, фиксируйте время от команды restore до момента, когда сервис отвечает на простую проверку (health плюс один "боевой" запрос) и прошел прогрев кешей.

Для отчета обычно хватает: фактического RTO (общее время и время до готовности приложения), процента успешных restore за период, "дрейфа" (что не восстановилось или изменилось) и фактической потери данных (реальный RPO по контрольным точкам).

Автоматизируйте тесты по расписанию: ночной restore в тестовый namespace, ежемесячный restore на резервный кластер, сохранение логов и таймингов в единый журнал.

Частые ошибки и ловушки при бэкапе stateful в Kubernetes

Что ломается чаще всего

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

Одна из типовых проблем - PV не поднимается, потому что в целевом кластере другой StorageClass или нет нужного CSI-драйвера. Бэкап восстанавливает манифесты, но хранилище не может выделить том с теми же параметрами (тип диска, зоны, политика расширения, параметры шифрования). В итоге Pod зависает в Pending, а время идет.

Вторая ловушка - потерянные секреты и ключи. Приложение вроде бы развернулось, но не может расшифровать данные, подключиться к базе или открыть TLS-сертификат. Особенно болезненно это для stateful-сервисов: данные уже восстановлены, а ключи другие, и сервис отказывается работать.

Третья ошибка - снимки делаются без "заморозки" записи. Для PostgreSQL, MySQL, Elasticsearch и похожих систем важна согласованность. Если сделать снапшот на горячую без quiesce (или без встроенного механизма бэкапа базы), можно получить тихую порчу: восстановление пройдет, а потом всплывут битые индексы или недостающие транзакции.

Четвертая проблема - права доступа. Если бэкапы лежат в одном месте и доступ к ним слишком широкий, их легко удалить случайно: оператором, скриптом очистки или ошибкой в политике retention.

И самая частая причина провала - restore не проверяли месяцами. В день аварии выясняется, что поменялись версии CRD, истекли токены, новый кластер не видит репозиторий, или восстановление требует ручных шагов, о которых никто не помнит.

Как подстелить соломку

Помогает короткий набор регулярных проверок:

• Сопоставляйте StorageClass и CSI в плане восстановления: что будет в новом кластере и как маппятся тома.
• Храните секреты так, чтобы их можно было восстановить вместе с данными, и отдельно проверяйте ключи шифрования.
• Для баз данных используйте согласованный режим: либо встроенный бэкап, либо снапшоты с quiesce и проверкой целостности.
• Разделяйте роли: кто создает бэкапы, кто может удалять, кто запускает restore.
• Тестируйте восстановление по расписанию и фиксируйте фактические RTO и точки потери.

Простой сценарий: раз в две недели восстановите тестовый namespace с Postgres и приложением, затем выполните одну-две контрольные операции (логин, запись, чтение). Это дешевле, чем разбираться во время реальной остановки.

Короткий чеклист перед запуском в прод

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

Сначала договоритесь, что именно для вас считается потерей данных и сколько простоя терпимо. Для разных stateful-сервисов цифры будут разными: база, очередь и хранилище файлов почти никогда не равны по критичности.

Дальше пройдитесь по пунктам:

• Есть список критичных сервисов, для каждого записаны RPO и RTO и выбрана модель восстановления (в тот же кластер или в новый).
• Бэкап покрывает не только тома (PV), но и манифесты, настройки и зависимости: Namespace, CRD, ConfigMap, Secrets, а также Ingress и политики доступа, если они нужны для старта.
• Хранилище бэкапов изолировано: отдельные доступы, защита от массового удаления, включена версияция или неизменяемость, понятен план на случай компрометации учетных данных.
• Есть тест восстановления и известна дата последнего успешного прогона, плюс измерены фактические RTO: время до запуска Pod, до готовности приложения и до проверки данных.
• Назначен владелец процесса: кто следит за расписанием, кто реагирует на ошибки, где лежит короткая инструкция восстановления и как быстро получить к ней доступ во время инцидента.

Чтобы чеклист был живым, привяжите его к конкретному примеру. Например: "PostgreSQL для биллинга: RPO 15 минут, RTO 1 час, восстановление в новый namespace, проверка: количество записей и последние транзакции". Если это нельзя описать одной строкой, план пока не готов.

После запуска в прод поставьте напоминание пересматривать настройки при любом изменении хранилища, политик доступа или версии Kubernetes. Именно такие изменения чаще всего ломают восстановление.

Следующие шаги: пилот, регламент и инфраструктура под бэкапы

Дальше важнее не название инструмента, а то, как вы превратите бэкап Kubernetes в повторяемый процесс. Самый практичный путь - короткий пилот, где видно реальное время, размер, нагрузку и качество восстановления.

Начните с 1-2 приложений, которые отражают ваш типичный риск: PostgreSQL с PVC и небольшой сервис с критичными Secret и ConfigMap. Сделайте полный цикл: резервная копия, потеря данных (в тестовой среде) и восстановление, затем проверка на уровне приложения (логин, запросы, фоновые задачи).

План на 2-3 недели можно держать простым: выбрать пилотные приложения и RPO/RTO, настроить расписание и сроки хранения, провести несколько restore-сценариев (в тот же кластер, в отдельный namespace, в другой кластер, если он есть), зафиксировать метрики (время, размер, успешность проверок) и оформить короткий регламент на 1-2 страницы.

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

Если кластер on-prem, заранее продумайте серверную базу под хранилище и резервирование: отдельные узлы, RAID или репликацию, питание, мониторинг, схему оффсайта. В таких задачах иногда подключают системного интегратора - например, GSE.kz, который поставляет серверы и помогает собрать инфраструктуру под Kubernetes и процессы резервного копирования с учетом требований к поддержке и размещению данных.