Proxmox Backup Server: настройка системы резервирования виртуальных машин

Proxmox Backup Server (PBS) - это отдельный продукт на базе Debian, который хранит резервные копии виртуальных машин, контейнеров и физических серверов с дедупликацией и проверкой целостности. Встроенные средства Proxmox VE со своей задачей справляются, но при росте инфраструктуры упираются в потолок: длинные окна копирования, отсутствие дедупликации, невозможность достать из копии один файл. PBS эти ограничения снимает.

Архитектура, которая работает

PBS разворачивают и на физическом сервере, и в виртуальной машине. Главное отличие от встроенных инструментов - архитектура, спроектированная под работу именно с резервными копиями.

Система работает по схеме клиент-сервер. PBS выступает централизованным репозиторием, хосты Proxmox VE отправляют туда данные. Копирование виртуальных машин идёт безагентно, через API гипервизора, с использованием моментальных снимков: машины продолжают работать, останавливать сервисы не нужно.

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

Установка и базовая настройка

Установка PBS не сложнее развёртывания обычного Debian-сервера. Скачиваете ISO с сайта Proxmox, записываете на флешку, загружаетесь. Инсталлятор проведёт через стандартные шаги: выбор диска, сетевые настройки, пароль root.

После установки получаете систему с веб-интерфейсом на порту 8007. Первым делом создаём datastore - хранилище для резервных копий:

Datastore → Add Datastore
Name: backup-storage
Path: /mnt/datastore/main

Под datastore выделяйте отдельный диск или массив. PBS интенсивно работает с дисковой подсистемой, особенно во время верификации и сборки мусора. SSD ускорит эти операции, но и обычные HDD справятся - просто дольше.

Подключение к Proxmox VE

Интеграция происходит через веб-интерфейс, занимает пару минут, но есть нюанс с правами.

Сначала на стороне PBS создаём пользователя:

Configuration → Access Control → User Management
Username: backup@pbs
Password: [надёжный пароль]

Назначаем ему права на datastore:

Permissions → Add → User Permission
User: backup@pbs
Datastore: backup-storage
Role: DatastoreBackup

Роль DatastoreBackup даёт право создавать копии, но не удалять чужие - для учётной записи, под которой ходит гипервизор, этого достаточно. Полный доступ ей не нужен, и давать его не стоит: если хост скомпрометируют, с правами на удаление злоумышленник вычистит и копии.

Теперь в Proxmox VE добавляем PBS как хранилище:

Datacenter → Storage → Add → Proxmox Backup Server
ID: pbs-main
Server: 192.168.1.100
Username: backup@pbs
Datastore: backup-storage

При добавлении PVE попросит отпечаток сертификата PBS - его берут в веб-интерфейсе PBS в разделе Dashboard, кнопка Show Fingerprint. После добавления хранилище появится во всех диалогах резервного копирования.

Организация резервного копирования

PBS поддерживает полные и инкрементные копии, но за счёт дедупликации даже полная копия занимает немного: повторяющиеся блоки не пишутся заново.

Расписание настраивается на стороне Proxmox VE:

Datacenter → Backup → Add
Storage: pbs-main
Schedule: 02:00
Selection mode: All
Mode: Snapshot

Режим Snapshot обеспечивает консистентность на уровне диска. Для машин с установленным QEMU Guest Agent стоит включить соответствующую опцию в настройках ВМ: перед снимком гипервизор попросит агента заморозить файловые системы (fsfreeze), а сразу после - разморозить. Это даёт консистентность уже на уровне файловой системы, а не одного лишь блочного устройства. Агент есть и для Linux, и для Windows, и в обоих случаях его стоит поставить.

Где Proxmox хранит резервные копии

Вопрос, который возникает первым, когда копии уже настроены, а найти их надо руками.

Встроенный бэкап PVE (vzdump). По умолчанию копии складываются в каталог /var/lib/vz/dump/ на том узле, где выполнялось задание. Это путь хранилища local, идущего в комплекте. Файлы называются по схеме vzdump-qemu--<дата>.vma.zst для виртуальных машин и vzdump-lxc--<дата>.tar.zst для контейнеров. Последнее расширение зависит от выбранного сжатия: .zst, .gz или .lzo, а без сжатия его не будет вовсе.

