server 24.03.2026 Евгений Семёнов

Proxmox Backup Server: установка, настройка и удалённый бэкап

Proxmox Backup Server — установка и настройка

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

PBS бесплатен и с открытым исходным кодом. Платная подписка даёт доступ к enterprise-репозиторию и техподдержку, но все функции доступны бесплатно.

Зачем нужен отдельный сервер бэкапов

Хранить бэкапы на том же сервере, где крутятся виртуальные машины — классика жанра, и мы это видели не раз. Сервер упал — потеряли всё: и данные, и копии разом. Пришёл шифровальщик — та же история, никаких шансов.

PBS закрывает эти дыры сразу несколькими механизмами:

Системные требования PBS

По железу PBS довольно скромен в плане CPU, но к дискам требователен — это надо учитывать при выборе сервера:

Для datastore рекомендуются ZFS-массивы (mirror или raidz1/raidz2) — PBS нативно поддерживает ZFS-снимки, что ускоряет операции и добавляет уровень защиты данных.

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

Установка PBS ничем не отличается от установки Proxmox VE — те же шаги, тот же подход:

  1. Скачайте ISO с proxmox.com/downloads
  2. Пишем на USB через Balena Etcher или утилиту dd — кому что привычнее
  3. Грузимся с USB, проходим мастер установки — там всё интуитивно
  4. Диск под ОС — рекомендую ZFS mirror, потеря загрузочного диска не должна убивать весь сервер бэкапов
  5. Сеть — только статический IP, никаких DHCP, иначе после перезагрузки роутера потеряете связь с хранилищем
# Альтернативная установка на существующий Debian 12
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 install proxmox-backup-server -y

После установки веб-интерфейс сразу доступен по адресу https://IP:8007.

Создание Datastore

Datastore — это каталог, в котором PBS физически хранит бэкапы. Прежде чем создавать его в интерфейсе, подготовьте файловую систему на нужном диске:

# Создание ZFS-пула для бэкапов
zpool create -f backup-pool mirror /dev/sdb /dev/sdc

# Создание файловой системы
zfs create backup-pool/datastore

# Создание точки монтирования
zfs set mountpoint=/mnt/backup-datastore backup-pool/datastore

Дальше в веб-интерфейсе: Datastore → Add Datastore, прописываем путь /mnt/backup-datastore — и готово.

Настройка Garbage Collection

Garbage Collection убирает «мусор» — блоки, которые после дедупликации уже никому не нужны. Без регулярного GC datastore будет пухнуть. Настройте расписание, обычно раз в сутки в ночное время, когда нагрузка минимальна:

# В веб-интерфейсе: Datastore → Options → Scheduling
# Или через CLI:
proxmox-backup-manager datastore update mystore \
  --gc-schedule "daily 03:00"

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

Теперь подключаем PBS к Proxmox VE. На стороне PVE-кластера:

  1. Идём в Datacenter → Storage → Add → Proxmox Backup Server
  2. Вписываем IP или имя PBS-сервера, порт 8007
  3. Указываем учётные данные — или лучше API-токен, так безопаснее
  4. Копируем Fingerprint сертификата с Dashboard PBS — без этого подключение не пройдёт
  5. Выбираем нужный Datastore
# Или через CLI на PVE:
pvesm add pbs pbs-storage \
  --server 10.0.0.10 \
  --port 8007 \
  --datastore mystore \
  --username backup@pbs \
  --password YOUR_PASSWORD \
  --fingerprint XX:XX:XX:...

Создание заданий бэкапа

Расписание бэкапов настраивается в Proxmox VE через Datacenter → Backup → Add:

Политика хранения (Retention)

Политика хранения в PBS гибкая, можно комбинировать несколько правил одновременно:

# Пример: 7 ежедневных + 4 еженедельных + 6 ежемесячных
keep-daily: 7
keep-weekly: 4
keep-monthly: 6
keep-yearly: 2

Итого выходит около 19 точек восстановления, которые покрывают горизонт в 2 года — не так много места, но хронологию восстановить можно.

Шифрование бэкапов

PBS поддерживает client-side encryption — то есть данные шифруются прямо на стороне Proxmox VE, ещё до передачи на сервер бэкапов:

