Proxmox Backup Server: настройка и восстановление на практике

MAATRIX

Снапшот перед обновлением спасает от неудачного апдейта, но не спасает, если сгорел диск или контроллер хранилища — снапшот живёт на том же томе, что и сама машина. Proxmox Backup Server (PBS) закрывает именно эту дыру: отдельное хранилище, дедупликация на уровне блоков и — что чаще всего забывают — реально работающий процесс восстановления, а не только кнопка «создать бэкап». Разберём обе половины: как настроить и как потом действительно достать данные обратно.

Зачем отдельный PBS, если уже есть снапшоты и vzdump

У Proxmox VE есть встроенный vzdump, который умеет складывать полные архивы VM в обычное хранилище (NFS, локальный диск, CIFS). Он рабочий, но у него нет дедупликации: каждый полный бэкап — это полный архив, и десять копий 100-гигабайтной машины — это условно терабайт места, даже если между бэкапами поменялось 200 МБ данных.

Снапшот QCOW2/LVM-thin — это вообще не бэкап в строгом смысле, а слепок состояния диска с ростом цепочки copy-on-write и деградацией производительности со временем. Он живёт на том же сторадже, что и продакшн-диск: если умер массив или контроллер, снапшот умирает вместе с оригиналом. Это инструмент для «откатить неудачное обновление за пять минут», а не для катастроф.

PBS — специализированный демон, который хранит бэкапы отдельно (физически другой сервер, желательно другая площадка) и режет каждый диск на чанки переменного размера (обычно 1–4 МБ), считает SHA-256 от содержимого и хранит уникальный чанк один раз, даже если он встречается в десятках полных бэкапов разных VM. Отсюда два практических следствия: место экономится кратно, а «полный» бэкап после первого раза идёт по сети и по диску почти как инкрементальный.

Важный принцип, который PBS не решает сам по себе, — это разнесение копий физически. Если PBS стоит на том же гипервизоре, что и VM, вы получаете защиту от «человек нажал не туда в интерфейсе», но не от «сдох сервер». Для реальной защиты датастор PBS должен жить на отдельном железе или хотя бы на отдельном физическом диске/контроллере, а в идеале — вообще в другой локации.

Установка Proxmox Backup Server

PBS ставится либо с официального ISO как отдельная ОС, либо поверх Debian 12 (Bookworm) как пакет — второй вариант удобен, если у вас уже есть арендованный сервер под бэкапы и не хочется переустанавливать систему.

Установка поверх готового Debian 12:

# добавляем репозиторий PBS (no-subscription — без коммерческой подписки)
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs.list

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
  -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

apt update && apt full-upgrade -y
apt install -y proxmox-backup-server

После установки веб-интерфейс доступен на https://<ip-сервера>:8007, логин по умолчанию — root@pam с системным паролем root. Первым делом создаём датастор — отдельный раздел (лучше отдельный физический диск), куда будут писаться чанки:

# смотрим доступные диски
proxmox-backup-manager disk list

# форматируем и монтируем под датастор одной командой
proxmox-backup-manager disk fs create backup-disk --disk sdb --filesystem ext4

# создаём сам датастор поверх смонтированного пути
proxmox-backup-manager datastore create store1 /mnt/datastore/backup-disk

Дальше стоит завести отдельного пользователя вместо использования root — на случай, если у злоумышленника окажется доступ к Proxmox VE, он не должен автоматически получать root на бэкап-сервере:

proxmox-backup-manager user create backup@pbs --password 'сложный-пароль'
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id backup@pbs

Ещё лучше — выпустить API-токен вместо пароля (proxmox-backup-manager user generate-token backup@pbs backup-token) и использовать его при подключении из Proxmox VE: токен легко отозвать, не трогая пароль.

Подключение PBS к Proxmox VE и расписание бэкапов

В интерфейсе Proxmox VE: Datacenter → Storage → Add → Proxmox Backup Server. Нужны четыре вещи:

• ID — произвольное имя хранилища внутри Proxmox VE, например pbs-remote;
• Server — IP или хостнейм сервера PBS;
• Datastore — имя, которое вы дали при создании (store1 из примера выше);
• Username / Password (или API Token) — backup@pbs и пароль, либо backup@pbs!backup-token с секретом токена.

При первом подключении Proxmox VE спросит fingerprint сертификата PBS — его можно посмотреть на самом PBS в Dashboard → Certificate или командой proxmox-backup-manager cert info. Сверьте, что fingerprint совпадает с тем, что показывает сама панель PBS, а не берите его из письма или чата — это защита от подмены сервера.

После добавления хранилища создаём задание бэкапа: Datacenter → Backup → Add.

• Node / VM — выбираем конкретные машины или «все VM на ноде»;
• Storage — указываем добавленный pbs-remote;
• Schedule — можно выбрать пресет (daily, weekly) или задать calendar-событие вручную, например 02:30 для ежедневного запуска в полтретьего ночи;
• Mode — Snapshot для VM с включённым QEMU guest agent (бэкап без остановки машины), Suspend или Stop, если агента нет и нужна гарантированная консистентность.