Как узнать свой путь, если хранилище не дефолтное. В веб-интерфейсе: Datacenter → Storage, найдите строку, у которой в колонке Content указано «VZDump backup file», и посмотрите Path. Настройки хранилищ лежат в файле /etc/pve/storage.cfg - там же виден и каталог, и тип.

Копии в PBS. Здесь файлов в привычном виде нет. Данные разложены по чанкам внутри каталога datastore (в нашем примере /mnt/datastore/main), и лазить туда файловым менеджером бессмысленно: собрать из чанков образ можно только средствами PBS. Список копий смотрят в веб-интерфейсе PBS в разделе Content нужного datastore либо командой на клиенте:

proxmox-backup-client snapshot list --repository backup@pbs@192.168.1.100:backup-storage

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

Оптимизация хранения

Здесь важно не перепутать два инструмента, и путаница эта распространённая.

Настраивать в PBS стоит другое - политику хранения. Управление старыми копиями идёт через prune-правила:

Комбинируя метки, легко получить схему «дед-отец-сын» или любую другую. Важный момент: prune только помечает копии на удаление, а место освобождает сборка мусора (Garbage Collection), и запускать её надо отдельно. Пока GC не отработала, свободного места на диске не прибавится - на этом регулярно спотыкаются.

proxmox-backup-client: копии физических серверов и отдельных папок

Виртуальными машинами PBS не ограничивается. Клиент proxmox-backup-client ставится на обычный Linux-сервер и копирует его файловую систему в тот же datastore - удобно, когда часть парка живёт вне гипервизора.

Чтобы не повторять адрес репозитория в каждой команде, его удобно положить в переменную окружения:

export PBS_REPOSITORY=backup@pbs@192.168.1.100:backup-storage

Копирование каталога выглядит так:

proxmox-backup-client backup root.pxar:/ --repository backup@pbs@192.168.1.100:backup-storage

Здесь root.pxar - имя архива внутри копии, а / - что именно копируем. Можно указать несколько источников в одной команде, каждый со своим именем архива.

Формат адреса репозитория - пользователь@область@сервер:datastore. Область pbs означает встроенную базу пользователей PBS; если подключена доменная аутентификация, область будет другой.

Про Windows. Официальный клиент Proxmox поставляет для Linux, пакетами для Debian и Ubuntu. Windows-машины, работающие как виртуальные, копируются на уровне гипервизора и клиента не требуют вовсе - там достаточно QEMU Guest Agent для консистентного снимка. Для физического Windows-сервера PBS - не тот инструмент, и подбирать под эту задачу стоит что-то другое.

Восстановление данных

Гибкость восстановления - то, ради чего PBS ставят.

Вся машина целиком. В интерфейсе Proxmox VE выбираете нужную копию и нажимаете Restore. Процесс идентичен работе с локальными копиями. Восстановить можно и на другой узел кластера, и с другим VMID - последнее полезно, когда надо поднять копию рядом с работающей машиной, чтобы что-то из неё достать.

Отдельные файлы. В веб-интерфейсе PBS есть File Restore: система монтирует образ диска и отдаёт нужное на скачивание через браузер. Это самый частый сценарий в реальной жизни - пользователь удалил документ, и разворачивать ради него всю машину не нужно.

Через командную строку. Полная форма команды выглядит так:

proxmox-backup-client restore vm/100/2026-01-15T02:00:00Z drive-scsi0.img restored.raw \
  --repository backup@pbs@192.168.1.100:backup-storage

Разберём аргументы: vm/100/2026-01-15T02:00:00Z - это снимок (тип, идентификатор машины, метка времени), drive-scsi0.img - имя архива внутри снимка, restored.raw - куда положить результат. Ключ --repository обязателен - без него команда завершится ошибкой, если только адрес не задан переменной PBS_REPOSITORY. Имена доступных снимков и архивов смотрят командой snapshot list из раздела выше.

Мониторинг и обслуживание

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

Три задачи, которые надо поставить на расписание:

• Garbage Collection - освобождает место, занятое чанками, на которые больше никто не ссылается. Без неё удаление копий место не вернёт.
• Verification - перечитывает данные и сверяет контрольные суммы. Именно она отвечает на вопрос «а восстановится ли», не дожидаясь аварии.
• Prune - применяет политику хранения и помечает лишние копии.

Запускать их лучше в период минимальной нагрузки: обе первые заметно нагружают диски.