# Генерация ключа шифрования
proxmox-backup-client key create /root/pbs-encryption-key.json

# Использование при бэкапе
proxmox-backup-client backup root.pxar:/ \
  --repository backup-server:mystore \
  --keyfile /root/pbs-encryption-key.json
Храните ключ шифрования в безопасном месте ОТДЕЛЬНО от PBS-сервера! Без ключа восстановление зашифрованных бэкапов невозможно. Рекомендуется Paper Key (распечатанный QR-код).

Удалённая синхронизация: правило 3-2-1

Хранить бэкапы только локально — полумера. Для реальной защиты нужна географически удалённая площадка. PBS поддерживает два режима репликации — Push и Pull, и у каждого своя логика:

Push Sync (локальный сервер → удалённый)

Push — локальный PBS сам «толкает» данные на удалённый сервер:

  1. На удалённом PBS: создаём datastore и заводим пользователя с правами DatastoreAdmin
  2. На локальном PBS: идём в Configuration → Remotes → Add Remote
  3. Прописываем Remote ID, адрес, учётные данные, fingerprint удалённого сервера
  4. Создаём Push Sync Job на нужном datastore
  5. Расписание и Rate Limit — обязательно, иначе синхронизация съест весь канал в самый неподходящий момент

Pull Sync (удалённый сервер ← локальный) — более безопасный

Pull — удалённый PBS сам вытягивает данные с локального. Это интереснее с точки зрения безопасности: локальный сервер вообще не знает адрес удалённого хранилища и не имеет туда доступа. Если локальный сервер взломали или зашифровали — удалённые бэкапы останутся нетронутыми.

  1. На локальном PBS: создаём пользователя с правами DatastoreReader — только чтение, никаких лишних привилегий
  2. На удалённом PBS: настраиваем Remote, который смотрит на локальный сервер
  3. Создаём Pull Sync Job — дальше удалённый PBS сам разберётся
Рекомендация: первую синхронизацию проведите, когда оба сервера в одной сети (до географического разнесения). Первый полный бэкап может занять сотни гигабайт — через интернет это дни ожидания.

Верификация бэкапов

Бэкап без проверки — это иллюзия безопасности, мы это проходили. PBS умеет проверять целостность автоматически, настройте это сразу:

# Настройка задания верификации
proxmox-backup-manager verify-job create daily-verify \
  --store mystore \
  --schedule "daily 06:00" \
  --outdated-after 7

Параметр outdated-after задаёт, через сколько дней бэкап считается непроверенным и требует внимания. В веб-интерфейсе статус верификации виден сразу по иконкам — удобно для ежедневного мониторинга.

Восстановление из бэкапов

Восстановление в PBS — не одна кнопка, а несколько сценариев под разные ситуации:

Полное восстановление VM

Самый частый сценарий — восстановление VM целиком. В Proxmox VE: правый клик на нужной машине → Restore → выбираем точку восстановления из PBS-хранилища. Занимает пару минут.

Гранулярное восстановление файлов

Одна из фишек PBS, за которую я особенно ценю этот инструмент, — можно залезть внутрь бэкапа и вытащить конкретный файл. Не нужно поднимать всю VM ради одного конфига или документа:

# Просмотр содержимого бэкапа
proxmox-backup-client catalog dump \
  --repository backup-server:mystore \
  vm/100/2025-03-24T01:00:00Z

# Восстановление отдельного файла
proxmox-backup-client restore \
  --repository backup-server:mystore \
  vm/100/2025-03-24T01:00:00Z drive-scsi0.img.fidx \
  /tmp/restored-disk.raw

Мониторинг и уведомления

PBS умеет слать письма о результатах бэкапов, GC и верификации. Настроить SMTP несложно, но без этого вы узнаете о проблеме только когда припрёт:

# Configuration → Notifications
# Или через конфиг:
# /etc/proxmox-backup/notifications.cfg

Если у вас уже есть Zabbix, Grafana или что-то своё — подключайте PBS через API:

# Получение статуса datastore через API
curl -k -H "Authorization: PBSAPIToken=user@pbs!token:UUID" \
  https://pbs-server:8007/api2/json/admin/datastore/mystore/status

Оптимизация производительности

