Proxmox Backup Server: политика резервного копирования, исключения, проверка и тестовое восстановление

Практическая схема для PBS: охват резервным копированием, сроки хранения, prune и GC, проверка целостности, тестовые восстановления и документированные исключения.

Проверено на: Proxmox VE 9.x · Proxmox Backup Server 4.x · VM and CT backups

Контекст

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

Политика резервного копирования должна явно отвечать на вопросы:

• какие VM и CT обязаны резервироваться;
• какие системы исключены намеренно;
• как часто создаются точки восстановления;
• сколько времени они хранятся;
• когда реально освобождается место после удаления старых снимков;
• проверяется ли целостность сохранённых данных;
• выполнялось ли реальное тестовое восстановление;
• какие риски восстановления приняты осознанно.

Proxmox Backup Server предоставляет отдельные механизмы для резервного копирования, удаления старых точек, garbage collection и проверки целостности. Их нужно рассматривать как части одной эксплуатационной политики, а не как независимые задания в интерфейсе.

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

Сначала определите охват

Не начинайте проектирование с параметров retention. Сначала классифицируйте нагрузки.

Практичный вариант:

Важно не название класса, а то, что у каждой VM или CT есть явный статус.

Система без определённого статуса — это не осознанное исключение, а пробел в политике.

Ведите реестр исключений

Некоторые системы действительно не требуют регулярного копирования в PBS. Это нормально, если решение принято осознанно.

Типичные примеры:

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

Для каждого исключения фиксируйте минимум:

Так отсутствие VM в задании PBS превращается из случайности в управляемое решение по риску.

Успешная копия не гарантирует консистентность приложения

Успешно завершённая задача Proxmox подтверждает, что гипервизор создал резервную копию. Это не означает автоматически, что каждое приложение внутри гостевой ОС получило транзакционно согласованную точку восстановления.

QEMU Guest Agent может улучшить согласованность файловой системы Windows и Linux. Но базы данных и другие транзакционные системы могут дополнительно требовать:

• собственных backup-механизмов;
• dump;
• WAL/binlog;
• специальных процедур восстановления приложения.

Разделяйте два вопроса:

1. можно ли восстановить VM или CT;
2. сможет ли приложение внутри неё корректно восстановиться до нужного состояния.

Зелёная задача PBS лучше отвечает на первый вопрос, чем на второй.

Определяйте расписание через RPO

Не используйте одно расписание для всех систем, если требования отличаются.

Пример:

Расписание должно соответствовать требованиям восстановления, а не только доступному месту на datastore.

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

Частота копирования и retention — разные вещи

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

PBS поддерживает, в частности:

• keep-last;
• keep-hourly;
• keep-daily;
• keep-weekly;
• keep-monthly;
• keep-yearly.

Пример:

keep-last:    6
keep-daily:   14
keep-weekly:  8
keep-monthly: 12

Это не универсальная рекомендация. Сроки хранения должны определяться требованиями бизнеса и реальной ёмкостью datastore.

Prune и garbage collection — разные операции

prune удаляет точки восстановления согласно политике хранения.

garbage collection освобождает chunks, которые больше не используются ни одной сохранённой точкой восстановления, с учётом защитных правил PBS.

То есть:

prune != немедленное освобождение места

После prune старые backup snapshots могут уже исчезнуть из списка, а занятое место почти не изменится до завершения GC.

Это особенно важно при дефиците свободного пространства.

Проверяйте задания PBS через CLI

На PBS можно посмотреть текущую конфигурацию:

proxmox-backup-manager datastore list
proxmox-backup-manager prune-job list
proxmox-backup-manager garbage-collection list
proxmox-backup-manager verify-job list

Удаление старых точек, освобождение места и проверка целостности — разные эксплуатационные процессы. Их нужно контролировать отдельно.

Проектируйте prune осознанно

Политика prune должна соответствовать частоте создания резервных копий.

Если VM резервируется каждый день, но после prune остаётся только одна точка в неделю, фактическая плотность доступных точек восстановления становится недельной.

При изменении retention:

1. оцените, сколько точек останется;
2. проверьте, нет ли важных вручную сохранённых точек;
3. крупные изменения сначала проверьте на некритичных данных;
4. изучите результат prune;
5. дождитесь GC и только после этого оценивайте высвобождённое место.