Отдельно настройте уведомления. PBS умеет слать почту о результатах заданий, и это тот случай, когда молчание должно означать «всё хорошо», а не «письма настроить забыли».

Безопасность системы резервирования

PBS поддерживает сквозное шифрование: данные шифруются на клиенте до отправки. Даже получив доступ к серверу, без ключа копии прочитать нельзя.

При работе через Proxmox VE ключом управляют в настройках хранилища - в диалоге добавления PBS есть поле Encryption Key, где ключ либо генерируется, либо загружается готовый. Для клиента на отдельной машине ключ создают командой proxmox-backup-client key create с указанием пути к файлу.

Дополнительные меры, которые стоят недорого:

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

Последний пункт стоит повторить: если шифровальщик добрался до хоста PVE, он попробует добраться и до хранилища копий. Разграничение прав здесь работает лучше любого антивируса.

Сравнение с альтернативами

PBS - не единственный вариант. Veeam, Кибер Бэкап, Bacula решают ту же задачу иначе.

PBS выигрывает в нативной интеграции с Proxmox VE и в отсутствии лицензионных платежей. Veeam сильнее в разнородных средах, где кроме Proxmox есть VMware или Hyper-V. Bacula гибче в настройке, но требует понимания её архитектуры и заметно большего времени на запуск.

Для инфраструктуры целиком на Proxmox выбор обычно очевиден: PBS даёт максимум возможностей при минимуме времени на настройку. Если же гипервизор пока не выбран, сравнение платформ есть в отдельном разборе - сравнение гипервизоров.

Практические рекомендации

Не кладите datastore на то же хранилище, где живут виртуальные машины. Это создаёт конкуренцию за операции ввода-вывода и замедляет обе системы. А при отказе этого хранилища вы теряете и машины, и копии одновременно.

Настройте синхронизацию между двумя PBS. Задание Sync Job копирует данные на удалённый сервер автоматически. Это защита и от отказа основного хранилища, и от шифровальщика, если у приёмника нет доступа на запись к источнику.

Следите за свободным местом. PBS не удаляет старые копии сам, если места не хватает для новых, - задание просто упадёт. Поставьте оповещение при заполнении на 80%, останется время расширить или почистить.

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

Сколько ресурсов заложить под сам PBS и под хранилище копий, считается по объёму и глубине хранения - ориентиры есть в разборе про сервер под резервное копирование, а требования к железу под сам гипервизор - в статье про системные требования Proxmox. Про то, как собрать под всё это отказоустойчивый массив, разобрано в материале про RAID в Proxmox. А если место закончилось прямо сейчас - есть отдельная инструкция, как удалить старые резервные копии.

Частые вопросы

PBS - это что такое простыми словами?
Proxmox Backup Server - отдельный сервер с собственной системой, который принимает и хранит резервные копии от хостов Proxmox VE и от обычных Linux-машин. Хранит с дедупликацией, шифрованием и проверкой целостности, управляется через веб-интерфейс на порту 8007.

Где по умолчанию хранятся резервные копии Proxmox?
Копии встроенного механизма vzdump лежат в /var/lib/vz/dump/ на том узле, где выполнялось задание. Копии в PBS хранятся внутри datastore в виде чанков, и добраться до них можно только средствами PBS - через веб-интерфейс или proxmox-backup-client.

Можно ли поставить PBS на тот же сервер, что и Proxmox VE?
Технически да, в том числе в виртуальной машине. Практически это лишает смысла саму затею: отказ одного сервера унесёт и рабочие машины, и копии. Как временное решение на время тестов - допустимо, как постоянное - нет.

Как остановить запущенное задание резервного копирования?
В интерфейсе Proxmox VE задача видна в списке Tasks, там же есть кнопка Stop. Прерванная копия останется в PBS как незавершённая и будет убрана сборкой мусора.

Почему после удаления копий не освободилось место?
Prune только помечает копии на удаление. Физически место освобождает Garbage Collection, и до её запуска занятый объём не изменится. Поставьте GC на расписание.

Нужен ли отдельный агент для копирования виртуальных машин?
Нет. Виртуальные машины копируются через API гипервизора, агент не нужен. QEMU Guest Agent ставят для другого - чтобы снимок был консистентным на уровне файловой системы, а не одного лишь диска.