Типичные проблемы и их решения

Бэкап зависает или работает медленно

Начните с трёх вещей: скорость дисков (fio), загруженность сети (iftop) и журнал GC — там часто видно, что datastore забит мусорными чанками, которые просто не успели почиститься.

Ошибка «verification failed»

Вариантов несколько: сбой диска, bitrot, повреждение файловой системы. Первым делом смотрите на ZFS: zpool status покажет общую картину, zpool scrub запустит проверку. Если сломан конкретный бэкап — проще удалить и снять заново, чем чинить.

Datastore быстро заполняется

Первое, что проверяю в таких случаях, — Retention. Бывает, что политика хранения слишком мягкая и старые бэкапы копятся годами. Убедитесь, что GC реально работает по расписанию, а не висит. Если место всё равно кончается — либо агрессивнее сжимайте, либо добавляйте диски.

Интеграция PBS с несколькими Proxmox VE кластерами

На практике почти всегда несколько Proxmox VE серверов или целых кластеров смотрят на один PBS. Мы сами так работаем у клиентов — это удобно, если правильно организовать структуру хранения с самого начала.

Структура datastore

Для каждого PVE-кластера или площадки лучше сделать отдельный datastore. Тогда retention, GC и синхронизация настраиваются независимо — и разбираться в чужих бэкапах не придётся:

# Создание отдельных датасторов
proxmox-backup-manager datastore create office-main \
  --path /mnt/backup/office-main \
  --gc-schedule "daily 03:00" \
  --comment "Главный офис — PVE кластер"

proxmox-backup-manager datastore create office-branch \
  --path /mnt/backup/office-branch \
  --gc-schedule "daily 04:00" \
  --comment "Филиал — отдельный PVE"

API-токены вместо паролей

Для автоматизации берите API-токены, не пароли. Токен можно ограничить конкретными правами и отозвать в любой момент, не меняя учётку:

# Создание пользователя для бэкапа
proxmox-backup-manager user create backup-office@pbs \
  --comment "Backup user for main office PVE"

# Создание API-токена
proxmox-backup-manager user generate-token backup-office@pbs office-token

# Назначение прав на конкретный datastore
proxmox-backup-manager acl update /datastore/office-main \
  DatastoreBackup --auth-id backup-office@pbs!office-token

Автоматизация с помощью скриптов

PBS идёт в комплекте с CLI-клиентом proxmox-backup-client. Он умеет бэкапить любой Linux-сервер, не только Proxmox VE — удобно, когда в инфраструктуре есть голые физические машины:

#!/bin/bash
# Скрипт ежедневного бэкапа физического Linux-сервера на PBS
# /usr/local/bin/pbs-backup.sh

REPO="backup-user@pbs@10.0.0.10:server-backups"
KEYFILE="/root/.pbs-encryption-key.json"

# Бэкап конфигурации
proxmox-backup-client backup \
  etc.pxar:/etc \
  --repository "$REPO" \
  --keyfile "$KEYFILE" \
  --backup-id "$(hostname)" \
  --backup-type host

# Бэкап данных
proxmox-backup-client backup \
  data.pxar:/var/lib/important-data \
  --repository "$REPO" \
  --keyfile "$KEYFILE" \
  --backup-id "$(hostname)-data" \
  --backup-type host

# Очистка старых бэкапов (оставить 7 ежедневных + 4 еженедельных)
proxmox-backup-client prune \
  --repository "$REPO" \
  --backup-id "$(hostname)" \
  --backup-type host \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

echo "Backup completed: $(date)"
# Добавление в cron
echo "0 2 * * * /usr/local/bin/pbs-backup.sh >> /var/log/pbs-backup.log 2>&1" \
  | crontab -

ZFS: лучший друг PBS

PBS и ZFS — это действительно удачная связка, не маркетинг. ZFS даёт то, что серверу бэкапов нужно по-настоящему:

# Рекомендуемая настройка ZFS для PBS
# Создание пула с RAIDZ1 (аналог RAID5)
zpool create -o ashift=12 backup-pool raidz1 /dev/sdb /dev/sdc /dev/sdd

# Включение сжатия
zfs set compression=zstd backup-pool

