Velero: backup и recovery для Kubernetes — полное руководство

Velero Kubernetes backup: где рвётся восстановление

Резервные копии снимаются по расписанию, отчёты зелёные, копии лежат в объектном хранилище. А в момент аварии восстановление проходит без единой ошибки — и кластер поднимается «пустым»: поды падают на старте, приложения не находят свои данные, часть объектов просто отсутствует. Причина в том, что Velero по умолчанию копирует не всё, что нужно для рабочего состояния, а порядок восстановления не повторяет порядок зависимостей.

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

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

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

Что даёт управляемое резервное копирование кластера

Резервное копирование перестаёт быть страховкой «на всякий случай» и становится управляемым процессом с измеримым целевым временем восстановления. Расписания снимают состояние ресурсов и томов в объектное хранилище, а восстановление выполняется из конкретной точки: отдельным пространством имён или кластером целиком. Целевое время восстановления задаётся заранее — десятки минут на типовой сценарий вместо часов ручной сборки.

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

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

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

Velero, снапшоты и репликация: когда что подходит

Защита состояния кластера распадается на две разные задачи: быстро вернуть рабочую нагрузку после сбоя и перенести её на другую площадку. Снапшот тома закрывает первую, но ничего не знает про объекты API — манифесты, секреты, привязки ролей и конфигурации. Velero работает именно с ресурсами кластера и умеет дополнять их копированием данных томов, но по скорости отката уступает снапшоту.

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

На практике подходы комбинируют: снапшот даёт быстрый откат, Velero — перенос и долгое хранение, репликация прикрывает отказ площадки. Что брать за основу, определяется тем, какое время восстановления вы обещаете бизнесу.

Этапы внедрения: от аудита хранилищ до передачи

Внедрение начинается не с установки, а с инвентаризации: какие пространства имён критичны, какие тома нужно снимать согласованно, а какие восстанавливаются из внешних систем. Без этой картины расписания делают «на всё подряд», хранилище растёт, а откат никто не проверял.

1. Аудит нагрузок и целей восстановления. Размечаем ресурсы по критичности и фиксируем для каждой группы два числа: допустимую потерю данных и допустимое время простоя. Они задают глубину расписаний и решают, что попадает в копии.
2. Схема резервирования. Выбираем целевое объектное хранилище, раскладку по контейнерам и правила хранения: сколько копий держать и когда чистить старое. Отдельно определяем, как снимать постоянные тома — снимками дисков или файловым способом.
3. Настройка расписаний. Расписания Velero описываем декларативно, разносим по критичности и дополняем сценариями согласованного снятия состояния баз. Конфигурация хранится в системе контроля версий и проходит ревью как код.
4. Изоляция доступа и контроль. Учётные записи с минимально достаточными правами, шифрование копий и оповещения о неуспешных заданиях — пропущенное копирование видно в тот же день, а не при аварии.
5. Проверка восстановлением. Разворачиваем копии в отдельном тестовом контуре, замеряем время отката и сверяем целостность данных. Расхождения возвращаем в схему: правим расписание, порядок снятия томов или набор ресурсов.
6. Передача документации. Отдаём схемы, файлы конфигурации, порядок отката и инструкцию для дежурного, разбираем процесс с командой заказчика. Дальше регламент живёт как обычная эксплуатационная процедура.

Что остаётся у вашей команды после внедрения

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

• Конфигурации копирования — расписания Velero, шаблоны, списки включаемых и исключаемых ресурсов, сроки хранения точек восстановления.
• Схема резервирования — карта: какие пространства имён, диски и объекты попадают в копию, в какие хранилища уходят данные, чем отличаются полная и инкрементальная копии.
• Политики доступа и роли для хранилища — раздельные учётные записи на запись копий и на восстановление, минимально необходимые права, порядок ротации ключей.
• Регламент восстановления — пошаговый сценарий с точками ветвления: выбор точки, подъём отдельного пространства имён или всего кластера, проверка результата.
• Инструкции для дежурной смены — что делать при сбое, как проверить свежесть последней копии, когда эскалировать и кого подключать.
• Регламент регулярных проверок — как часто выполняется тестовое восстановление на отдельном контуре, что считается успешным результатом и где хранится отчёт.
• Мониторинг и оповещения — журнал запусков, алерты на неуспешные копии и на превышение времени восстановления.

Каждый артефакт проверяем на учебном восстановлении: если по инструкции копия не поднимается на тестовом контуре, документ дорабатывается.

Кейс: восстановление за минуты вместо суток

До внедрения восстановление кластера было ручной операцией: снимки etcd снимались по расписанию, а тома и объекты внутри кластера в копию не попадали вовсе. Когда после неудачного обновления контроллеров понадобилось поднять рабочий контур заново, инженеры собирали его по частям из старых описаний — простой растянулся почти на сутки. Ни одной проверки копий до этого не делали, поэтому никто не мог сказать, лежит ли в архиве что-то пригодное к восстановлению.

Что изменили

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

Что изменилось в цифрах

Время восстановления типового сервиса сократилось с суток до 15-20 минут, окно допустимой потери данных — с нескольких часов до 15 минут на критичных контурах. Доля успешных автоматических проверок вышла за 90%, и каждая занимает минуты без участия человека. Откат перестал быть событием: инженер поднимает нужный срез данных одной командой и получает отчёт о том, что именно восстановлено, а интервалы расписаний подобраны так, чтобы объём архива рос предсказуемо.

Что делать, если кластер уже развёрнут и разделён

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

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

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

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

Технические сомнения и ограничения подхода

Копии делают не для галочки, а под проверку восстановлением. Ниже — возражения, которые чаще всего звучат перед внедрением Velero: насколько полна копия, как процесс влияет на продуктивный контур и где заканчиваются границы применимости.

Не просядет ли продуктивный контур во время копирования?

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

Кто отвечает, если восстановление не сработает?

Инструмент возвращает то, что в него положили: объекты кластера и тома. Секреты в сторонних хранилищах, DNS-записи, балансировщики и состояние за пределами кластера в копию не попадают — это зона заказчика. Мы описываем политики, хуки и расписания и проверяем восстановление на отдельном контуре, заказчик подтверждает перечень систем и порядок их подъёма.

Где подход перестаёт работать?

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

Обсудим вашу задачу и вернёмся с планом

Чтобы вернуться с составом работ и сроками, а не с общими словами, нужны ваши исходные данные. Пришлите конфигурацию кластеров и список пространств имён, отметьте сервисы, которые хранят состояние, и укажите, где сейчас лежат копии — в объектном хранилище или на дисках рядом с кластером.

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

Дальше мы собираем план внедрения:

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

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