Proxmox VE + Proxmox Backup Server: резервное копирование VM и диагностика зависших backup-задач

Proxmox Backup Server (PBS) интегрируется с Proxmox VE (PVE) как отдельное backup-хранилище. В штатном режиме PVE запускает vzdump, взаимодействует с QEMU через QMP, создаёт backup-сессию на PBS и передаёт туда данные виртуальной машины. PBS хранит резервные копии в datastore, использует дедупликацию и позволяет выполнять последующие backup инкрементально.

На практике важно уметь не только создать backup job, но и понимать, на каком именно уровне возникла проблема, если резервное копирование зависло: внутри VM, в QMP, на локальном storage PVE, в сети, в PBS API, в datastore или в зависшей серверной backup-сессии.

Эта инструкция объединяет базовую настройку PVE → PBS и полноценный сценарий диагностики случая, когда backup останавливается на стадии запуска QMP-команды, а в логах появляются ошибки вида:

qmp command 'backup' failed - got timeout
qmp command 'backup-cancel' failed - got timeout
qmp command 'cont' failed - got timeout

Проверено на: Proxmox VE 8.x, Proxmox Backup Server 3.x
Уровень сложности: средний
Время выполнения: 30–60 минут на настройку; диагностика зависит от характера сбоя
Требуемый доступ: root на PVE и PBS либо эквивалентные административные права

Что будет настроено и проверено

• подключение Proxmox Backup Server к Proxmox VE;
• отдельный пользователь PBS с минимально необходимыми правами;
• проверка доступности datastore из PVE;
• ручной backup выключенной VM в режиме stop;
• ручной backup работающей VM в режиме snapshot;
• проверка плановых backup-задач;
• анализ vzdump и QMP при зависании;
• проверка локального storage, CPU, RAM, I/O и сети на PVE;
• анализ активных и завершённых task на PBS;
• поиск зависшей PBS backup-сессии;
• безопасная работа со stale lock: backup;
• безопасный перезапуск proxmox-backup-proxy, если зависшие сессии подтверждены;
• контрольный backup после восстановления;
• рекомендации по профилактике повторного сбоя.

Исходные условия

Предполагается следующая инфраструктура:

• один или несколько узлов Proxmox VE;
• отдельный Proxmox Backup Server;
• PBS datastore уже создан и смонтирован;
• между PVE и PBS есть IP-связность;
• TCP/8007 от PVE к PBS разрешён;
• на PBS создан пользователь или API token для резервного копирования;
• на PVE есть хотя бы одна тестовая VM.

В примерах используются плейсхолдеры:

PVE_NODE          — имя узла Proxmox VE
PVE_IP            — IP-адрес узла PVE
PBS_IP            — IP-адрес Proxmox Backup Server
PBS_STORAGE_ID    — имя PBS storage в Proxmox VE, например pbs-backup
PBS_DATASTORE     — имя datastore на PBS, например backups
PBS_USER          — пользователь PBS, например backup-user@pbs
PBS_FINGERPRINT   — SHA-256 fingerprint сертификата PBS

VMID_STOPPED      — VM, которая штатно выключена
VMID_RUNNING      — работающая тестовая VM

Не подставляйте в документацию реальные IP-адреса, имена сотрудников, названия внутренних серверов, fingerprint сертификатов и учётные данные.

Схема резервного копирования

 ┌───────────────────────────────────────┐
 │             Proxmox VE               │
 │                                       │
 │  vzdump                               │
 │     │                                 │
 │     ├── QMP ──> QEMU/KVM VM           │
 │     │                                 │
 │     └── PBS client / backup protocol  │
 └───────────────────┬───────────────────┘
                     │
                     │ HTTPS / TCP 8007
                     │
                     ▼
 ┌───────────────────────────────────────┐
 │       Proxmox Backup Server           │
 │                                       │
 │  proxmox-backup-proxy                 │
 │            │                          │
 │            ▼                          │
 │       datastore                       │
 │            │                          │
 │            ▼                          │
 │  chunks + indexes + manifests         │
 └───────────────────────────────────────┘

Для диагностики эта схема принципиальна: если ping до PBS работает, это ещё не означает, что backup работает. Аналогично, доступный PBS API не гарантирует, что конкретная backup-сессия не зависла после её создания.

Как работает backup VM в общих чертах

При резервном копировании виртуальной машины PVE выполняет несколько этапов:

1. создаёт vzdump task;
2. устанавливает lock: backup на VM;
3. взаимодействует с QEMU через QMP;
4. при необходимости выполняет guest-agent freeze/thaw;
5. создаёт backup-сессию на PBS;
6. получает или создаёт индексы предыдущей резервной копии;
7. передаёт блоки дисков;
8. PBS сохраняет новые chunks и переиспользует уже существующие;
9. PVE завершает QMP backup;
10. снимается lock: backup;
11. задача завершается со статусом OK.

