Proxmox Backup Server: установка, дедупликация, расписания и проверка восстановления в 2026 году

Proxmox Backup Server (PBS) хранит резервные копии виртуальных машин Proxmox VE и LXC-контейнеров в datastore, использует дедупликацию чанков, шифрование на стороне клиента, политики retention и автоматические задания проверки целостности. Рабочая схема состоит из отдельного PBS-сервера, подключенного хранилища, backup job в Proxmox VE, verify job, prune, garbage collection, уведомлений и регулярного тестового восстановления.

Успешное завершение backup подтверждает, что данные были записаны. Оно не доказывает, что виртуальная машина или контейнер действительно запустятся после сбоя. Поэтому приемка PBS должна включать восстановление VM и LXC в изолированную среду, проверку дисков, файловых систем, сети и прикладного сервиса. Команды ниже нужно сверять с major-версией PBS и Proxmox VE, установленной в инфраструктуре в 2026 году.

Что получится настроить в Proxmox Backup Server

Итоговая схема резервного копирования

Логическая цепочка выглядит так:

1. Proxmox VE запускает backup job по расписанию.
2. Гипервизор передает данные VM или LXC в PBS.
3. PBS разбивает поток на чанки, считает их хэши и сохраняет уникальные блоки в datastore.
4. Proxmox VE получает индекс резервной копии и статус задания.
5. PBS запускает verify job, который проверяет доступность и целостность данных.
6. Prune удаляет точки восстановления, которые больше не входят в retention-политику.
7. Garbage collection удаляет чанки, на которые больше не ссылается ни одна сохраненная точка.
8. Администратор периодически восстанавливает VM и LXC в тестовую среду.

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

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

Какие риски закрывает PBS

Подготовка сервера и хранилища для Proxmox Backup Server

Планирование емкости и пропускной способности

Емкость PBS нельзя рассчитывать только по сумме дисков виртуальных машин. На итоговый расход влияют объем занятых данных, число изменяемых блоков, частота backup, срок хранения, количество параллельных заданий, компрессия и фактический коэффициент дедупликации.

Для предварительной оценки используйте формулу:

объем PBS = изменяемые данные за период + полные уникальные данные + запас свободного места

В расчет нужно заложить минимум 20-30 процентов свободного пространства для служебных операций и пиковых нагрузок. Точный коэффициент дедупликации заранее неизвестен. Одинаковые блоки нескольких резервных копий могут храниться один раз, но базы данных, зашифрованные диски, сжатые архивы и активно изменяемые файлы часто дают меньшую экономию.

Пример: VM имеет виртуальный диск на 500 ГБ, но реально занято 120 ГБ. При ежедневном backup за 30 дней нужно учитывать не 500 ГБ, а объем занятых и изменяемых блоков, метаданные, retention и запас. Если за сутки меняется 8 ГБ, простая оценка изменения составит 240 ГБ, однако дедупликация и компрессия изменят фактический результат. Измерять его нужно после нескольких полных циклов.

Для небольшой лаборатории достаточно 4-8 ядер CPU, 16-32 ГБ RAM и гигабитной сети. Рабочая инсталляция с большим числом VM требует расчета по параллельным backup-задачам, скорости дисков и окну резервного копирования. NVMe или SSD полезны для metadata, индексов и интенсивных операций с чанками. HDD подходят для емкого datastore при приемлемом времени backup и restore.

Системный диск лучше отделить от datastore. Сбой или переполнение хранилища резервных копий не должны лишать сервер возможности загрузиться и открыть веб-интерфейс. ZFS дает контроль целостности и удобные средства мониторинга, но требует RAM, дисковой избыточности и грамотного планирования. Аппаратный RAID может быть оправдан при наличии качественного контроллера с защищенным кэшем. Не смешивайте несколько уровней дисковой избыточности без понятной причины.

Проверка сети, DNS и времени

PBS должен иметь стабильное имя узла, статический IP-адрес и корректную DNS-запись. Имя PBS должно разрешаться с узлов Proxmox VE. Обратное разрешение тоже полезно для диагностики и журналов.

hostnamectl
hostname -f
ip address
ip route
getent hosts pbs.example.internal
getent hosts pve01.example.internal
ping -c 3 pbs.example.internal
nc -vz pbs.example.internal 8007
timedatectl status
systemctl status systemd-timesyncd chrony --no-pager

