Proxmox Backup Server: ставим, настраиваем, не теряем ВМ

Proxmox Backup Server: установка, настройка, бэкап ВМ и Windows — полный рецепт
Состав рецепта
  • Диагноз — почему «снапшот раз в месяц» это не бэкап
  • Причины — откуда берётся боль при бэкапах в Proxmox VE
  • Рецепт — установка PBS, подключение к PVE, настройка backup job для ВМ и контейнеров
  • PBS Agent для Windows-машин
  • Хранение бэкапов на S3 (Tape → S3 offload)
  • Мониторинг PBS через Zabbix
  • Как скачать, остановить и восстановить бэкап
  • Осложнения — топ ошибок и как их лечить

1. ДИАГНОЗ

У тебя Proxmox VE с десятком виртуалок, и бэкапы «настроены». По факту — это папка /var/lib/vz/dump/ на том же диске, куда пишутся ВМ. Или того лучше: снапшот раз в неделю, который живёт на том же хосте. Диск умрёт — и прощай, и ВМ, и бэкап одновременно.

Или другой классический сценарий: бэкапы есть, но восстановление никто не проверял с момента настройки. А это значит, бэкапов нет — есть просто большие файлы непонятного содержания.

Правило трёх: 3 копии, 2 разных носителя, 1 офсайт. Бэкап на том же сервере — это не бэкап, это иллюзия спокойствия.

Proxmox Backup Server (PBS) — это отдельный продукт от той же команды, который решает проблему нормально: дедупликация, инкрементальные бэкапы, проверка целостности, веб-интерфейс, интеграция с PVE из коробки. И всё это бесплатно.

Обещание: После этого рецепта у тебя будет рабочий Proxmox Backup Server, подключённый к PVE, с расписанием бэкапов виртуалок (включая Windows), retention policy и пониманием, как всё это восстановить. Время — 40–60 минут на чистой установке.

2. ПРИЧИНЫ — ПОЧЕМУ БОЛИТ

  • Бэкапы в /var/lib/vz/dump/ — это не решение. Тот же хост, тот же диск. RAID не поможет — он защищает от отказа диска, но не от «rm -rf», крипто-локера или пожара в стойке.
  • Стандартный vzdump без PBS — нет дедупликации. Полный бэкап 100GB-диска каждый день = 700 GB в неделю. Место заканчивается быстрее, чем ты думаешь.
  • Windows-ВМ без агента бэкапятся грязно. Без PBS Agent снапшот делается на уровне блочного устройства, NTFS может быть в несогласованном состоянии. С агентом — VSS, всё чисто.
  • Нет мониторинга — нет бэкапов. Бэкап-джоб упал в 3 ночи с ошибкой, ты узнаешь об этом при попытке восстановиться через три месяца.
  • Retention policy никто не настраивает. Диск заполняется, новые бэкапы не пишутся, старые не удаляются — полный паралич.

3. РЕЦЕПТ

Архитектура за 30 секунд

Два варианта развёртывания:

  • PBS на отдельном физическом сервере — правильно, бэкапы физически изолированы от PVE-хостов.
  • PBS как ВМ на PVE — допустимо для старта и тестов, но помни: если хост умрёт вместе с ВМ — бэкапы недоступны. Дай PBS отдельный диск через passthrough.
Минимальные требования PBS: 2 ядра CPU, 2 GB RAM (лучше 4+), 64-bit x86. Диск для хранения — отдельно от системного, желательно XFS или ZFS. Debian 12 Bookworm под капотом.

Шаг 1. Установка Proxmox Backup Server

Вариант A — установка с ISO (рекомендую)

Скачай актуальный ISO с официального сайта:

# Актуальная <a href="https://it-apteka.com/windows-12-data-vyhoda-versii-64-bit-i-chto-izvestno-v-2026-godu/" title="Windows 12 — дата выхода, версии, 64 bit и что известно в 2026 году" target="_blank" rel="noopener"  data-wpil-monitor-id="1194">версия на момент написания —</a> PBS 3.x
# https://www.proxmox.com/en/downloads/proxmox-backup-server
# Записываешь на USB (Ventoy, Rufus, dd) — и устанавливаешь как обычный Debian