# Создание датасета с оптимальными параметрами
zfs create -o recordsize=64K backup-pool/pbs-store
zfs set atime=off backup-pool/pbs-store
zfs set xattr=sa backup-pool/pbs-store

# Настройка еженедельного scrub (проверка целостности)
cat > /etc/cron.d/zfs-scrub << 'EOF'
0 1 * * 0 root zpool scrub backup-pool
EOF

# Мониторинг состояния
zpool status -v backup-pool
zfs list -o name,used,avail,refer,compressratio

Планирование ёмкости хранилища

Хорошее планирование ёмкости — это когда datastore не заканчивается в 3 ночи в пятницу. Мы через это прошли. Вот формула, которую используем:

Пример из жизни: 10 виртуалок по 100 ГБ, итого 1 ТБ данных. С дедупликацией и инкрементами за месяц уходит 1.5-2 ТБ на datastore. Закладывайте 3-4 ТБ с запасом на год роста — потом скажете себе спасибо.

Настройте алерт на заполнение datastore выше 80%. В PBS: Configuration → Notifications. Или через внешний мониторинг: проверяйте вывод proxmox-backup-manager datastore list --output-format json и следите за полем used.

Сценарии аварийного восстановления

Бэкап сам по себе ничего не стоит. Ценность — в восстановлении. Проверяйте его регулярно, не ждите аварии.

Сценарий 1: Восстановление VM после сбоя диска

  1. Замените вышедший диск, поднимите Proxmox VE заново или переключитесь на резервный узел
  2. Подключите PBS-хранилище в Datacenter → Storage
  3. Выберите нужную VM и точку восстановления
  4. Restore — VM поднимется с новым VMID или перезапишет существующую, смотря что выберете

Сценарий 2: Восстановление отдельного файла из VM

Не нужно поднимать VM ради одного файла. В веб-интерфейсе PBS есть File Browser — открываете нужный бэкап, листаете файловую систему как в проводнике и скачиваете что нужно через Download.

Сценарий 3: Полная катастрофа — восстановление инфраструктуры с нуля

  1. Установите Proxmox VE на новое железо
  2. Если PBS на отдельном сервере — просто подключите его
  3. Если PBS жил на том же сервере — придётся восстанавливать его из удалённой копии (вот почему offsite-бэкап не опция, а обязательное условие)
  4. Восстанавливайте VM в порядке зависимостей: сначала DNS, потом AD/LDAP, затем базы данных и уже потом приложения
Проводите учебное восстановление минимум раз в квартал. Создайте документ «Runbook» с пошаговыми инструкциями для каждого сценария. Храните его вне инфраструктуры (распечатанный или в облаке).

Сравнение PBS с другими решениями для бэкапа

PBS — хороший выбор, но не единственный. Клиенты иногда спрашивают про альтернативы, и для части сценариев они действительно имеют смысл:

PBS vs Vzdump (встроенный бэкап PVE)

Vzdump — это встроенный в Proxmox VE механизм резервного копирования, который делает полные снимки VM и контейнеров. PBS тоже использует vzdump как транспорт, но поверх него добавляет инкрементальность и дедупликацию. Разница ощутимая: при 10 машинах по 100 ГБ каждый полный vzdump-бэкап съест 1 ТБ дискового пространства. PBS за целый месяц инкрементальных бэкапов потребует около 1.2 ТБ. Экономия — 5-10 раз. Мы в своё время именно из-за этой разницы и перешли на PBS.

PBS vs Veeam Backup for Proxmox

Veeam выпустил бесплатную Community Edition под Proxmox — и это действительно серьёзная заявка. Если у вас гетерогенная среда (VMware + Hyper-V + Proxmox вперемешку), богатый GUI и встроенная проверка восстанавливаемости SureBackup сделают жизнь проще. Но для чистого Proxmox-стека PBS выигрывает по всем фронтам: нативная интеграция с PVE, лучшая дедупликация, работа с ZFS-снимками и полностью открытый исходный код. Никаких лицензионных сюрпризов.

PBS vs Borg Backup

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

Безопасность PBS: защита от ransomware

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

Самая частая ошибка — хранить бэкапы на том же сервере с доступом из той же сети. При компрометации одного сервера злоумышленник получает доступ и к бэкапам. Всегда изолируйте PBS и используйте Pull Sync для удалённых копий.