Веб-интерфейс и API PBS обычно работают через TCP-порт 8007. Фильтрация должна разрешать доступ к нему только от управляющих узлов и административных сетей. При использовании jumbo frames проверяйте MTU на всем маршруте, иначе backup может завершаться нестабильно.

Время синхронизируйте через NTP. Расхождение часов осложняет анализ журналов, работу сертификатов и интерпретацию расписаний.

Proxmox Backup Server: установка на Debian и базовая настройка

Установка PBS и подключение официального репозитория

Для production-сервера удобнее использовать установочный ISO Proxmox Backup Server. Такой путь уменьшает число ручных шагов и сразу создает поддерживаемую базовую систему. Установка поверх Debian подходит, если организация уже использует стандартизированный образ и умеет сопровождать repository-конфигурацию.

Перед установкой определите major-версии PBS и Proxmox VE. Не смешивайте репозитории разных выпусков Debian и PBS. Проверьте модель поддержки, доступность обновлений и совместимость клиента Proxmox VE с сервером PBS.

Типовая последовательность для Debian выглядит так:

apt update
apt full-upgrade -y
apt install -y proxmox-backup-server proxmox-backup-client
systemctl enable --now proxmox-backup-proxy proxmox-backup
proxmox-backup-manager versions

Названия пакетов и состав сервисов могут отличаться между major-версиями. Если пакетный менеджер предлагает удалить базовые компоненты Debian или заменить критичные пакеты из другого выпуска, остановите установку и исправьте репозитории.

После установки задайте hostname, сетевой адрес и DNS. Установите обновления только из согласованного набора репозиториев. Для production желательно разделить тестовый и рабочий контуры и сначала проверить обновление на копии PBS.

Проверка сервисов и веб-интерфейса

systemctl status proxmox-backup-proxy --no-pager
systemctl status proxmox-backup --no-pager
journalctl -u proxmox-backup-proxy -b --no-pager
journalctl -u proxmox-backup -b --no-pager
proxmox-backup-manager versions
ss -lntp | grep 8007

Откройте веб-интерфейс PBS по адресу сервера с портом 8007 и проверьте:

• сертификат содержит имя, по которому Proxmox VE подключается к PBS;
• время на сервере синхронизировано;
• в журналах нет ошибок запуска proxy или API;
• системный диск и будущий datastore видны с ожидаемыми разделами и точками монтирования;
• обновления не оставили систему в частично настроенном состоянии.

Создание datastore и настройка дедупликации

Создание каталога и добавление datastore

Подготовьте отдельную файловую систему и смонтируйте ее постоянно. Пусть точка монтирования будет /backup/pbs.

mkdir -p /backup/pbs
findmnt /backup/pbs
df -hT /backup/pbs
lsblk -f

После настройки UUID или другого постоянного идентификатора в /etc/fstab проверьте монтирование:

mount -a
findmnt /backup/pbs
df -hT /backup/pbs

Добавить datastore можно в веб-интерфейсе PBS в разделе Datastore или через CLI. Пример:

proxmox-backup-manager datastore create backup01 /backup/pbs --comment "Основное хранилище PBS"
proxmox-backup-manager datastore list
proxmox-backup-manager datastore show backup01

Путь должен указывать на реально смонтированную файловую систему. Если mount point не подключился после перезагрузки, PBS может записать данные на системный диск. Это приводит к быстрому заполнению корневого раздела и усложняет восстановление.

Как проверить эффект дедупликации

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

В интерфейсе datastore анализируйте logical usage, chunk store usage и deduplication factor. Логический размер показывает объем данных резервных копий, а физическое использование отражает место, занятое чанками и служебными структурами.

proxmox-backup-manager datastore list
proxmox-backup-manager datastore status backup01

Снимайте показатели после нескольких полных циклов backup. Один запуск не показывает реальный коэффициент, особенно если в инфраструктуре мало повторяющихся данных или retention еще не сформировал историю точек восстановления.

Что происходит при удалении backup

Удаление точки восстановления или выполнение prune удаляет ссылки на backup, которые больше не нужны по политике хранения. Общие чанки могут продолжать использоваться другими точками. Поэтому свободное место в файловой системе часто появляется после garbage collection.

Дедупликация экономит место, но не заменяет retention, мониторинг и независимую копию datastore. Потеря самого datastore уничтожит все точки, которые хранились только на нем.

Пользователи, API-токены и минимальные права

Создание отдельного пользователя PBS