Установка стандартная — выбираешь диск для системы (не для хранилища бэкапов!), задаёшь hostname, IP, пароль root. После перезагрузки:

# Открываешь в браузере:
https://IP_СЕРВЕРА:8007
# Логин: root
# Пароль: тот, что задал при установке

Вариант B — установка на существующий Debian 12

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

# Добавляем ключ
wget -qO- https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
  | gpg --dearmor \
  > /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

# Обновляем и ставим
apt update && apt install -y proxmox-backup-server

# Запускаем
systemctl enable --now proxmox-backup

# Проверяем статус
systemctl status proxmox-backup proxmox-backup-proxy
No-subscription репозиторий — полностью функциональный, без ограничений. Subscription-репозиторий даёт приоритетные обновления и поддержку. Для домашней лабы и небольших компаний no-subscription — нормально.

Шаг 2. Первичная настройка хранилища (Datastore)

Datastore — это директория на сервере, куда пишутся бэкапы. Создаём через веб-интерфейс или командой.

Через CLI

# Смотрим доступные диски
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

# Если диск /dev/sdb ещё не размечен — форматируем под XFS (рекомендую для PBS)
parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary xfs 0% 100%
mkfs.xfs /dev/sdb1

# Монтируем
mkdir -p /mnt/backup-store
echo "/dev/sdb1 /mnt/backup-store xfs defaults,nofail 0 2" >> /etc/fstab
mount -a

# Проверяем
df -h /mnt/backup-store
# Создаём datastore через CLI
proxmox-backup-manager datastore create main /mnt/backup-store \
  --comment "Основное хранилище бэкапов"

# Проверяем
proxmox-backup-manager datastore list

Через веб-интерфейс

Administration → Storage / Disks → Datastore → Create. Указываешь имя и путь. PBS сам инициализирует структуру директорий.

Retention Policy — сразу, не потом

# Настройка через CLI: хранить 7 ежедневных, 4 еженедельных, 3 ежемесячных
proxmox-backup-manager datastore update main \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3 \
  --keep-last 3

# Или через веб: Administration → Datastore → main → Options → Prune Schedule
Prune vs GC: Prune — удаляет старые снапшоты по политике. Garbage Collection — физически освобождает место от удалённых чанков. Prune без GC — место не освобождается. Настрой оба по расписанию.
# Расписание GC — раз в день в 2:30
proxmox-backup-manager datastore update main \
  --gc-schedule "02:30"

# Расписание Prune — раз в день в 3:00
proxmox-backup-manager datastore update main \
  --prune-schedule "03:00"

Шаг 3. Создание пользователя для PVE

Не используй root для подключения PVE к PBS. Создай отдельного пользователя с минимальными правами.

# Создаём пользователя (в PBS используется realm @pbs)
proxmox-backup-manager user create pve-backup@pbs \
  --password "СложныйПароль123!" \
  --comment "Пользователь для подключения PVE"

# Создаём API token (рекомендую вместо пароля)
proxmox-backup-manager user generate-token pve-backup@pbs pve-token