Обновление и обслуживание PBS

PBS не требует постоянного внимания, но совсем забыть про него не получится. Есть несколько задач, которые нужно выполнять регулярно — иначе в какой-то момент бэкапы окажутся там, где их нет:

# Скрипт мониторинга здоровья PBS
#!/bin/bash
# /usr/local/bin/pbs-health-check.sh

echo "=== ZFS Pool Status ==="
zpool status -v

echo "=== Datastore Usage ==="
proxmox-backup-manager datastore list

echo "=== Last GC Results ==="
proxmox-backup-manager task list --typefilter garbage_collection --limit 3

echo "=== Last Verify Results ==="
proxmox-backup-manager task list --typefilter verify --limit 3

echo "=== Disk Health ==="
for disk in /dev/sd?; do
  echo "--- $disk ---"
  smartctl -H "$disk" 2>/dev/null | grep -i "result\|health"
done

FAQ: частые вопросы по Proxmox Backup Server

Можно ли использовать PBS без Proxmox VE?

Да, и это одна из недооценённых возможностей PBS. Клиент proxmox-backup-client работает на любом Linux — ставите пакет, прописываете хранилище и бэкапите что угодно: физические серверы, Docker-контейнеры, произвольные директории. Мы так бэкапим несколько bare-metal серверов клиентов прямо в тот же PBS, что и виртуалки.

PBS или Veeam — что выбрать?

Если инфраструктура построена на Proxmox — PBS. Без вариантов: бесплатен, нативно интегрирован с PVE, инкрементальные бэкапы с дедупликацией работают из коробки. Veeam имеет смысл, когда в зоопарке есть ещё VMware или Hyper-V и нужна единая консоль управления для всего этого хозяйства.

Какую файловую систему использовать для datastore?

ZFS — первый и основной выбор: нативная поддержка в PBS, снимки, checksums, самовосстановление при scrub. ext4 работает, мы проверяли, но теряете всё то, ради чего ZFS и стоит ставить. XFS — разумный компромисс, если по каким-то причинам ZFS не подходит, но объёмы большие.

Сколько места нужно под бэкапы?

Дедупликация меняет всю математику. На практике коэффициент 2-3x от объёма активных данных покрывает месяц инкрементальных бэкапов с запасом. Грубое правило: на 1 ТБ данных в VM выделяйте 2-3 ТБ под datastore. Точнее посчитаете после первых двух недель работы — PBS показывает реальный коэффициент дедупликации в интерфейсе.

Как защитить PBS от шифровальщика?

Пять обязательных пунктов: 1) изолированная сеть без доступа из пользовательского сегмента; 2) минимальные права — DatastoreReader для Pull Sync, не больше; 3) client-side encryption, чтобы даже администратор PBS не мог прочитать данные без ключа; 4) географически удалённая копия — желательно в другом здании или дата-центре; 5) учётные данные PBS отдельно от AD/LDAP, чтобы компрометация домена не давала доступа к бэкапам.

Поддерживает ли PBS бэкап Windows?

Напрямую — нет, PBS не понимает Windows на уровне агента. Но Windows VM, запущенные в Proxmox VE, бэкапятся штатно через QEMU Guest Agent — тут всё работает. С физическими Windows-серверами сложнее: proxmox-backup-client можно запустить в WSL2, либо использовать сторонние агенты. Не самое элегантное решение, если честно, но рабочее.

Можно ли мигрировать бэкапы с PBS на другой PBS?

Да. Sync Jobs в PBS поддерживают и Push, и Pull — настраивается через веб-интерфейс за пару минут. Если нужно перенести datastore целиком, можно опуститься на уровень файловой системы: rsync или zfs send/receive справятся.

IT-аутсорсинг для бизнеса

Нужна помощь с настройкой серверной инфраструктуры?

Компания ITfresh предоставляет полный спектр IT-услуг: от настройки серверов и систем резервного копирования до внедрения Kubernetes и почтовых решений. Более 10 лет опыта, сотни довольных клиентов.

10+лет опыта
500+проектов
24/7поддержка
Получить консультацию Позвонить

Читайте также