Отдельным блоком настраивается retention (политика хранения) — сколько копий держать и по какому графику ротации:

Эта комбинация (3 последних + неделя ежедневных + месяц еженедельных + квартал ежемесячных) — разумный старт для большинства продакшн-VM: свежие точки восстановления детальные, старые — редеют, но не исчезают совсем.

Важная деталь, которую легко упустить: сам PBS не удаляет чанки сразу при удалении старого бэкапа по retention — сначала снимается «индекс» бэкапа, а реальное освобождение места чанков происходит при запуске Garbage Collection (Datastore → Prune & GC, или proxmox-backup-manager gc start store1). Без регулярного GC датастор будет расти, даже если retention вроде бы всё почистил.

Дедупликация на уровне блоков: как PBS экономит место

Наивный полный бэкап копирует весь диск заново при каждом запуске: 100 ГБ VM с ежедневным бэкапом за месяц — это условно 3 ТБ хранилища. PBS режет диск на чанки, считает хэш каждого и сверяет с уже сохранёнными: если чанк уже есть в датасторе (неважно, от этой VM или от другой — дедупликация глобальная в рамках датастора), записывается только ссылка на него, а не сами данные.

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

Экономия сильно зависит от характера нагрузки: базы данных со случайной перезаписью блоков дедуплицируются хуже, чем условные веб-серверы со статикой и логами. Ориентировочно для типичного набора VM (ОС + приложение + логи) экономия по сравнению с наивным полным копированием может быть в разы — но это ориентир, а не гарантия: для вашей конкретной нагрузки цифра будет другой, и её стоит посмотреть в Datastore → Summary, где PBS показывает реальный процент дедупликации.

Отдельно стоит включить периодическую верификацию датастора (Datastore → Verify Jobs) — задание, которое перечитывает чанки и проверяет их контрольные суммы. Дедупликация — это ценность только пока чанк цел; без верификации повреждённый на диске чанк обнаружится в худший момент — при попытке восстановления.

Восстановление VM целиком из PBS

Это тот раздел, который часто выпадает из инструкций «настроили бэкап и на этом всё». Разворачивание из PBS в интерфейсе Proxmox VE:

1. Заходим в pbs-remote → Backups, там список всех сохранённых снапшотов по VMID и датам.
2. Выбираем нужный снапшот, нажимаем Restore.
3. Указываем VMID — можно восстановить поверх исходной машины (тот же ID) или в новую (это как раз способ проверить бэкап, не трогая продакшн — подробнее про перенос VM между железом здесь).
4. Выбираем целевое хранилище дисков (может отличаться от исходного) и нажимаем Restore.

Из командной строки то же самое делается через qmrestore:

# восстановить снапшот в новую VM с ID 9999 на локальное хранилище local-lvm
qmrestore pbs-remote:backup/vm/100/2026-08-15T02:30:00Z 9999 --storage local-lvm

# восстановление поверх существующей VM (осторожно — перезаписывает диски)
qmrestore pbs-remote:backup/vm/100/2026-08-15T02:30:00Z 100 --storage local-lvm --force

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

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

Разворачивать всю VM ради одного случайно удалённого конфига или таблицы — избыточно. PBS умеет File Restore: в списке бэкапов у каждого снапшота есть кнопка с иконкой файлов — она поднимает временную служебную VM (использует встроенный минимальный образ), которая монтирует образ диска из бэкапа и отдаёт файловый браузер прямо в окне Proxmox VE. Там можно пройтись по файловой системе (поддерживаются ext4, xfs, NTFS и другие распространённые ФС) и скачать нужный файл или папку архивом, не трогая исходную VM и не разворачивая её копию.

Для более гибких сценариев (например, восстановление на другой сервер или скриптовая автоматизация) есть CLI-путь через proxmox-backup-client, установленный на любой машине с сетевым доступом к PBS:

# список файлов внутри конкретного бэкапа
proxmox-backup-client catalog dump vm/100/2026-08-15T02:30:00Z --repository backup@pbs@pbs-remote:store1

# смонтировать образ диска из бэкапа локально (нужен ключ шифрования, если бэкап зашифрован)
proxmox-backup-client mount vm/100/2026-08-15T02:30:00Z drive-scsi0.img.fidx /mnt/restore \
  --repository backup@pbs@pbs-remote:store1

Дальше /mnt/restore — обычная точка монтирования, откуда можно скопировать что угодно cp/rsync.

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

Практика, которая реально работает: раз в месяц (для критичных систем — чаще) брать случайный продакшн-бэкап и разворачивать его в новую VM с другим VMID в изолированном сегменте сети, проверять, что машина стартует, сервисы поднимаются и данные на месте, и только после этого удалять тестовую копию. Это занимает 15–30 минут и один раз в квартал реально спасает от ситуации «бэкап был, а восстановиться не вышло». Фиксируйте время восстановления каждого такого теста — это ваш реальный RTO, а не тот, что написан в презентации.

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