# Сохрани токен! Он показывается ОДИН РАЗ.
# Формат: pve-backup@pbs!pve-token = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
[/bash>

[bash]
# Выдаём права на datastore
proxmox-backup-manager acl update /datastore/main \
  --auth-id "pve-backup@pbs!pve-token" \
  --role DatastoreBackup

# Если нужно восстановление тоже — роль DatastoreAdmin или DatastoreAudit+DatastoreRestore

Роли PBS для справки:

Роль Что может
DatastoreAdmin Всё, включая удаление бэкапов
DatastoreBackup Только писать бэкапы (для PVE-подключения)
DatastoreAudit Только читать/просматривать
DatastoreReader Чтение и восстановление
RemoteAdmin Управление remote-репозиторием

Шаг 4. Подключение PBS к Proxmox VE

Теперь идём на PVE-хост (или в веб-интерфейс PVE).

Через веб-интерфейс PVE

  1. Datacenter → Storage → Add → Proxmox Backup Server
  2. Заполняем:
    • ID — любое имя, например pbs-main
    • Server — IP или hostname PBS-сервера
    • Usernamepve-backup@pbs (или токен в формате pve-backup@pbs!pve-token)
    • Password / Token — значение токена
    • Datastoremain (имя созданного datastore)
    • Fingerprint — скопируй с PBS: Dashboard → Show Fingerprint

Fingerprint PBS — где взять

# На PBS-сервере:
proxmox-backup-manager cert info | grep "Fingerprint"

# Или через API:
curl -sk https://localhost:8007/api2/json/nodes/localhost/certificates \
  | python3 -m json.tool | grep fingerprint

Через CLI на PVE-хосте

pvesm add pbs pbs-main \
  --server IP_PBS_СЕРВЕРА \
  --datastore main \
  --username "pve-backup@pbs!pve-token" \
  --password "ЗНАЧЕНИЕ_ТОКЕНА" \
  --fingerprint "XX:XX:XX:..." \
  --content backup

# Проверяем
pvesm status
pvesm list pbs-main

Шаг 5. Настройка Backup Job для ВМ и контейнеров

Через веб-интерфейс PVE

  1. Datacenter → Backup → Add
  2. Настраиваем:
    • Storagepbs-main
    • Schedule — например, 02:00 (каждый день в 2 ночи)
    • Selection — All (все ВМ) или выбираем конкретные
    • Mode — Snapshot (онлайн, без остановки), Suspend, Stop
    • Compression — zstd (быстро и хорошо сжимает)
    • Send email to — твой email для уведомлений об ошибках

Через CLI на PVE-хосте

# Бэкап всех ВМ и CT каждую ночь в 02:00, хранение по retention PBS
pvesh create /cluster/backup \
  --storage pbs-main \
  --schedule "02:00" \
  --all 1 \
  --mode snapshot \
  --compress zstd \
  --mailnotification always \
  --mailto admin@example.com

# Посмотреть все backup jobs
pvesh get /cluster/backup

Ручной запуск бэкапа — прямо сейчас

# Бэкап конкретной ВМ (например, vmid 101) на PBS
vzdump 101 --storage pbs-main --mode snapshot --compress zstd

# Бэкап нескольких ВМ
vzdump 101 102 103 --storage pbs-main --mode snapshot --compress zstd

# Бэкап всех ВМ на ноде
vzdump --all --storage pbs-main --mode snapshot --compress zstd

# С подробным выводом
vzdump 101 --storage pbs-main --mode snapshot --compress zstd --verbose 1

Остановить текущий бэкап

# Найти PID процесса vzdump
pgrep -a vzdump

# Остановить через API PVE
pvesh get /nodes/$(hostname)/tasks | grep vzdump
# Найди UPID задачи и:
pvesh delete /nodes/$(hostname)/tasks/UPID:...

# Или грубо, через kill (не рекомендую без крайней необходимости):
pkill -f vzdump

Шаг 6. PBS Agent для Windows-виртуалок

Без агента бэкап Windows-ВМ — это снапшот блочного устройства. Файловая система может быть в несогласованном состоянии (незафлашенные буферы, открытые транзакции БД). С агентом — используется VSS (Volume Shadow Copy Service), всё чисто и консистентно.

Установка агента на Windows

# Скачать с PBS-сервера или с официального сайта:
# https://www.proxmox.com/en/downloads/proxmox-backup-client
# Файл: proxmox-backup-client_X.X.X_amd64.msi (для Windows)
  1. Скачай MSI-установщик с официального сайта Proxmox или с твоего PBS по адресу: https://IP_PBS:8007/ → Downloads.
  2. Запусти установщик на Windows-ВМ с правами администратора.
  3. После установки служба Proxmox Backup Agent запускается автоматически.

Настройка агента

На Windows-ВМ открываем PowerShell (от администратора):

# Проверяем статус службы
Get-Service "ProxmoxBackupAgent"

# Если не запущена:
Start-Service "ProxmoxBackupAgent"
Set-Service "ProxmoxBackupAgent" -StartupType Automatic

В PVE при настройке backup job включи опцию Guest Agent (или флаг --agent в vzdump). PVE сам обнаружит агент и задействует VSS-снапшот.

# Бэкап Windows-ВМ с использованием агента
vzdump 105 --storage pbs-main --mode snapshot --compress zstd --agent 1
Важно: Агент работает только в режиме snapshot. В режимах stop и suspend он не нужен — ВМ остановлена, диск консистентен и без агента.

Шаг 7. Подключение S3 как дополнительного хранилища (offload)

PBS не умеет писать напрямую в S3 — он работает только с локальными директориями. Но никто не мешает смонтировать S3 как файловую систему через s3fs или rclone и использовать это как datastore. Это offload-вариант: PBS пишет в локальный datastore, а потом ты переносишь старые бэкапы на S3.

Вариант A — rclone mount (рекомендую)

# Устанавливаем rclone
apt install -y rclone fuse3

# Настраиваем подключение к S3 (интерактивно)
rclone config
# Выбираем: n (new remote), вводим имя "s3backup"
# Тип: s3
# Provider: выбираешь своего провайдера (AWS, Yandex, Selectel, и т.д.)
# access_key_id, secret_access_key — из консоли провайдера
[/bash>

[bash]
# Создаём точку монтирования
mkdir -p /mnt/s3-backup

# Создаём systemd-unit для автомонтирования
cat > /etc/systemd/system/rclone-s3.service << 'EOF'
[Unit]
Description=RClone S3 Mount for PBS
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount s3backup:ИМЯ_БАКЕТА /mnt/s3-backup \
  --vfs-cache-mode writes \
  --allow-other \
  --dir-cache-time 72h \
  --log-level INFO \
  --log-file /var/log/rclone-s3.log
ExecStop=/bin/fusermount -u /mnt/s3-backup
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now rclone-s3
systemctl status rclone-s3
# Добавляем S3-директорию как datastore в PBS
proxmox-backup-manager datastore create s3-offload /mnt/s3-backup \
  --comment "S3 offload storage"

# Настройка retention для S3 (хранить дольше)
proxmox-backup-manager datastore update s3-offload \
  --keep-monthly 12 \
  --keep-yearly 3

Вариант B — скрипт синхронизации локальный PBS → S3

#!/bin/bash
# sync-pbs-to-s3.sh — синхронизация старых бэкапов на S3
# Запускать из cron: 0 4 * * 0 /opt/scripts/sync-pbs-to-s3.sh

SOURCE="/mnt/backup-store"
DEST="s3backup:ИМЯ_БАКЕТА/pbs-backup"
LOG="/var/log/pbs-s3-sync.log"

echo "$(date): Начало синхронизации PBS → S3" >> "$LOG"

rclone sync "$SOURCE" "$DEST" \
  --transfers 4 \
  --checkers 8 \
  --log-file "$LOG" \
  --log-level INFO \
  --exclude "*.tmp" \
  --stats 30s

EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
  echo "$(date): Синхронизация завершена успешно" >> "$LOG"
else
  echo "$(date): ОШИБКА синхронизации, код: $EXIT_CODE" >> "$LOG"
  # Уведомление на email
  echo "PBS→S3 sync failed with code $EXIT_CODE" | \
    <a class="wpil_keyword_link" title="mail" href="https://it-apteka.com/tag/mail/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="1215">mail</a> -s "PBS Backup Sync Error" admin@example.com
fi
chmod +x /opt/scripts/sync-pbs-to-s3.sh

# Добавляем в cron (каждое воскресенье в 4:00)
echo "0 4 * * 0 root /opt/scripts/sync-pbs-to-s3.sh" \
  >> /etc/cron.d/pbs-s3-sync

Шаг 8. Мониторинг PBS через Zabbix

Бэкапы без мониторинга — это шрёдингеровский бэкап: и есть, и нет одновременно. Узнаешь правду только при восстановлении.

Вариант A — PBS API + Zabbix HTTP Agent

# На PBS создаём API token для мониторинга (только чтение)
proxmox-backup-manager user create zabbix@pbs \
  --password "ZabbixMonPass!" \
  --comment "Zabbix <a class="wpil_keyword_link" title="Мониторинг" href="https://it-apteka.com/category/monitoring/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="1212">мониторинг</a>"

proxmox-backup-manager user generate-token zabbix@pbs monitoring

# Выдаём права только на аудит
proxmox-backup-manager acl update / \
  --auth-id "zabbix@pbs!monitoring" \
  --role Audit

В Zabbix создаём HTTP-элементы данных для опроса PBS API:

# Примеры endpoints PBS API (порт 8007):

# Статус ноды (CPU, память, uptime)
GET https://IP_PBS:8007/api2/json/nodes/localhost/status
Authorization: PBSAPIToken=zabbix@pbs!monitoring:ЗНАЧЕНИЕ_ТОКЕНА

# Статус datastore
GET https://IP_PBS:8007/api2/json/admin/datastore/main/status

# Список задач (последние backup jobs)
GET https://IP_PBS:8007/api2/json/nodes/localhost/tasks?typefilter=backup&limit=50

# Статистика GC
GET https://IP_PBS:8007/api2/json/admin/datastore/main/gc-history

Вариант B — готовый bash-скрипт для Zabbix External Check

#!/bin/bash
# pbs_check.sh — <a class="wpil_keyword_link" title="Скрипты" href="https://it-apteka.com/category/scripts/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="1209">скрипт</a> проверки PBS для Zabbix External Check
# Размещаем в /usr/lib/zabbix/externalscripts/
# Использование: ./pbs_check.sh <IP> <TOKEN_ID> <TOKEN_VALUE> <CHECK_TYPE>

PBS_HOST="$1"
TOKEN_ID="$2"
TOKEN_VALUE="$3"
CHECK="$4"

PBS_URL="https://${PBS_HOST}:8007/api2/json"
AUTH="PBSAPIToken=${TOKEN_ID}:${TOKEN_VALUE}"

api_call() {
  curl -sk -H "Authorization: ${AUTH}" "${PBS_URL}/$1"
}

case "$CHECK" in
  "node.status")
    api_call "nodes/localhost/status" | python3 -c \
      "import sys,json; d=json.load(sys.stdin)['data']; print(d.get('uptime',0))"
    ;;
  "datastore.usage")
    api_call "admin/datastore/main/status" | python3 -c \
      "import sys,json; d=json.load(sys.stdin)['data']