Подключайте Proxmox VE к PBS через отдельную учетную запись. Root-пароль не должен использоваться в автоматических заданиях и конфигурациях гипервизора.

В веб-интерфейсе PBS создайте пользователя в подходящем realm, например backup-sync@pbs. Затем назначьте ACL на конкретный datastore, а не на корень всей системы.

proxmox-backup-manager user create backup-sync@pbs
proxmox-backup-manager user list
proxmox-backup-manager acl list

Точные названия ролей зависят от сценария. Для backup-клиента нужны права на запись резервных копий и чтение статуса, а для restore-оператора потребуются дополнительные разрешения. Выдавайте их разным субъектам, если резервное копирование и восстановление выполняют разные команды.

Создание API-токена с ограниченной областью действия

API-токен состоит из идентификатора и секрета. Секрет показывается при создании, поэтому сохраните его в менеджере секретов сразу. В конфигурацию Proxmox VE передается секрет токена, а не пароль пользователя.

proxmox-backup-manager token create backup-sync@pbs pve01
proxmox-backup-manager token list backup-sync@pbs

Назначьте токену ACL только на нужный datastore и только на нужный набор операций. Отдельные токены полезны для разных кластеров, узлов и внешних скриптов. При компрометации отзывайте конкретный токен, не меняя все учетные данные PBS.

Ключ токена нельзя хранить в открытом репозитории, командной истории или общем файле с правами чтения для всех пользователей. После ротации проверьте backup job и тестовое подключение.

Проверка ACL и аудит доступа

Проверьте, что токен работает с нужным datastore и не получает доступ к соседним хранилищам.

proxmox-backup-manager acl list
proxmox-backup-manager user permissions backup-sync@pbs /datastore/backup01
proxmox-backup-manager task list

Сохраните в документации имя субъекта, область ACL, роль, владельца токена и дату последней проверки. Ошибка в ACL часто выглядит как проблема сети, поэтому проверяйте разрешения сразу после DNS, порта и сертификата.

Шифрование резервных копий и управление ключами

TLS-соединение между Proxmox VE и PBS

TLS защищает канал между Proxmox VE и PBS. Клиент должен подключаться по имени, которое соответствует сертификату, либо проверять доверенный fingerprint сервера.

При добавлении PBS storage в Proxmox VE укажите:

• hostname PBS;
• порт 8007;
• datastore;
• идентификатор пользователя или токена;
• fingerprint или доверенный сертификат;
• путь к ключу шифрования, если включаете клиентское шифрование.

Отключение проверки сертификата маскирует ошибки DNS и открывает возможность подключения к подмененному серверу. Для временной диагностики лучше проверить fingerprint и цепочку доверия, затем вернуть строгую проверку.

Ключи шифрования backup-данных

Клиентское шифрование защищает содержимое backup даже при чтении дисков PBS. Ключ создается и используется на стороне клиента, поэтому потеря ключа может сделать восстановление невозможным.

proxmox-backup-client key create /root/pbs-backup.key
proxmox-backup-client key show /root/pbs-backup.key

Команды и параметры нужно сверить с установленной версией клиента. Храните резервную копию ключа в независимом защищенном месте: например, в менеджере секретов с ограниченным доступом и отдельной офлайн-копии. Ключ на том же PBS-сервере не защищает от его полного уничтожения.

После настройки шифрования выполните тестовое восстановление. Проверьте, что оно проходит на другом узле или после временного отключения исходного Proxmox VE. Так вы обнаружите зависимость от локального файла ключа до аварии.

Retention, prune и garbage collection: политика хранения без сюрпризов

Как перевести RPO и срок хранения в retention-политику

RPO определяет допустимую потерю данных, а RTO показывает, за какое время сервис должен вернуться в работу. Эти параметры задают частоту backup, число точек и требования к restore-тестам.

Пример политики для рабочей VM:

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

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

Для домашней лаборатории может подойти более компактный вариант:

keep-last: 2
keep-daily: 7
keep-weekly: 4
keep-monthly: 3

Перед настройкой политики определите, какие данные нужно восстановить через час, день, неделю или месяц. Retention не должен съедать весь datastore: оставляйте запас под рост VM, временные пики и операции GC.

Настройка prune job

Prune job можно создать на уровне datastore через веб-интерфейс. Укажите datastore, retention-параметры и расписание, например запуск после завершения основного окна backup.