Из этого следует важное правило:

Ошибка qmp command 'backup' failed - got timeout не означает автоматически, что проблема находится внутри гостевой ОС. QMP-команда backup затрагивает весь путь от QEMU до целевого backup backend.

Подготовка datastore на PBS

На PBS проверьте конфигурацию datastore:

cat /etc/proxmox-backup/datastore.cfg

Пример:

datastore: PBS_DATASTORE
        path /mnt/datastore/PBS_DATASTORE

Проверьте файловую систему:

df -hT
findmnt /mnt/datastore/PBS_DATASTORE

Datastore должен быть смонтирован в режиме rw, а на файловой системе должен оставаться рабочий запас свободного места.

Пример:

Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/sdX1       ext4  9.1T  6.0T  2.7T  70% /mnt/datastore/PBS_DATASTORE

Пользователь PBS для резервного копирования

Для PVE лучше использовать отдельного пользователя или отдельный API token, а не root@pam.

Создать пользователя можно через Web UI PBS или CLI:

proxmox-backup-manager user create PBS_USER --password 'CHANGE_ME'

После создания назначьте право DatastoreBackup на нужный datastore:

proxmox-backup-manager acl update \
  /datastore/PBS_DATASTORE \
  DatastoreBackup \
  --auth-id PBS_USER

Проверьте права:

proxmox-backup-manager user permissions \
  PBS_USER \
  --path /datastore/PBS_DATASTORE

Для backup-клиента принцип минимальных привилегий предпочтительнее административных ролей.

Важно: пароль в командной строке может попасть в shell history. В production удобнее создать пользователя через Web UI или использовать API token с отдельным secret.

Получение fingerprint PBS

Если PBS использует сертификат, которому PVE не доверяет через системный CA, понадобится SHA-256 fingerprint.

На PBS:

proxmox-backup-manager cert info | grep Fingerprint

Пример:

Fingerprint (sha256): AA:BB:CC:...:EE:FF

Сохраните значение как PBS_FINGERPRINT.

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

На PVE можно добавить PBS через:

Datacenter
  → Storage
  → Add
  → Proxmox Backup Server

Понадобятся:

ID          = PBS_STORAGE_ID
Server      = PBS_IP
Datastore   = PBS_DATASTORE
Username    = PBS_USER
Password    = пароль или token secret
Fingerprint = PBS_FINGERPRINT

Через CLI:

pvesm add pbs PBS_STORAGE_ID \
  --server PBS_IP \
  --datastore PBS_DATASTORE \
  --username PBS_USER \
  --fingerprint PBS_FINGERPRINT \
  --password

После выполнения команда запросит пароль интерактивно.

Конфигурация storage хранится в:

cat /etc/pve/storage.cfg

Пример:

pbs: PBS_STORAGE_ID
        datastore PBS_DATASTORE
        server PBS_IP
        content backup
        fingerprint PBS_FINGERPRINT
        prune-backups keep-all=1
        username PBS_USER

Пароль не хранится прямо в storage.cfg.

Проверка подключения PVE → PBS

На PVE:

pvesm status

Ожидаемый результат:

Name              Type  Status  Total  Used  Available  %
PBS_STORAGE_ID     pbs   active  ...

Проверка конкретного storage:

pvesm status --storage PBS_STORAGE_ID

Проверка списка backup конкретной VM:

pvesm list PBS_STORAGE_ID --vmid VMID_STOPPED

Измерить время ответа:

time pvesm list PBS_STORAGE_ID --vmid VMID_STOPPED

Если storage отвечает за секунды и показывает существующие snapshots, базовая связность PVE → PBS работает.

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

Проверка TCP/8007

proxmox-backup-proxy принимает внешние HTTPS-подключения PBS на TCP/8007.

С PVE:

curl -k -sS \
  --connect-timeout 5 \
  --max-time 10 \
  -o /dev/null \
  -w 'HTTP=%{http_code} connect=%{time_connect}s TLS=%{time_appconnect}s total=%{time_total}s\n' \
  https://PBS_IP:8007/api2/json/version

Также полезно:

ping -c 5 -W 2 PBS_IP
ip route get PBS_IP

ping проверяет только ICMP. Для backup важнее доступность TCP/8007 и нормальная работа PBS API.

Ручной backup выключенной VM

Для первой проверки удобна VM, которая штатно выключена.

Проверьте:

qm status VMID_STOPPED
qm config VMID_STOPPED | grep '^lock:' || echo 'lock: отсутствует'

Ожидаемо:

status: stopped
lock: отсутствует

Запустите backup:

vzdump VMID_STOPPED \
  --storage PBS_STORAGE_ID \
  --mode stop

Для сохранения полного лога:

vzdump VMID_STOPPED \
  --storage PBS_STORAGE_ID \
  --mode stop \
  2>&1 | tee /root/vzdump-VMID_STOPPED-test.log

При backup уже выключенной VM PVE может временно запустить служебный QEMU для выполнения backup-задачи. После успешного завершения исходно выключенная VM должна снова иметь:

status: stopped

и не должна оставаться с lock: backup.

Ручной backup работающей VM

Проверьте состояние:

qm status VMID_RUNNING
time qm status VMID_RUNNING --verbose | \
  grep -E '^(name|qmpstatus|status|vmid):'

Ожидаемо:

qmpstatus: running
status: running

Запуск:

vzdump VMID_RUNNING \
  --storage PBS_STORAGE_ID \
  --mode snapshot

С сохранением лога:

vzdump VMID_RUNNING \
  --storage PBS_STORAGE_ID \
  --mode snapshot \
  2>&1 | tee /root/vzdump-VMID_RUNNING-test.log

Режим snapshot предназначен для backup работающей VM без её полного выключения.

Если настроен QEMU Guest Agent, в логах могут появляться операции freeze/thaw файловой системы.

Как выглядит штатный backup

Нормальный лог содержит переход от подготовки к фактической backup-задаче:

INFO: Starting Backup of VM ...
INFO: backup mode: ...
INFO: creating Proxmox Backup Server archive ...
INFO: started backup task '...'
INFO: ide0: dirty-bitmap status: ...
INFO:   1% (...)
INFO:   2% (...)
...
INFO: 100% (...)
INFO: backup was done incrementally, reused ...
INFO: transferred ...
INFO: Finished Backup of VM ...
INFO: Backup job finished successfully

Ключевая граница:

started backup task

и последующий процентный прогресс означают, что PVE успешно перешёл от подготовки QMP/PBS к обработке дисковых данных.

Почему write: 0 B/s не всегда ошибка

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

В таком случае возможен вывод:

read: 300 MiB/s, write: 0 B/s
...
backup was done incrementally, reused 64.00 GiB (100%)

Это не обязательно проблема.

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

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

Finished Backup of VM ...
Backup job finished successfully

а не только по write: 0 B/s.

Плановое резервное копирование

В Web UI PVE:

Datacenter
  → Backup
  → Add

Настройте:

• целевой PBS storage;
• список VM или All;
• режим backup;
• расписание;
• retention;
• уведомления;
• bandwidth limit при необходимости.

Плановые vzdump jobs запускаются scheduler-ом PVE. Их конфигурацию можно проверить на узле:

cat /etc/pve/jobs.cfg

Статус scheduler:

systemctl status pvescheduler

После первой ночи обязательно проверьте не только наличие task со статусом OK, но и реальные snapshots на PBS.

Где смотреть логи на PVE

Лог конкретной QEMU VM:

cat /var/log/vzdump/qemu-VMID.log

Последние строки:

tail -150 /var/log/vzdump/qemu-VMID.log

Поиск процессов:

pgrep -af 'vzdump|proxmox-backup-client'

Список задач узла:

pvesh get /nodes/$(hostname)/tasks --limit 50

Статус конкретной task по UPID:

pvenode task status 'UPID:...'

Лог:

pvenode task log 'UPID:...'

Для длинного общего backup-job полезно отфильтровать только начало и результат каждой VM:

pvenode task log 'UPID:...' 2>&1 |
grep -E \
  'Starting Backup of VM|Finished Backup of VM|Backup of VM .* failed|Failed at|Finished at|qmp command.*backup.*failed'

Где смотреть задачи на PBS

Только текущие задачи:

proxmox-backup-manager task list

Текущие и завершённые:

proxmox-backup-manager task list \
  --all \
  --limit 1000

В JSON:

proxmox-backup-manager task list \
  --all \
  --limit 1000 \
  --output-format json-pretty \
  > /root/pbs-task-list.json

Лог конкретной задачи:

proxmox-backup-manager task log 'UPID:pbs:...'

Это один из самых важных инструментов диагностики PVE → PBS: PVE task и PBS task нужно сравнивать по времени.

Типовой симптом: backup завис на QMP

Один из характерных сценариев:

INFO: creating Proxmox Backup Server archive ...
INFO: attaching TPM drive to QEMU for backup
ERROR: VM ... qmp command 'backup' failed - got timeout
INFO: aborting backup job
ERROR: VM ... qmp command 'backup-cancel' failed - got timeout
INFO: resuming VM again
ERROR: Backup of VM ... failed - VM ... qmp command 'cont' failed - got timeout

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

В таком случае диагностику нужно расширять до уровня PVE host и PBS.

