Proxmox VE 8.2: настраиваем backup scheduler раздельно для КИИ и dev в одном кластере

Proxmox VE 8.2 вышел в апреле 2024, и главное, что нас в нём заинтересовало практически, - переработанный backup scheduler. Ceph Squid и SDN-улучшения тоже хорошо, но у нас прямо сейчас задача сложнее: один кластер Proxmox, в котором сидят и продуктив КИИ, и dev-окружения разработчиков. Требования к резервному копированию у них диаметрально противоположные. До 8.2 это решалось костылём в виде внешних cron-задач и нескольких скриптов. Теперь попробовали через штатный scheduler - и в целом он справляется.

Что поменялось в backup scheduler

В предыдущих версиях Proxmox планировщик резервного копирования был простым: одно задание, один storage target, расписание по cron-строке, опционально - список VM/CT. Гибкости не хватало. Если нужно было отдельное расписание для разных групп ВМ с разными политиками retention - приходилось либо создавать несколько заданий с перекрытием, либо вообще уходить в внешние инструменты.

В 8.2 scheduler получил поддержку нескольких независимых заданий с индивидуальными настройками:

• Retention policy на уровне задания. Теперь у каждого backup job своя политика хранения - сколько держать последних копий, сколько daily/weekly/monthly. Раньше это было глобально.
• Фильтрация по тегам ВМ. Backup job можно привязать к тегу, а не только к явному списку VMID. Это ключевое для нашей схемы.
• Уведомления через notification targets. В 8.1 появились notification targets, в 8.2 они плотнее интегрированы с backup - можно настроить алерты на провалившееся задание отдельно от всего остального.

Как мы разделили политики

Схема у клиента такая: в кластере примерно два десятка продуктивных ВМ (сегмент КИИ, соответственно требования регулятора по хранению резервных копий) и полтора десятка dev-машин разработчиков, которым важна свежесть бэкапа, но не глубина.

Для КИИ-продуктива требования по retention жёсткие: последние 7 ежедневных, 4 еженедельных, 3 ежемесячных. Для dev-машин это избыточно и только съедало бы место: держим последние 3 копии, не больше.

Разметили ВМ тегами прямо в Proxmox - kii-prod и dev. После этого в Web UI создали два отдельных backup job:

Первый job - kii-prod-backup - цепляется к тегу kii-prod, запускается ночью в 02:00, target - выделенный NFS-storage на резервной СХД, retention: keep-last=7, keep-weekly=4, keep-monthly=3. Уведомление на провал - через SMTP на дежурный адрес команды.

Второй job - dev-backup - тег dev, запускается в 04:00, тот же кластерный PBS (Proxmox Backup Server), retention: keep-last=3. Уведомления менее критичные - в корпоративный чат через webhook.

Важный момент: теги в Proxmox VE 8.x поддерживают иерархию с двоеточием - мы используем env:kii-prod и env:dev, но для фильтрации в backup job нужно указывать точный тег целиком, wildcards не поддерживаются. Если у ВМ несколько тегов, job подхватит её, если хотя бы один тег совпадает - это поведение стоит проверить на своей конфигурации до ввода в продуктив.

Ceph Squid: что имеем на практике

Proxmox VE 8.2 поставляет Ceph Reef по умолчанию, но поддержка Squid появилась как опция установки. Мы делали обзор Ceph 19 Squid в августе - тогда было понятно, что переход на Squid раньше следующего цикла обновлений Proxmox будет нестандартной историей.

На данном кластере мы остались на Reef: смешивать Ceph Squid с Proxmox-пакетами, которые пока что рассчитаны на Reef, не захотели. Поддержка Squid в 8.2 - это хорошо для новых инсталляций, но для действующих кластеров с Reef это скорее «можно попробовать», а не «пора мигрировать». Задокументируем миграцию, когда Proxmox выпустит нормальный upgrade path с тестированием на Squid.

SDN: небольшое, но заметное улучшение

В 8.2 улучшена интеграция SDN (Software Defined Networking) в части VXLAN-зон и управления маршрутами. Для нас это актуально, потому что сегментация сети КИИ и dev реализована через SDN-зоны прямо в Proxmox - без внешнего контроллера.

Конкретное улучшение, которое ощутили: стабилизировалось поведение при перезапуске ноды - SDN-конфигурация теперь применяется корректно без необходимости ручного pvesh set /cluster/sdn после загрузки. Раньше это иногда требовалось на одной из нод. Мелочь, но надоедало.

Про backup в разрезе КИИ

Требования 187-ФЗ и приказов ФСТЭК к резервному копированию для объектов КИИ - это не только «копии должны быть», но и контролируемое хранение, и задокументированная процедура восстановления, и периодическая проверка восстановления. Proxmox backup scheduler решает только планирование и хранение. Проверку восстановления он не автоматизирует - это отдельный процесс, который мы ведём вручную по расписанию.

Для сравнения: Veeam v12.1 умеет SureBackup с автоматической проверкой восстановимости. В Proxmox такого нет из коробки - тесты восстановления делаем скриптом, который поднимает ВМ из бэкапа в изолированной сети и проверяет доступность. Работает, но требует поддержки.

Где сейчас

Схема работает около двух недель. KII-prod job ни разу не провалился, dev-job один раз завис на одной ВМ с locked disk - разобрались, был незавершённый snapshot от другой операции. В целом разделение политик через теги оказалось удобнее, чем ожидали.

Если держите смешанный кластер под managed-сопровождением - тегирование ВМ по среде стоит заложить с самого начала, не потом. Retrofit идёт нормально, но разметить сотню ВМ задним числом - то ещё удовольствие.