Перед автоматизацией выполните ручной расчет или dry-run, если он поддерживается вашей версией PBS. Сначала убедитесь, что список удаляемых точек соответствует требованиям бизнеса. Удаленную точку восстановления нельзя вернуть из PBS без другой копии.

proxmox-backup-manager prune-job list
proxmox-backup-manager task list
proxmox-backup-manager datastore status backup01

Запуск garbage collection и контроль места

Практический порядок операций: backup, prune, garbage collection. После prune PBS определяет чанки, которые больше не используются, а GC удаляет их и обновляет статистику.

proxmox-backup-manager garbage-collection start backup01
proxmox-backup-manager garbage-collection status backup01
df -hT /backup/pbs

Названия подкоманд могут отличаться между выпусками, поэтому сверяйте синтаксис с локальным help:

proxmox-backup-manager garbage-collection help

Запускайте GC вне пикового окна backup и отслеживайте I/O. Если свободное место не выросло, проверьте, что prune действительно удалил точки, а общие чанки не используются другими backup. Отдельно проверьте snapshots файловой системы, резервирование места и корректность mount point.

Расписания backup, verify jobs и уведомления

Настройка backup job в Proxmox VE

В Proxmox VE создайте backup job и выберите PBS datastore. Укажите VM и LXC, расписание, режим snapshot, compression и ограничение bandwidth при необходимости. Для production обычно выбирают окно, которое не пересекается с пиковыми задачами баз данных и интенсивными batch-процессами.

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

Пример порядка для трех VM:

1. Критичные VM с коротким RPO запускаются в начале окна.
2. Системы с высокой дисковой активностью получают отдельное окно или ограничение скорости.
3. Тестовые VM выполняются после production-задач.

Для баз данных snapshot гостевой системы не заменяет согласованный backup базы. Используйте native backup PostgreSQL, MySQL или другого СУБД и сохраняйте его в отдельный контур. Общую стратегию можно сверить с руководством по автоматическому резервному копированию сервера.

Проверка целостности через verify job

Verify job читает backup-данные и проверяет целостность чанков, индексов и связанных объектов. Это отдельная операция, ее нужно планировать регулярно, особенно для редко используемых архивных точек.

Создайте verify job в разделе Datastore, задайте расписание и ограничьте период, если полная проверка всех данных занимает слишком много времени. Для крупного хранилища распределяйте проверки по дням.

proxmox-backup-manager verify-job list
proxmox-backup-manager task list
journalctl -u proxmox-backup -b --no-pager

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

Уведомления об успехе и ошибках

Уведомления должны приходить при failed backup, failed verify, нехватке места и ошибках garbage collection. Уведомления об успехе полезны для критичных задач, но при большом количестве VM могут перегрузить почтовый канал.

Настройте email в PBS и Proxmox VE, затем отправьте тестовое сообщение. Для production передавайте статусы задач в систему мониторинга или централизованный syslog. Контролируйте минимум следующие показатели:

• последний успешный backup каждой критичной VM и LXC;
• возраст последней точки восстановления;
• результат verify job;
• свободное место datastore;
• статус prune и garbage collection;
• ошибки сертификатов, DNS и времени.

Обязательная проверка восстановления из PBS

Восстановление виртуальной машины в тестовую среду

Для restore-теста используйте отдельный узел Proxmox VE или изолированный VLAN. Не подключайте восстановленную VM к production-сети с исходным MAC-адресом и hostname.

1. Выберите backup критичной VM с известной датой.
2. Укажите тестовый узел и целевое хранилище.
3. Задайте новый VMID, если исходная VM доступна.
4. Восстановите диски и конфигурацию.
5. Назначьте уникальный MAC-адрес или отключите сетевой интерфейс до проверки.
6. Запустите VM и проверьте загрузчик, диски, файловые системы и системные журналы.
7. Проверьте запуск прикладного сервиса и тестовый запрос к нему.

Зафиксируйте время начала restore, время первого запуска ОС, время готовности сервиса и объем переданных данных. Эти значения формируют фактический RTO. Сравните их с требованиями системы.

Восстановление LXC-контейнера

Восстанавливайте LXC с новым CTID в изолированную сеть. После завершения проверьте конфигурацию контейнера, mount points, лимиты ресурсов, UID/GID, сетевой интерфейс и systemd-сервисы.

pct config <новый-CTID>
pct start <новый-CTID>
pct status <новый-CTID>
pct exec <новый-CTID> -- systemctl --failed
pct exec <новый-CTID> -- df -h