Первый принцип диагностики: не снимать lock сразу

Если VM показывает:

lock: backup

не выполняйте автоматически:

qm unlock VMID

Сначала убедитесь, что task, установившая lock, действительно больше не работает.

Проверьте:

pgrep -af 'vzdump|proxmox-backup-client'

и:

ps auxww | grep -E '[v]zdump|[p]roxmox-backup-client|[q]emu.*VMID'

Снятие корректного lock с реально работающего backup может привести к запуску конфликтующих операций.

Базовая диагностика зависшей VM

На PVE:

echo '=== VM STATUS ==='
qm status VMID
qm config VMID

echo
echo '=== LOCK ==='
qm config VMID | grep -i '^lock:' || true

echo
echo '=== BACKUP PROCESSES ==='
pgrep -af 'vzdump|proxmox-backup-client' || true

echo
echo '=== VM PROCESSES ==='
pgrep -af 'kvm -id VMID|VMID.swtpm' || true

echo
echo '=== VZDUMP LOG ==='
tail -150 /var/log/vzdump/qemu-VMID.log 2>/dev/null || true

Особенно важны:

status: stopped
status: running
status: prelaunch
lock: backup

и наличие или отсутствие живого vzdump.

Что означает status: prelaunch

Состояние prelaunch может появиться, если PVE поднял QEMU, но VM фактически ещё не исполняет гостевую ОС.

При backup выключенной VM это может быть временный служебный QEMU.

В списке процессов такой QEMU может содержать:

/usr/bin/kvm -id VMID ... -S

Ключ -S означает, что виртуальные CPU не запущены автоматически.

Если одновременно:

• в backup log записано status = stopped;
• используется backup mode: stop;
• живого vzdump уже нет;
• VM показывает prelaunch;
• остаётся lock: backup;
• QEMU существует только как служебный процесс backup;

то это похоже на orphaned backup QEMU после аварийно завершившейся task.

Безопасное удаление orphaned backup QEMU

Предупреждение: этот раздел применим только тогда, когда вы доказали, что VM до backup была выключена, активной backup-задачи больше нет, а запущенный QEMU является оставшимся служебным процессом. Не выполняйте эти команды вслепую на рабочей VM.

Сначала ещё раз:

qm status VMID
qm config VMID | grep '^lock:' || true
pgrep -af 'vzdump|proxmox-backup-client' || true
pgrep -af 'kvm -id VMID|VMID.swtpm' || true

Если условия подтверждены:

qm stop VMID --skiplock 1

Проверить:

qm status VMID
pgrep -af 'kvm -id VMID|VMID.swtpm' || true

После остановки orphaned QEMU:

qm unlock VMID

Финально:

qm status VMID
qm config VMID | grep '^lock:' || echo 'lock: отсутствует'

Ожидаемо для исходно выключенной VM:

status: stopped
lock: отсутствует

Если QMP timeout идёт по множеству VM

Проверьте, отвечает ли QMP сейчас:

RUNNING_IDS="$(qm list | awk 'NR>1 && $3=="running" {print $1}' | head -10)"

for id in $RUNNING_IDS; do
    echo "--- VM $id ---"
    START=$(date +%s)
    timeout 10 qm status "$id" --verbose 2>&1 |
      grep -E '^(name|qmpstatus|status|vmid):'
    RC=${PIPESTATUS[0]}
    END=$(date +%s)
    echo "rc=$RC duration=$((END-START))s"
done

Штатная картина:

qmpstatus: running
status: running
rc=0 duration=1s

Если большинство VM отвечает быстро после завершения проблемного backup-job, а во время backup журнал был заполнен QMP timeout, вероятна временная деградация backup path, а не постоянная поломка QEMU.

Проверка ресурсов PVE

Быстрая проверка:

uptime
free -h
vmstat 1 5

Pressure Stall Information:

for f in /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory; do
    echo "--- $f"
    cat "$f"
done

D-state процессы:

ps -eo state,pid,ppid,wchan:32,etime,%cpu,%mem,cmd |
awk '$1 ~ /^D/ {print}'

Топ по CPU:

ps -eo pid,ppid,stat,%cpu,%mem,etime,cmd \
  --sort=-%cpu |
head -30

Если установлен sysstat:

iostat -xz 1 5

Ищите:

• высокий wa в vmstat;
• процессы в D;
• постоянный высокий PSI I/O;
• полностью занятую RAM с активным swap-in/swap-out;
• storage latency;
• ошибки дисков.

Проверка kernel и storage PVE

journalctl -k \
  --since 'TIME_FROM' \
  --until 'TIME_TO' \
  --no-pager |
grep -Ei \
  'oom|out of memory|killed process|segfault|i/o error|buffer i/o|nvme|ata|scsi|xfs|ext4|blk|reset|timeout|hung|call trace'

Storage:

pvesm status
df -hT

Обращайте внимание не только на PBS, но и на локальные storage, где физически лежат диски VM.

Если локальная файловая система PVE заполнена почти полностью или на 100%, это отдельный аварийный фактор, даже если сам PBS имеет много свободного места.

Проверка сети PVE → PBS

ping -c 5 -W 2 PBS_IP
ip route get PBS_IP

Счётчики:

ip -s link

Ошибки физического интерфейса:

ethtool -S INTERFACE 2>/dev/null |
grep -Ei \
  'err|drop|discard|miss|timeout|reset|fault|overrun|crc'

Небольшие накопленные counters за месяцы работы сами по себе не доказывают текущую сетевую проблему. Важна динамика: растут ли ошибки во время backup.

Проверка PBS при зависшем backup

На PBS:

hostname
date
uptime
free -h

echo
cat /etc/proxmox-backup/datastore.cfg

echo
df -hT

echo
findmnt

echo
systemctl --no-pager --full status \
  proxmox-backup \
  proxmox-backup-proxy

Проверьте также расписания verify/prune:

cat /etc/proxmox-backup/verification.cfg 2>/dev/null || true
cat /etc/proxmox-backup/prune.cfg 2>/dev/null || true

Если verify, prune, GC или другие тяжёлые операции совпадают по времени с backup, это нужно учитывать при анализе нагрузки datastore.

Проверка журнала PBS в точном временном окне

Не анализируйте «весь день» без необходимости.

Возьмите время старта первой неуспешной VM на PVE и окно вокруг него:

journalctl \
  --since 'YYYY-MM-DD HH:MM:SS' \
  --until 'YYYY-MM-DD HH:MM:SS' \
  --no-pager |
grep -Ei \
  'backup|datastore|verify|verification|garbage|gc|prune|error|fail|timeout|slow|worker|connection|reset|broken pipe|no space|read-only|offline'

Kernel PBS:

journalctl -k \
  --since 'YYYY-MM-DD HH:MM:SS' \
  --until 'YYYY-MM-DD HH:MM:SS' \
  --no-pager |
grep -Ei \
  'error|fail|timeout|reset|i/o|blk|nvme|ata|scsi|ext4|xfs|zfs|oom|out of memory|hung'

Важно синхронизировать временные зоны PVE и PBS при сравнении timestamps.

Как обнаружить зависшую PBS backup-сессию

Очень показательный сценарий:

1. PVE создаёт backup VM;
2. PBS регистрирует новую backup task;
3. PVE через несколько минут фиксирует QMP timeout и идёт к следующей VM;
4. PBS task первой VM не завершается;
5. следующая VM создаёт ещё одну PBS task;
6. старые server-side tasks продолжают жить;
7. количество процессов/threads и потребление памяти proxmox-backup-proxy постепенно растёт.

Посмотреть активные задачи:

proxmox-backup-manager task list

Если backup-job на PVE уже завершён, а на PBS остаются старые tasks соответствующих VM, это важный симптом.

Посмотреть историю:

proxmox-backup-manager task list \
  --all \
  --limit 1000 \
  --output-format json-pretty \
  > /root/pbs-task-list.json

Сравнение PVE task и PBS task

На PVE определите:

VM start time
VM failed time
PVE UPID

На PBS найдите ту же VM:

grep -n 'vm-VMID' /root/pbs-task-list.json

Затем:

proxmox-backup-manager task log 'PBS_UPID'

Подозрительная картина:

download 'index.json.blob' from previous backup ...
register chunks in 'drive-....img.fidx' from previous backup ...
download 'drive-....img.fidx' from previous backup ...
created new fixed index ...

и после этого — длинная пауза без передачи данных.

Если PVE уже признал VM failed, а PBS task остаётся running ещё много времени, server-side backup session не завершилась корректно.

Почему важно анализировать первую неуспешную VM

Если общий job содержит десятки VM, не начинайте с последней машины, на которой вы заметили зависание.

Сначала получите краткую сводку:

pvenode task log 'PVE_UPID' 2>&1 |
grep -E \
  'Starting Backup of VM|Finished Backup of VM|Backup of VM .* failed|Failed at|Finished at|qmp command.*backup.*failed'

Найдите границу:

последняя успешная VM
первая неуспешная VM

Если первая же VM задания падает с тем же timeout и все последующие повторяют ошибку, источник проблемы почти наверняка шире одной конкретной VM.

Проверка состояния proxmox-backup-proxy

На PBS:

systemctl --no-pager status proxmox-backup-proxy | head -20

Дополнительно:

ps -C proxmox-backup-proxy \
  -o pid,lstart,rss,vsz,nlwp,cmd

Смотрите:

• uptime процесса;
• Tasks;
• Memory;
• RSS;
• NLWP;
• наличие старых активных PBS tasks.

Большое значение Tasks или Memory само по себе ещё не является доказательством сбоя. Оно становится значимым вместе с зависшими backup-сессиями и временной корреляцией с ошибками PVE.

Безопасный перезапуск proxmox-backup-proxy

Перезапуск proxy — восстановительная мера, а не доказательство первопричины.

Перед рестартом обязательно проверьте:

proxmox-backup-manager task list

Если вывод содержит активный backup, restore, verify или другую важную задачу — не перезапускайте сервис без понимания последствий.

Если активных задач нет и зависшее состояние подтверждено, зафиксируйте состояние:

echo '=== BEFORE ==='
systemctl --no-pager status proxmox-backup-proxy | head -20

ps -C proxmox-backup-proxy \
  -o pid,lstart,rss,vsz,nlwp,cmd

Перезапуск:

systemctl restart proxmox-backup-proxy

Проверка:

sleep 3

systemctl --no-pager --full status \
  proxmox-backup-proxy |
head -25

ps -C proxmox-backup-proxy \
  -o pid,lstart,rss,vsz,nlwp,cmd

proxmox-backup-manager task list

Нормально, если после рестарта:

• PID изменился;
• uptime стал минимальным;
• Tasks вернулся к базовому значению;
• memory/RSS резко снизились;
• активных backup tasks нет;
• PVE снова быстро получает ответы от PBS.

Важно: не используйте автоматический периодический restart proxy как «лечение». Если проблема повторяется, нужно собирать task logs и системные метрики до рестарта.

Почему рестарт только proxy лучше полного reboot PBS

proxmox-backup-proxy — внешний API proxy PBS. Если проблема локализована в зависших внешних backup-сессиях, перезапуск только этого сервиса является более узким воздействием, чем reboot всего backup-сервера.

Но сначала всё равно нужно исключить:

• активные server tasks;
• проблемы datastore;
• I/O errors;
• OOM;
• сетевые ошибки;
• filesystem read-only;
• аппаратные ошибки дисков.

Контрольный backup после восстановления

Сначала используйте штатно выключенную VM:

qm status VMID_STOPPED
qm config VMID_STOPPED | grep '^lock:' || echo 'lock: отсутствует'

time pvesm list PBS_STORAGE_ID --vmid VMID_STOPPED

Запустите:

vzdump VMID_STOPPED \
  --storage PBS_STORAGE_ID \
  --mode stop \
  2>&1 | tee /root/vzdump-VMID_STOPPED-test.log

Хороший признак — быстрый переход к:

started backup task
...
1%
2%
3%

После завершения:

qm status VMID_STOPPED
qm config VMID_STOPPED | grep '^lock:' || echo 'lock: отсутствует'
tail -60 /root/vzdump-VMID_STOPPED-test.log

Если backup выключенной VM успешен, следующим тестом можно использовать одну работающую VM в режиме snapshot:

vzdump VMID_RUNNING \
  --storage PBS_STORAGE_ID \
  --mode snapshot \
  2>&1 | tee /root/vzdump-VMID_RUNNING-test.log

Не нужно сразу запускать общий job на десятки VM.

Как отличить восстановление от найденной первопричины

Допустим:

до рестарта proxy:
  backup всех VM → QMP timeout

после рестарта proxy:
  test backup → успешно

Это подтверждает, что перезапуск очистил проблемное состояние.

Но это не доказывает, почему состояние появилось.

Возможные классы первопричин всё ещё требуют отдельного анализа:

• bug конкретной версии PBS/PVE;
• временный сетевой stall;
• проблема datastore;
• аппаратная задержка;
• ресурсное истощение;
• зависшая backup-сессия после предыдущей ошибки;
• взаимодействие нескольких jobs;
• проблема клиента PVE;
• редкий race condition.

Поэтому перед рестартом полезно сохранить максимально полный снимок состояния.

Диагностический снимок PVE в файл

Чтобы не копировать тысячи строк из консоли, вывод лучше сразу писать в файл:

bash -c '
echo "=== DATE / HOST / LOAD ==="
date
hostname
uptime
free -h

echo
echo "=== PSI ==="
for f in /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory; do
    echo "--- $f"
    cat "$f"
done

echo
echo "=== VMSTAT ==="
vmstat 1 5

echo
echo "=== D-STATE ==="
ps -eo state,pid,ppid,wchan:32,etime,%cpu,%mem,cmd |
awk '"'"'$1 ~ /^D/ {print}'"'"'

echo
echo "=== STORAGE ==="
pvesm status
df -hT

echo
echo "=== QMP ERRORS ==="
journalctl --since "30 minutes ago" --no-pager |
grep -E \
  "qmp command failed|query-proxmox-support|status update time" |
tail -200 || true

echo
echo "=== PVE VERSION ==="
pveversion -v

echo
echo "=== KERNEL ==="
uname -a

echo
echo "=== BACKUP PROCESSES ==="
pgrep -af "vzdump|proxmox-backup-client" ||
echo "backup processes: none"
' > /root/pve-backup-diag.txt 2>&1

После этого:

ls -lh /root/pve-backup-diag.txt
tail -30 /root/pve-backup-diag.txt

Диагностический снимок PBS

bash -c '
echo "=== HOST ==="
hostname
date
uptime
free -h

echo
echo "=== DATASTORE ==="
cat /etc/proxmox-backup/datastore.cfg

echo
echo "=== FILESYSTEM ==="
df -hT

echo
echo "=== RUNNING TASKS ==="
proxmox-backup-manager task list

echo
echo "=== PROXY ==="
systemctl --no-pager status proxmox-backup-proxy

echo
ps -C proxmox-backup-proxy \
  -o pid,lstart,rss,vsz,nlwp,cmd

echo
echo "=== VERSION ==="
proxmox-backup-manager versions
' > /root/pbs-backup-diag.txt 2>&1

История task:

proxmox-backup-manager task list \
  --all \
  --limit 1000 \
  --output-format json-pretty \
  > /root/pbs-task-list.json

Эти файлы удобно прикладывать к внутреннему инциденту или обращению в поддержку.

Проверка версий

PVE:

pveversion -v
uname -a

PBS:

proxmox-backup-manager versions
uname -a

Версии нужно фиксировать до обновления или reboot, если диагностируется редкий воспроизводимый сбой.

Проверка scheduled verify и prune

PBS имеет собственные фоновые jobs.

Посмотреть:

cat /etc/proxmox-backup/verification.cfg 2>/dev/null || true
cat /etc/proxmox-backup/prune.cfg 2>/dev/null || true

В больших datastore на HDD желательно понимать, не пересекаются ли по времени:

• PVE backup;
• PBS verify;
• prune;
• garbage collection;
• sync;
• другие тяжёлые операции.

Сам факт совпадения не означает ошибку, но он важен для анализа I/O contention.

Проверка свободного места

PBS:

df -hT /mnt/datastore/PBS_DATASTORE

PVE:

pvesm status
df -hT

Не ограничивайтесь только целевым PBS.

VM может использовать диски на нескольких локальных PVE storage, и заполненный исходный storage способен создать проблемы независимо от состояния PBS.

Работа с уведомлениями

Backup job должен отправлять уведомление как минимум при ошибке.

Проверяйте:

• уведомления PVE;
• уведомления PBS;
• локальную доставку root;
• SMTP relay при его использовании.

Если mail subsystem имеет ошибку, это не обязательно причина backup failure, но без исправных notifications ночная авария может оставаться незамеченной часами.

Минимальный алгоритм при аварии

Если ночью обнаружен зависший backup:

1. Не делать reboot сразу.
2. Не выполнять qm unlock вслепую.
3. Зафиксировать время.
4. Найти PVE UPID.
5. Найти первую неуспешную VM.
6. Проверить жив ли vzdump.
7. Проверить QMP нескольких VM.
8. Проверить pvesm status и доступ к PBS.
9. Проверить CPU/RAM/I/O/D-state.
10. Проверить kernel log.
11. На PBS проверить task list.
12. Сопоставить PBS task с первой failed VM.
13. Сохранить task log.
14. Проверить proxmox-backup-proxy Tasks/Memory/NLWP.
15. Только затем принимать решение о restart/unlock.
16. После восстановления — backup одной тестовой VM.
17. Не запускать сразу весь ночной job.

Пример интерпретации инцидента

Представим ситуацию:

00:00  PVE запускает backup VM-A
00:00  PBS создаёт server-side task VM-A
00:12  PVE получает QMP timeout и считает VM-A failed
00:12  PVE переходит к VM-B
00:12  PBS task VM-A всё ещё running
00:35  VM-B также падает
...
07:00  на PBS накоплено много незавершённых сессий

При этом:

• PBS ping доступен;
• TCP/8007 отвечает;
• datastore не заполнен;
• kernel I/O errors отсутствуют;
• после завершения проблемного job QMP снова отвечает быстро;
• PBS task первой VM оставалась активной намного дольше PVE task;
• после безопасного restart proxmox-backup-proxy тестовый backup проходит.

В такой ситуации корректный вывод:

проблема была связана с зависшим состоянием server-side backup sessions / proxy path, а не с конкретной последней VM, на которой оператор заметил зависание.

Но формулировка:

«причина точно была в proxmox-backup-proxy»

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

Что делать, если проблема повторится

При повторении ошибки важно не перезапускать PBS немедленно.

Сначала соберите:

PVE:
- UPID общего vzdump job;
- task log;
- /var/log/vzdump/qemu-VMID.log первой failed VM;
- qm status --verbose нескольких VM;
- pvesm status;
- pveversion -v;
- kernel log;
- PSI/vmstat/iostat;
- network counters.

PBS:
- proxmox-backup-manager task list;
- task list --all в JSON;
- task log первой зависшей backup task;
- systemctl status proxmox-backup-proxy;
- RSS/NLWP proxy;
- datastore free space;
- verify/prune/GC/sync jobs;
- PBS version;
- kernel log.

И только после фиксации состояния выполняйте восстановительные действия.

Так появляется шанс найти не только способ «починить до следующей ночи», но и реальную первопричину.

Профилактика

Для production-инфраструктуры полезно:

• использовать отдельного PBS пользователя или API token с минимальными правами;
• не давать PVE-клиенту лишние права на удаление backup;
• выполнять retention/prune на стороне PBS;
• контролировать свободное место и на PBS, и на PVE storage;
• следить за SMART/NVMe health;
• мониторить latency datastore;
• отслеживать proxmox-backup-proxy по memory и количеству tasks;
• отправлять alerts при failed backup;
• периодически выполнять verify;
• периодически проверять restore;
• не считать наличие snapshot на PBS достаточным доказательством восстанавливаемости;
• фиксировать версии PVE/PBS перед обновлениями;
• после обновлений выполнять тестовый manual backup;
• избегать бесконтрольного пересечения тяжёлых backup/verify/GC задач на медленном storage.

Проверка восстановления из backup

Полноценная стратегия резервного копирования должна включать тест восстановления.

Минимальный вариант:

1. выбрать отдельную некритичную VM;
2. восстановить её backup с PBS под новым VMID;
3. не подключать восстановленную VM к production-сети до проверки;
4. убедиться, что VM загружается;
5. проверить файловую систему и прикладные данные;
6. после теста удалить временную VM.

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

Финальная проверка PVE → PBS

На PVE:

# PBS активен
pvesm status --storage PBS_STORAGE_ID

# Существующие backup видны
pvesm list PBS_STORAGE_ID --vmid VMID_STOPPED

# Нет зависших backup процессов
pgrep -af 'vzdump|proxmox-backup-client' ||
echo 'backup processes: none'

# QMP отвечает
qm status VMID_RUNNING --verbose |
grep -E '^(qmpstatus|status|vmid):'

# Нет stale lock
qm config VMID_STOPPED |
grep '^lock:' ||
echo 'lock: отсутствует'

На PBS:

# Datastore смонтирован
df -hT /mnt/datastore/PBS_DATASTORE

# Proxy работает
systemctl is-active proxmox-backup-proxy

# Нет неожиданных зависших задач
proxmox-backup-manager task list

# Версия зафиксирована
proxmox-backup-manager versions

После тестового backup:

pvesm list PBS_STORAGE_ID --vmid VMID_STOPPED

должен появиться новый snapshot.

Что не охватывает эта инструкция

Это руководство ориентировано на резервное копирование QEMU VM из PVE в PBS и диагностику зависших backup-задач.

Отдельного рассмотрения требуют:

• подробное восстановление VM и отдельных файлов;
• LXC backup;
• client-side encryption;
• хранение и восстановление encryption keys;
• PBS namespaces;
• API token hardening;
• remote sync между несколькими PBS;
• off-site backup;
• tape backup;
• immutable/offline copies;
• disaster recovery всего PVE-кластера;
• HA во время backup;
• performance tuning datastore;
• аппаратный RAID/ZFS tuning;
• мониторинг через Prometheus, InfluxDB или Zabbix.

Итог

После корректной настройки получается следующая схема:

Proxmox VE
    │
    │ vzdump + QMP
    ▼
Proxmox Backup Server
    │
    ▼
datastore
    │
    ├── incremental backup
    ├── deduplication
    ├── retention
    └── verification

Для штатной эксплуатации достаточно контролировать успешность плановых jobs и периодически проверять restore.

При зависании главное — не начинать с reboot и qm unlock, а определить, где остановился pipeline:

VM
 ↓
QMP
 ↓
PVE backup worker
 ↓
сеть / TCP 8007
 ↓
proxmox-backup-proxy
 ↓
PBS task
 ↓
datastore

Если QMP timeout возникает сразу на множестве VM, а PBS продолжает хранить незавершённые server-side tasks после того, как PVE уже признал backup failed, нужно анализировать обе стороны одновременно.

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