Короткий ответ

Сбой backup на PBS — это не «пересоздать datastore». Проверьте с pve1: доступ к PBS (10.0.10.40:8007 или pbs1.contoso.example), fingerprint хранилища в PVE, имя datastore, квоту и свободное место на стороне PBS, учётку backup. Не удаляйте datastore в GUI PBS, чтобы «сбросить ошибку»: потеряете chunk.

vzdump на NFS — другая статья. Здесь — proxmox-backup-client / storage type pbs.

Симптомы и как отличить

Типичная картина:

  • Task log: TLS/fingerprint mismatch после переустановки PBS;
  • quota exceeded / datastore full;
  • timeout на verify;
  • GUI PVE storage PBS красный.

Отличия:

Что видноКуда
Архив vzdump .vmavzdump
Restore из PBS в VMIDRestore
Хост iowait во время backupIO wait
PVE storage вообщеХранилище

Возможные причины

  1. Неверный или устаревший fingerprint в storage.cfg.
  2. PBS недоступен: DNS, firewall 8007, сервис.
  3. Quota datastore / диск PBS 100%.
  4. Неверные user/token, права на datastore.
  5. GC/verify держат IO, timeout.
  6. Часы, TLS.

Диагностика

На pve1:

pveversion
pvesm status
grep -A20 '^pbs:' /etc/pve/storage.cfg
nc -vz 10.0.10.40 8007

На PBS (если есть доступ):

df -h
# GUI PBS: Datastore usage, GC status
systemctl status proxmox-backup.service --no-pager

Сверьте fingerprint из GUI PBS (Dashboard/certificate) с полем fingerprint в PVE storage.

Журнал job на PVE — полный Task. Ищите quota, 401, fingerprint, connection.

Решение

Сценарий A. Fingerprint

Скопируйте актуальный fingerprint из PBS в свойства storage на PVE. Повтор job для VM 101. Не отключайте проверку сертификата «навсегда» как политику.

Сценарий B. Нет 8007

DNS pbs1.contoso.example, маршрут, firewall. PBS слушает 8007 по умолчанию. Не путать с 8006 гипервизора.

Сценарий C. Квота / место

Поднимите quota, почистите prune по политике (не все namespaces), расширьте диск PBS. GC после prune освобождает место не мгновенно — дождитесь или запустите GC штатно в GUI PBS.

Сценарий D. Auth

User backup@pbs / API token с правом DatastoreBackup. Срок токена. 401 в логе — не fingerprint.

Сценарий E. Timeout / IO

Снизьте параллелизм, не бэкапьте все VM сразу, проверьте диск PBS. Verify job отдельно от backup.

Клиент на PVE, namespaces и почему «диск есть, квота нет»

PVE ходит на PBS как клиент с fingerprint и datastore id. Ошибка quota при свободном df на PBS — квота datastore в GUI PBS, не раздел. Смотрите Usage vs Quota там.

pvesm status
pvesm list <pbs-storage-id> | grep 101
cat /etc/pve/storage.cfg

pvesm list для PBS показывает snapshots, не qcow. Пустой list при зелёном status — права namespace или неверный datastore name.

GC running во время backup увеличивает latency и даёт timeout. Не выключайте GC навсегда: без него диск PBS только растёт. Разнесите окна.

Смена сертификата Let's Encrypt на reverse-proxy перед PBS ломает fingerprint, если в PVE прописан не тот PEM. Либо клиенты на прямой 8007, либо fingerprint того, что реально терминирует TLS.

Ключ клиентского шифрования (если включено) храните вне PBS. Потеря ключа = бесполезные chunk при живом datastore. Не «пересоздавайте datastore», чтобы обойти неизвестный ключ.

Как проверить, что проблема устранена

Успешный backup 101 на PBS, в GUI PBS появилась новая snapshot. pvesm status для pbs-storage active. Пробный restore файла или VM в новый VMID. Fingerprint в cfg совпадает с сервером. После prune+GC место растёт, если удаляли точки.

На PBS проверьте, что datastore не на том же rpool, что VM-диски pve1, если PBS совмещён. Тогда «квота» и IO wait — один диск. Разнесите.

Сверьте время PVE и PBS: сильный skew ломает TLS и ticket. timedatectl на обоих. Токен API с правом только DatastoreAudit не создаст backup — нужен DatastoreBackup; 403 в Task log, не fingerprint.

После смены fingerprint обновите storage один раз в кластерном storage.cfg: все узлы получат его через pmxcfs. Не прописывайте fingerprint локально в обход /etc/pve.

Если не помогло

  • Только одна VM: агент/диск VM, не PBS — сравните с vzdump.
  • Verify failed: битый chunk, диск PBS SMART; не глушите verify навсегда.
  • Encrypted datastore: неверный ключ на PVE.
  • Смена IP PBS: обновите server в storage, fingerprint если сертификат на IP.
  • Namespace: job пишет не туда, куда смотрите в GUI.

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

  • Мониторинг места PBS, очередь GC.
  • Алерт failed backup на каждом узле, не только на pve1.
  • Документировать fingerprint при смене сертификата.
  • Offsite/второй datastore.
  • Проверка перед работами включая last successful backup.
  • Разнести окна backup, GC и verify; не класть datastore PBS на тот же диск, что VM узла pve1.
  • Проверять timedatectl на PVE и PBS перед сменой сертификата, чтобы TLS не разъехался по времени.
  • Хранить encryption key отдельно от PBS; после смены TLS сразу обновить fingerprint в кластерном storage.cfg.

FAQ

PBS и PVE на одном сервере?

Технически бывает, для продакшена хуже: диск и IO общие. Ошибка места тогда бьёт по VM.

Нужен ли тот же fingerprint на всех узлах кластера?

Да, storage.cfg кластерный. Обновили один раз — всем узлам.

Чем prune отличается от GC?

Prune убирает snapshot из индекса. GC удаляет неиспользуемые chunk. Место после prune без GC может не вырасти.

Можно ли обойти fingerprint?

Плохая практика. Лечите сертификат.

Порт не 8007?

Если сознательно меняли — смотрите фактический listen, не копируйте 8007 из статьи вслепую. В стандартной установке — 8007.

Verify job красный, backup зелёный — данные уже мертвы?

Не обязательно сразу. Verify читает chunk; сбой диска PBS, GC, сеть. Не удаляйте datastore. Снимите SMART/место PBS, повторите verify одной snapshot VM 101, затем решайте про restore-тест.