avail=d.get('avail',0); total=d.get('total',1)
print(round((1 - avail/total)*100, 2))"
    ;;
  "datastore.avail")
    api_call "admin/datastore/main/status" | python3 -c \
      "import sys,json; d=json.load(sys.stdin)['data']; print(d.get('avail',0))"
    ;;
  "last.backup.status")
    # 0 = OK, 1 = error
    api_call "nodes/localhost/tasks?typefilter=backup&limit=10" | python3 -c \
      "import sys,json
tasks=json.load(sys.stdin)['data']
failed=[t for t in tasks if t.get('status','') not in ('OK','')]
print(1 if failed else 0)"
    ;;
  "gc.status")
    api_call "admin/datastore/main/gc-history" | python3 -c \
      "import sys,json
data=json.load(sys.stdin)['data']
if data: print(data[0].get('upid','unknown'))
else: print('no-gc-run')"
    ;;
  *)
    echo "Unknown check: $CHECK"
    exit 1
    ;;
esac
# Права на скрипт
chmod +x /usr/lib/zabbix/externalscripts/pbs_check.sh

# Тест:
./pbs_check.sh 192.168.1.50 "zabbix@pbs!monitoring" "токен" "datastore.usage"
# Ожидаем: число от 0 до 100 (процент использования)

