Proxmox Backup Server, или PBS, работает как отдельная система резервного копирования для виртуальных машин QEMU и контейнеров LXC. В продуктивной инфраструктуре его размещают за пределами защищаемого кластера Proxmox VE, чтобы отказ узлов виртуализации не затронул хранилище копий. PBS разбивает данные на чанки, сравнивает их по контрольным суммам и повторно использует уже сохраненные фрагменты. Поэтому после начальной копии по сети обычно передаются только новые данные, а восстановление доступно как для всей гостевой системы, так и для отдельных файлов. Такая схема сокращает резервное окно и одновременно сохраняет независимый контур восстановления.
Отдельно от Proxmox VE PBS нужен именно потому, что хранить бэкапы на том же кластере, который они защищают, рискованно: при отказе узла или всего кластера резервные копии могут стать недоступны одновременно с оригиналом. Вынесенный datastore уменьшает зависимость копий от продуктивного кластера. Хранение и проверка чанков выполняются на отдельном сервере, но чтение исходных данных по-прежнему нагружает узлы виртуализации. Этот ресурс нужно учитывать при выборе расписания.
Что такое Proxmox Backup Server и зачем он нужен отдельно от Proxmox VE
Proxmox Backup Server решает задачу, для которой в Proxmox VE нет встроенного инструмента такого уровня: централизованное хранение бэкапов с дедупликацией и шифрованием на стороне клиента. Отдельная функция PBS — плановая проверка целостности данных, которой в базовом функционале Proxmox VE тоже нет. Без PBS резервные копии в Proxmox VE делают простым экспортом образа диска целиком — это работает, но не масштабируется на десятки виртуальных машин из-за объема данных и отсутствия дедупликации между заданиями.
Proxmox Backup Server решает эту задачу как самостоятельная система с собственным хранилищем и политиками доступа.
Клиентское шифрование AES-256-GCM нужно включить при настройке хранилища PBS в Proxmox VE. Тогда содержимое копии шифруется на узле виртуализации до отправки и остается зашифрованным на сервере хранения. Сохраните ключ отдельно от защищаемого кластера и проверьте доступ к нему: без ключа восстановить такую копию не получится. Проверка целостности файлов на PBS не заменяет пробное восстановление с расшифровкой.
Требования к серверу под datastore
Под datastore Proxmox Backup Server достаточно скромного сервера: от 4 ядер процессора и 8 ГБ оперативной памяти для небольшой инфраструктуры до 10–20 виртуальных машин. Дисковую подсистему стоит планировать отдельно от процессора и памяти — дедупликация на лету создает интенсивную нагрузку на IOPS, и на HDD при большом числе одновременных заданий бэкапа сервер начинает захлебываться.
SSD или NVMe особенно важны при частых заданиях и большом числе виртуальных машин. На HDD проверка целостности может упереться в число операций ввода-вывода и не уложиться в резервное окно. Объем хранилища рассчитывают по суммарному размеру защищаемых машин и глубине retention-политики. Влияет и дедупликация: чем больше машин используют одинаковую ОС и набор пакетов, тем больше совпадающих блоков PBS хранит в единственном экземпляре.
При расчете нагрузки учитывайте обе стороны соединения. Сервер под Proxmox VE должен успевать читать диски гостевых систем и передавать изменившиеся данные, а отдельный узел PBS должен принимать этот поток без длительной очереди записи. Проверьте оба узла на пилотном задании до выбора окончательной конфигурации.
Установка и первичная настройка PBS
Вы устанавливаете Proxmox Backup Server на отдельный физический сервер или в виртуальную машину за пределами защищаемого узла. Резервная копия должна оставаться доступной при отказе продуктивной платформы. Установка идет через ISO-образ с собственным облегченным дистрибутивом на базе Debian, либо через пакет поверх уже настроенной системы.
После установки первичная настройка сводится к нескольким шагам: указать сетевые параметры и задать пароль администратора. Дальше остается открыть веб-интерфейс управления на порту 8007 и продолжить настройку уже там. В веб-интерфейсе администратор создает пользователей и API-токены для подключения Proxmox VE — использовать root-доступ для повседневных заданий бэкапа не стоит, отдельный токен с ограниченными правами снижает риск при компрометации одного из узлов кластера.
Создание datastore и подключение к Proxmox VE
В интерфейсе PBS откройте Datastore, выберите Add Datastore и укажите имя и путь к каталогу. Локальный каталог на ZFS дает предсказуемую производительность без сетевой задержки до внешнего хранилища. Ресурсы NFS и CIFS сначала монтируют в ОС сервера, затем создают datastore поверх этой точки как поверх локального каталога. В актуальных версиях PBS доступен и backend для S3-совместимого объектного хранилища с локальным кешем.
После создания datastore подключите его в Proxmox VE как новое хранилище резервных копий: укажите адрес PBS и токен доступа, затем выберите нужный datastore из списка. С этого момента задания резервного копирования на кластере Proxmox VE видят PBS как обычную точку назначения для бэкапов, наравне с локальным хранилищем.
Выбирайте оборудование для резервного копирования с учетом емкости datastore и скорости восстановления. До первого задания проверьте права на каталог и доступность точки монтирования после перезагрузки. Если используется внешнее хранилище, его отказ не должен приводить к незаметной записи чанков на системный диск PBS.
Настройка заданий резервного копирования и расписания
Резервное копирование Proxmox настройте в интерфейсе Proxmox VE: Datacenter → Backup → Add. Выберите хранилище PBS и гостевые системы, затем задайте время запуска в поле Schedule. Планировщик использует календарные выражения, похожие на формат systemd, поэтому обычную строку cron нельзя переносить без проверки синтаксиса. Разнесите задания разных узлов по времени и ограничьте скорость передачи при необходимости, чтобы ночной бэкап не мешал рабочим приложениям.
Для работающих QEMU-машин действующая dirty bitmap отмечает блоки, измененные после предыдущей копии, и сокращает объем повторного чтения. Если карта отсутствует или признана недействительной, данные придется прочитать заново, но дедупликация по-прежнему исключит повторную передачу уже сохраненных чанков. Для LXC-контейнеров PBS использует pxar-архивы с контентным разбиением на чанки и клиентской дедупликацией. Снепшот файловой системы при его наличии отвечает за согласованное состояние контейнера, но не заменяет механизм определения и передачи изменившихся данных.
Retention-политики и дедупликация
В PBS сроки хранения задаются правилами keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly и keep-yearly. Политику выбирают по допустимой точке возврата, а не по свободному месту на дисках. Например, для сервиса средней критичности можно сохранять семь дневных и четыре недельные версии, если такой горизонт подтвержден владельцем системы. Практический результат дает только правило, связанное с требованиями бизнеса к восстановлению.
Экономия места строится на повторном использовании одинаковых фрагментов данных. Образы QEMU разделяются на блоки фиксированного размера, а файловые архивы pxar используют динамическое разбиение. Хеш каждого чанка позволяет не записывать уже имеющийся фрагмент повторно, в том числе между копиями разных гостевых систем. Реальный коэффициент зависит от сходства ОС и приложений, поэтому емкость datastore лучше рассчитывать по результатам пилотного периода.
После удаления устаревших снимков данные освобождаются не мгновенно. Задание garbage collection ищет чанки, на которые больше не ссылается ни одна действующая резервная копия, и затем очищает datastore. Его запускают по расписанию и контролируют по журналу, иначе формально настроенная retention-политика не гарантирует своевременное высвобождение пространства.
Проверка целостности и восстановление данных
В PBS откройте вкладку Verify Jobs выбранного datastore и создайте задание проверки целостности. Для новых копий настройте регулярную проверку, например ежедневную, а все сохраненные копии повторно проверяйте не реже раза в месяц. Это разные настройки: ожидание 30 дней перед первой проверкой оставляет свежие ошибки незамеченными. Результат задания проверьте в журнале и настройте уведомление при сбое.
Восстановление в PBS доступно на двух уровнях: разворачивание всей виртуальной машины из выбранной точки бэкапа или точечное восстановление отдельного файла без запуска всей машины целиком. Второй вариант особенно полезен, когда пользователь случайно удалил документ или перезаписал конфигурационный файл — не нужно поднимать резервную копию всей системы, чтобы вернуть один файл.
Дополнительно администратор настраивает уведомления по email при ошибке verification job или самого задания бэкапа, так команда узнает о сбое вскоре после задания и сможет отреагировать до следующей плановой проверки.
Чек-лист перед запуском
- Выделите отдельный узел хранения и проверьте запас производительности на пилотной нагрузке;
- Настройте datastore и сроки хранения, затем проверьте выполнение очистки неиспользуемых чанков;
- Запустите пробное задание и восстановите гостевую систему в изолированной сети;
- Проверьте уведомления об ошибках и сохранность ключа шифрования вне защищаемого кластера.
При масштабировании PBS его включают в общую систему резервного копирования компании с согласованными сроками хранения и процедурами восстановления. Такой подход связывает конфигурацию datastore с реальными требованиями к доступности данных.