Во время storage-инцидента не меняйте retention вслепую: можно удалить единственную полезную точку восстановления.

Планируйте GC после prune

Логичная последовательность обслуживания:

backup jobs -> prune -> garbage collection -> verification

Точные интервалы зависят от длительности задач и производительности datastore.

Не запускайте все тяжёлые операции одновременно, если они конкурируют за I/O.

Проверка GC:

proxmox-backup-manager garbage-collection list

Для конкретного datastore:

proxmox-backup-manager garbage-collection status <datastore>
proxmox-backup-manager garbage-collection start <datastore>

Ручной запуск GC должен быть осознанным действием, а не автоматической реакцией на любое изменение свободного места.

Verification — проверка целостности

Задания verify проверяют сохранённые данные и позволяют обнаружить повреждение до момента реального восстановления.

proxmox-backup-manager verify-job list

Ручной запуск конкретного задания:

proxmox-backup-manager verify-job run <job-id>

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

Verification не заменяет тест восстановления

Проверенная резервная копия надёжнее копии, которую после создания никто не читал. Но verification не доказывает, что восстановленная ОС и приложение реально запустятся.

Тест восстановления должен подтвердить:

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

Verification и restore test решают разные задачи и дополняют друг друга.

Тестируйте восстановление на представительных системах

Не ждите реального аварийного случая, чтобы впервые проверить процедуру.

Полезно периодически восстанавливать:

• одну Windows VM;
• одну Linux VM;
• один container;
• workload с большим виртуальным диском;
• сервис со специфическими требованиями к консистентности приложения.

Восстанавливайте копию под временным VMID или CTID. До загрузки изолируйте сеть, если возможны конфликты IP, доменного членства или production-сервисов.

Для VM можно использовать qmrestore:

qmrestore <backup-volume> <temporary-vmid> --storage <target-storage>

Точный идентификатор backup volume лучше брать из фактического содержимого storage, а не собирать вручную.

Измеряйте фактический RTO

Для тестового восстановления фиксируйте время этапов:

T0  объявлено восстановление
T1  найдена нужная резервная копия
T2  начато восстановление
T3  восстановление VM/CT завершено
T4  гостевая ОС загрузилась
T5  приложение проверено

Так появляется измеренный RTO, а не предположение.

Если восстановление слишком долгое, причина может быть в сети, целевом storage, конкурирующей нагрузке или просто в нереалистичном RTO.

Перепроверяйте охват после изменений инфраструктуры

Покрытие резервным копированием часто ломается не из-за PBS, а потому что инфраструктура меняется быстрее расписаний.

Повторная проверка нужна, когда:

• появилась новая VM или CT;
• тестовая система стала production;
• шаблон превратился в постоянный сервер;
• VM переехала в другой кластер;
• изменились storage или PBS credentials;
• прежнее исключение больше не оправдано.

Не рассчитывайте на «добавим потом по памяти».

Ошибка backup для критичной системы — это инцидент

Регулярно падающую задачу нельзя считать обычным шумом.

Проверяйте отдельно:

• guest lock или другую активную задачу;
• недоступность storage;
• сетевые ошибки;
• проблемы аутентификации или прав PBS;
• snapshot/QEMU Guest Agent;
• нехватку места на datastore;
• наложение maintenance jobs;
• проблемы исходного storage.

Исправляйте причину, а не просто перезапускайте задачу до первого зелёного результата.

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

Из-за дедупликации логический размер резервных копий и фактический рост datastore не совпадают.

Это усложняет простые расчёты, но не означает, что место бесконечно.

Отслеживайте:

• физически занятое место;
• скорость роста за последние периоды;
• сколько места освободил GC;
• количество сохранённых точек;
• появление крупных новых VM;
• изменения retention.

Если datastore регулярно удаётся спасти только срочным GC, это уже проблема планирования ёмкости.

Защищайте сам PBS

PBS — часть цепочки восстановления. Он не должен полностью разделять те же точки отказа, что и защищаемый кластер.

Желательно разделять:

• административные учётные данные;
• storage failure domain;
• сетевой путь;
• административный доступ;
• мониторинг и оповещения.

Если модель риска требует, используйте второй PBS, remote sync или отдельную offline/offsite-копию.

Один PBS остаётся единой точкой отказа системы резервного копирования, даже если данные внутри него дедуплицируются и проходят verification.

Offsite-копия и вторая копия — не одно и то же

Локальный PBS хорошо защищает от отказов VM, узла или кластера. Но он не обязательно защищает от:

• потери площадки;
• ransomware с административным доступом;
• одновременного уничтожения основного и резервного storage.

PBS поддерживает синхронизацию datastore на другой backup server.

Ключевое различие:

backup copy != независимая disaster-recovery copy

Если offsite-защиты нет, это нужно явно записать как остаточный риск.

Исключения с принятым риском

Исключение допустимо только если:

• система идентифицирована;
• причина документирована;
• способ восстановления известен;
• допустимая потеря данных понятна;
• у решения есть владелец;
• исключение периодически пересматривается.

Нормальный пример — одноразовая тестовая VM или сервис, полностью воспроизводимый из version-controlled automation.

Плохой пример — «никто не добавил в backup job».

Шаблоны и архивные системы

Шаблоны и архивные VM часто требуют отдельного подхода.

Если шаблон можно воспроизвести из установочного образа, cloud-init, automation и списка пакетов, редкого или ручного резервного копирования может быть достаточно.

Если архивная VM содержит уникальные исторические данные, низкая runtime-criticality не означает низкую ценность резервной копии.

Классифицируйте системы по восстанавливаемости и ценности данных, а не по загрузке CPU.

Резервное копирование на уровне приложения

PBS должен дополняться средствами самого приложения там, где это улучшает восстановление.

Примеры:

• PostgreSQL base backup + WAL;
• логические дампы баз данных;
• экспорт конфигурации Mailcow или другого сервиса;
• процедуры восстановления directory services;
• файловые копии с отдельным сроком хранения.

Это дополнительный уровень защиты, а не требование дублировать каждый механизм для каждой VM.

Минимальная эксплуатационная проверка

Периодически отвечайте на вопросы:

Все production-системы классифицированы?
Все исключения всё ещё осознанны?
Плановые backup jobs проходят успешно?
Prune сохраняет нужную историю?
Garbage collection завершается нормально?
Verify jobs проходят успешно?
Недавно выполнялось реальное тестовое восстановление?
Рост datastore остаётся в ожидаемых пределах?
Риск отсутствия offsite/second copy рассмотрен явно?

Это полезнее простого просмотра времени последней резервной копии.

Условия остановки

Не меняйте retention и не удаляйте точки восстановления, если:

• владелец сервиса не может подтвердить, какие исторические точки ещё нужны;
• verification показывает необъяснимые ошибки;
• datastore или underlying filesystem нездоров;
• активные backup jobs продолжают писать в этот datastore;
• новая prune-policy удалит единственную известную рабочую точку;
• процедура восстановления критичной системы никогда не тестировалась.

При дефиците места освобождение storage не всегда важнее сохранения единственной пригодной точки восстановления.

Что сохранять по результатам восстановления

Для критичных тестов и реальных восстановлений фиксируйте:

• время исходной backup-точки;
• PBS datastore и namespace;
• целевое хранилище;
• время начала и окончания восстановления;
• результат загрузки VM/CT;
• результат проверки приложения;
• ручные шаги;
• фактический RTO;
• фактический разрыв относительно требуемого RPO.

Так восстановление перестаёт быть «знанием одного администратора» и превращается в проверяемую эксплуатационную процедуру.

Рабочая схема

Практичная политика PBS выглядит так:

классифицировать системы
  -> задать расписание
  -> документировать исключения
  -> применять prune
  -> выполнять GC
  -> проверять целостность
  -> тестировать восстановление
  -> пересматривать принятые риски

Главный признак зрелой системы — не «все backup jobs зелёные», а понимание того, что именно защищено, что намеренно не защищено и сколько реально занимает проверенное восстановление.

References

• Proxmox Backup Server documentation: https://pbs.proxmox.com/docs/
• Proxmox Backup Server Administration Guide: https://pbs.proxmox.com/docs/proxmox-backup.pdf
• Proxmox VE backup and restore documentation: https://pve.proxmox.com/pve-docs/chapter-vzdump.html