Триггеры Zabbix (минимальный набор)

Метрика Условие триггера Severity
datastore.usage > 85% Warning
datastore.usage > 95% High
last.backup.status = 1 (есть ошибки) High
node.status (uptime) = 0 (недоступен) Disaster
datastore.avail < 10 GB High

Шаг 9. Восстановление бэкапа

Бэкап, который ты не проверял — это не бэкап. Восстанавливай хотя бы раз в квартал.

Восстановление через веб-интерфейс PVE

  1. PVE → Storage → pbs-main → Backups
  2. Выбери нужный бэкап (по дате и VMID)
  3. Нажми Restore
  4. Выбери целевую ноду, storage для диска, новый VMID (или тот же, если исходная ВМ удалена)
  5. Start after restore — включи, если хочешь сразу стартовать

Восстановление через CLI

# Посмотреть доступные бэкапы
pvesh get /nodes/$(hostname)/storage/pbs-main/content \
  --content backup | grep "vmid"

# Восстановить ВМ 101 из последнего бэкапа на storage local-lvm
qmrestore pbs-main:backup/vm/101/YYYY-MM-DDTHH:MM:SSZ 101 \
  --storage local-lvm \
  --force 1

# Восстановить LXC-контейнер 201
pct restore 201 pbs-main:backup/ct/201/YYYY-MM-DDTHH:MM:SSZ \
  --storage local-lvm \
  --force 1