Особое внимание уделите bind mounts и внешним точкам монтирования. Их содержимое может не входить в обычный backup контейнера. Проверьте данные приложения, права доступа и доступность зависимостей.

Проверка зашифрованного backup

Выполните restore с сохраненным ключом шифрования в среде, которая не зависит от исходного узла. Проверьте, что ключ читается с резервного носителя, имеет правильные права и соответствует backup.

Сценарий проверки должен включать:

• получение ключа из независимого хранилища;
• подключение тестового Proxmox VE к PBS;
• выбор зашифрованной точки;
• восстановление VM или LXC;
• проверку запуска и прикладных данных;
• фиксацию результата и времени восстановления.

Если restore возможен только при наличии файла ключа на исходном гипервизоре, аварийная процедура не готова.

Регламент регулярного restore-теста

Критичные VM проверяйте ежемесячно или чаще, менее важные системы, минимум ежеквартально. После обновления PBS, Proxmox VE, ядра, дисковой системы или параметров шифрования запускайте внеплановый тест.

Чек-лист restore-теста:

• выбрана точка восстановления с известным временем;
• восстановление выполнено в изолированную среду;
• ОС загрузилась без критичных ошибок;
• диски и файловые системы доступны;
• сетевые параметры не конфликтуют с production;
• прикладной сервис запустился;
• тестовые данные читаются;
• измерены RTO и фактический RPO;
• результат, ошибки и ответственный записаны в журнал.

Для комплексного подхода сопоставьте этот процесс с руководством по резервному копированию и восстановлению в Linux.

Диагностика типовых проблем Proxmox Backup Server

Backup не запускается или завершается с ошибкой доступа

Проверяйте проблему по цепочке: DNS, TCP-порт 8007, fingerprint, realm, идентификатор пользователя, секрет токена, имя datastore и ACL. Не начинайте с выдачи root-доступа. Избыточные права скроют исходную ошибку и создадут лишний риск.

getent hosts pbs.example.internal
nc -vz pbs.example.internal 8007
proxmox-backup-manager user list
proxmox-backup-manager token list backup-sync@pbs
proxmox-backup-manager acl list
journalctl -u proxmox-backup-proxy -b --no-pager

Datastore заполнен, хотя старые backup удалены

Сначала проверьте, завершился ли prune. Затем запустите или дождитесь GC, убедитесь в отсутствии snapshots файловой системы и сравните использование datastore с реальным mount point. Отдельно проверьте, что PBS пишет в нужную файловую систему, а не в каталог на системном диске.

Verify job обнаружил поврежденные данные

Зафиксируйте время, идентификатор backup и полный журнал задания. Проверьте другие точки восстановления той же VM или LXC. Исследуйте SMART, ошибки контроллера, состояние ZFS или другой файловой системы и сообщения ядра.

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

Итоговый чек-лист настройки PBS в 2026 году

Критерии готовности к эксплуатации

• PBS размещен на отдельном сервере или отказоустойчивой платформе.
• Системный диск отделен от datastore.
• Настроены статический IP, DNS и NTP.
• Proxmox VE подключен по проверяемому TLS-сертификату.
• Создан datastore с понятной схемой хранения и запасом емкости.
• Backup job для VM и LXC завершается без ошибок.
• Используются отдельный пользователь или API-токен и минимальные ACL.
• Ключ шифрования сохранен в независимом защищенном месте.
• Настроены retention и prune job.
• Garbage collection выполняется после prune и контролируется.
• Создан verify job, а ошибки попадают администратору.
• Настроены email, syslog или интеграция с мониторингом.
• VM восстановлена в изолированную среду и прошла прикладную проверку.
• LXC восстановлен с проверкой mount points, сети и сервисов.
• Зафиксированы фактические RPO, RTO, владелец процедуры и дата последнего теста.

Что пересматривать после обновления PBS или Proxmox VE

После значимого обновления проверьте совместимость major-версий, статусы systemd-сервисов, сертификаты, права токенов, расписания, retention, verify jobs и параметры шифрования. Выполните тестовый backup и restore для VM и LXC.

Список изменений и результат проверки храните рядом с эксплуатационной документацией. Для обновлений гипервизора полезно использовать отдельный чек-лист безопасного обновления информационных систем.

Proxmox Backup Server готов к эксплуатации, когда резервные копии создаются по расписанию, чанки проверяются, старые точки удаляются по согласованной политике, уведомления доходят, а VM и LXC действительно восстанавливаются в заданное время.

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