Скачать бэкап на локальный диск

# На PBS — бэкапы хранятся как .fidx/.didx + chunks
# Экспортировать как .vma.zst (стандартный формат Proxmox):
proxmox-backup-client restore \
  --repository pve-backup@pbs!pve-token@IP_PBS:main \
  vm/101/YYYY-MM-DDTHH:MM:SSZ \
  /tmp/vm101-backup.vma.zst \
  --keyfile /путь/к/ключу  # если шифрование включено

# Или через веб PBS: Datastore → main → vm → 101 → Download
[/bash>

<h4>File-level восстановление (отдельные файлы из бэкапа)</h4>

[bash]
# Монтируем бэкап как файловую систему (только чтение)
proxmox-backup-client mount \
  --repository pve-backup@pbs!pve-token@IP_PBS:main \
  vm/101/YYYY-MM-DDTHH:MM:SSZ \
  /mnt/restore-point

# Теперь /mnt/restore-point содержит диски ВМ как файлы
ls /mnt/restore-point/

# Монтируем нужный диск образа (например, drive-scsi0.img)
mount -o ro,loop /mnt/restore-point/drive-scsi0.img /mnt/vm-disk

# Копируем нужные файлы
cp /mnt/vm-disk/var/www/html/важный_файл.php /tmp/

# Размонтируем
umount /mnt/vm-disk
proxmox-backup-client umount /mnt/restore-point

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

Если бэкапы уходят на внешний S3 или недоверенное хранилище — шифрование обязательно.

# Генерируем ключ шифрования (на клиенте PVE)
proxmox-backup-client key create /etc/pve/priv/pbs-encryption.key

# СРАЗУ делаем бумажный бэкап ключа (или в Vault)
proxmox-backup-client key paperkey /etc/pve/priv/pbs-encryption.key \
  --output-format text

# Прописываем ключ в backup job (через веб PVE или CLI)
# В vzdump: --encrypt /etc/pve/priv/pbs-encryption.key

# Без этого ключа расшифровать бэкап НЕВОЗМОЖНО.
# Потеря ключа = потеря всех зашифрованных бэкапов.
Ключ шифрования — храни отдельно от бэкапов. Если диск с PBS умрёт вместе с ключом — расшифровать бэкапы нельзя. Распечатай paperkey и положи в сейф. Это не шутка.

4. ОСЛОЖНЕНИЯ — ОШИБКИ И ИХ ЛЕЧЕНИЕ

Симптом Причина Лечение
authentication failed - invalid credentials Неверный токен или пользователь при подключении PVE к PBS Пересоздай токен на PBS, обнови в Storage settings PVE. Проверь realm: должно быть @pbs, не @pam
SSL certificate problem: unable to get local issuer certificate Самоподписанный сертификат PBS, fingerprint не указан или неверный Получи актуальный fingerprint: proxmox-backup-manager cert info и укажи в Storage config PVE
Бэкап завис, прогресс не движется часами Большой dirty-bitmap, медленный диск, сетевые проблемы pgrep -a vzdump → проверь I/O-wait: iostat -x 2. Первый полный бэкап большой ВМ может идти долго — это нормально
backup failed: unable to create backup lock Предыдущий бэкап не завершился корректно, lock-файл не удалён Найди и удали lock-файл: find /var/run/ -name "*.lck" | grep vzdump. Или: rm /var/run/vzdump.lock
Место на PBS не освобождается после prune Prune удалил ссылки, но GC не запускался — чанки не удалены Запусти GC вручную: proxmox-backup-manager garbage-collection start main или через веб PBS → Datastore → GC
error: connection refused при подключении к PBS PBS не запущен, firewall, неверный порт systemctl status proxmox-backup proxmox-backup-proxy. Проверь firewall: ss -tlnp | grep 8007
Windows ВМ бэкапится очень долго VSS создаёт снапшот медленно, или агент не установлен и используется suspend-mode Установи PBS Agent на Windows, используй режим snapshot + agent=1. Проверь состояние VSS: vssadmin list writers в CMD
datastore is full, новые бэкапы не пишутся Retention не настроен, GC не запускается, место кончилось Вручную запусти prune + GC. Настрой retention policy. Добавь диск или расширь существующий
Восстановление завершается с ошибкой verify failed Повреждение чанков на PBS (диск, filesystem errors) Запусти verify на PBS: proxmox-backup-manager verify start main. Проверь SMART диска: smartctl -a /dev/sdX
PBS не принимает подключение с PVE после обновления Несовместимость версий клиента и сервера Обнови PBS и PVE до одной мажорной версии. PBS 3.x работает с PVE 8.x

Чеклист отладки backup job

# 1. Логи задачи на PVE (замени UPID на реальный из Tasks)
pvesh get /nodes/$(hostname)/tasks/UPID:$(hostname):XXXXX:backup:/log

# 2. Системный лог vzdump
journalctl -u pvestatd -n 100 --no-pager

# 3. Лог на PBS (все задачи за сегодня)
proxmox-backup-manager task list --limit 20

# 4. Проверка соединения PVE → PBS
curl -sk -H "Authorization: PBSAPIToken=pve-backup@pbs!pve-token:ТОКЕН" \
  https://IP_PBS:8007/api2/json/version

# 5. Проверка свободного места на PBS
proxmox-backup-manager datastore list
df -h /mnt/backup-store

# 6. Проверка integrity бэкапа
proxmox-backup-client verify \
  --repository pve-backup@pbs!pve-token@IP_PBS:main \
  vm/101/YYYY-MM-DDTHH:MM:SSZ

5. ПРОФИЛАКТИКА

Автоматическая проверка целостности

# На PBS — запускаем verify для всего datastore еженедельно
# Через веб: Administration → Datastore → main → Verify Schedule

# Через CLI:
proxmox-backup-manager datastore update main \
  --verify-new true

# Запустить вручную немедленно:
proxmox-backup-manager verify start main

Скрипт ежедневной проверки бэкапов и отправки отчёта

#!/bin/bash
# pbs-daily-report.sh — ежедневный отчёт о состоянии бэкапов
# cron: 0 6 * * * root /opt/scripts/pbs-daily-report.sh

PBS_HOST="IP_PBS_СЕРВЕРА"
TOKEN_ID="zabbix@pbs!monitoring"
TOKEN_VALUE="ЗНАЧЕНИЕ_ТОКЕНА"
MAIL_TO="admin@example.com"
PBS_URL="https://${PBS_HOST}:8007/api2/json"
AUTH="Authorization: PBSAPIToken=${TOKEN_ID}:${TOKEN_VALUE}"

# Получаем статус datastore
DS_STATUS=$(curl -sk -H "$AUTH" "${PBS_URL}/admin/datastore/main/status")
TOTAL=$(echo "$DS_STATUS" | python3 -c "import sys,json; d=json.load(sys.stdin)['data']; print(round(d['total']/1024**3,1))")
USED=$(echo "$DS_STATUS" | python3 -c "import sys,json; d=json.load(sys.stdin)['data']; print(round(d['used']/1024**3,1))")
AVAIL=$(echo "$DS_STATUS" | python3 -c "import sys,json; d=json.load(sys.stdin)['data']; print(round(d['avail']/1024**3,1))")
PCT=$(echo "$DS_STATUS" | python3 -c "import sys,json; d=json.load(sys.stdin)['data']; print(round(d['used']/d['total']*100,1))")

# Получаем последние задачи
TASKS=$(curl -sk -H "$AUTH" "${PBS_URL}/nodes/localhost/tasks?typefilter=backup&limit=30")
FAILED=$(echo "$TASKS" | python3 -c "
import sys,json
tasks=json.load(sys.stdin)['data']
failed=[t for t in tasks if t.get('status') and t['status'] != 'OK']
for t in failed:
    print(f\"  FAIL: {t.get('id','?')} @ {t.get('starttime','?')} — {t.get('status','?')}\")
")

# Формируем отчёт
REPORT="PBS Daily Report — $(date '+%Y-%m-%d')

=== Хранилище main ===
Всего:     ${TOTAL} GB
Занято:    ${USED} GB (${PCT}%)
Свободно:  ${AVAIL} GB

=== Ошибки за последние 30 задач ===
${FAILED:-'Ошибок нет — спи спокойно'}

=== Сервер PBS ===
${PBS_HOST}
"

# Отправляем
echo "$REPORT" | mail -s "PBS Backup Report $(date '+%Y-%m-%d')" "$MAIL_TO"

# Если есть ошибки — алерт с другим subject
if [ -n "$FAILED" ]; then
  echo "$REPORT" | mail -s "⚠️ PBS BACKUP ERRORS $(date '+%Y-%m-%d')" "$MAIL_TO"
fi
chmod +x /opt/scripts/pbs-daily-report.sh
echo "0 6 * * * root /opt/scripts/pbs-daily-report.sh" \
  >> /etc/cron.d/pbs-report

Тест восстановления — делай регулярно

#!/bin/bash
# test-restore.sh — тест восстановления бэкапа в изолированную ВМ
# Запускай раз в месяц вручную или из cron

VMID_SOURCE=101        # ID ВМ, бэкап которой тестируем
VMID_TEST=9101         # Временный ID для тестовой ВМ (должен быть свободен)
STORAGE="pbs-main"     # Storage PBS в PVE
STORAGE_DISK="local-lvm"  # Куда восстанавливаем диски

echo "$(date): Начало тест-восстановления ВМ $VMID_SOURCE → $VMID_TEST"

# Находим последний бэкап
LAST_BACKUP=$(pvesh get /nodes/$(hostname)/storage/${STORAGE}/content \
  --content backup 2>/dev/null \
  | grep "vmid.*${VMID_SOURCE}" \
  | sort -k4 -r \
  | head -1 \
  | awk '{print $1}')

if [ -z "$LAST_BACKUP" ]; then
  echo "ОШИБКА: бэкап ВМ $VMID_SOURCE не найден!"
  exit 1
fi

echo "Восстанавливаем из: $LAST_BACKUP"

# Восстановление
qmrestore "${STORAGE}:${LAST_BACKUP}" "$VMID_TEST" \
  --storage "$STORAGE_DISK" \
  --force 1

if [ $? -eq 0 ]; then
  echo "$(date): Восстановление успешно. ВМ $VMID_TEST создана."
  echo "Проверь вручную, затем удали: qm destroy $VMID_TEST"
else
  echo "$(date): ОШИБКА восстановления!"
  exit 1
fi

6. ПРОГНОЗ

Короче, что мы сделали:

  • Установили Proxmox Backup Server — с ISO или на существующий Debian
  • Создали datastore с правильными правами и retention policy
  • Подключили PBS к PVE через API-токен, без рутовых паролей в конфигах
  • Настроили backup jobs для всех ВМ и CT по расписанию
  • Поставили PBS Agent на Windows-виртуалки — бэкапы теперь VSS-консистентные
  • Подняли синхронизацию на S3 для offsite-копий
  • Добавили мониторинг в Zabbix с алертами на ошибки и заполнение диска
  • Разобрали восстановление — полное, file-level, на тестовую ВМ
  • Написали скрипт ежедневного отчёта и тест-восстановления

Результат: бэкапы есть, они проверены, мониторятся, и ты знаешь, как и за сколько времени восстановиться. Это называется «иметь бэкапы», а не «думать, что они есть».

Андрей Анатольевич
Author: Андрей Анатольевич

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх