Backup vzdump завершается ошибкой: читать Task log до rerun всех VM

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

На узле pve1 откройте Task log vzdump целиком: там обычно can't lock, no space, timeout guest-agent, ошибка snapshot на local-lvm/rpool/NFS. Не запускайте сразу backup всех VM и не kill -9 vzdump. Снимите lock только если qemu/backup-процесс мертв. Цель — успешный прогон 101 на тот же storage, не «пересоздать job с нуля».

vzdump и PBS — разные стеки. Если цель PBS, см. PBS backup.

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

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

• Datacenter → Backup: failed для 101 или всего job;
• VM остаётся с lock;
• на target storage 0 байт свободно;
• guest-agent freeze timeout, backup идёт без консистентности и падает на snapshot.

Отличия:

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

1. Lock: предыдущий vzdump/migrate не завершился.
2. Нет места на backup storage (часто тот же local).
3. Snapshot не создаётся: thin/ZFS/qcow, или агент завис.
4. NFS stale в середине dump.
5. VM с PCI passthrough / нестандартным диском, snapshot не поддерживается.
6. Имя файла/VMID конфликт, повреждён предыдущий .vma.zst.

Диагностика

pveversion
qm status 101
qm config 101
pvesm status
ls -l /var/lock/qemu-server/lock-101.conf

Job и лог:

cat /etc/pve/jobs.cfg
ls -lt /var/log/vzdump/ 2>/dev/null
journalctl --since '2 hours ago' | grep -i vzdump | tail

В GUI скопируйте TASK ERROR. Ищите space, lock, snapshot, agent, timeout.

Место:

df -h
lvs -a
zfs list rpool

Решение

Сценарий A. Lock

ps aux | grep -E 'vzdump|101' | grep -v grep

Нет процесса — qm unlock 101, повтор одной VM:

vzdump 101 --storage <backup-storage> --mode snapshot --compress zstd

Storage подставьте из pvesm status (не выдумывайте имя). Если процесс жив — дождитесь или отмените задачу в GUI.

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

Очистите backup storage, смените target, prune. Не пишите vzdump на local-lvm с дисками VM. Thin полный — сначала пул.

Сценарий C. Snapshot / agent

Проверьте агент: qm agent 101 ping. Для консистентности Windows/VSS агент должен отвечать. Если snapshot LVM не создаётся — место в пуле, или диск не на snapshot-capable storage. Временно mode stop в окно (простой VM), не как постоянная схема для прод-БД без согласования.

Сценарий D. NFS оборвался

NFS, затем повтор. Несостоявшийся файл удалите только после проверки, что это обрезанный dump.

Сценарий E. Неподдерживаемый диск

CD-ROM на недоступном ISO, RBD с неверными опциями, passthrough LUN — исключите из backup или смените режим по документации PVE 8 для этого типа.

Где лежит лог и как не смешать fleecing с местом на backup storage

В PVE 8 у vzdump есть fleecing (временный том под изменившиеся блоки). Ошибка места может относиться к fleecing storage, не к NFS с архивами. Смотрите опции job и Task log на fleece.

pvesm status
qm config 101 | grep -E 'agent:|scsi0|lock'
ls -l /var/log/vzdump/qemu-101* 2>/dev/null
journalctl -u pvescheduler --since '1 day ago' --no-pager | tail

pvescheduler запускает jobs.cfg. Если GUI job enabled, а CLI вручную проходит — смотрите user, под которым scheduler пишет, и mailto не как диагностику.

Для qcow на directory snapshot vzdump использует qemu backup API. Для LVM-thin — thin snapshot. Для ZFS — zfs snapshot. Текст ошибки cannot create snapshot читайте относительно типа scsi0, не «NFS виноват» по привычке.

Не ставьте mode snapshot на VM с ide диском без поддержки и не ждите чуда. Смените шину в окне или mode stop.

Повтор failed job без разбора lock оставляет 101 с lock-иконкой и ломает уже Start, не только backup.

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

Успешный Task OK для 101. Файл dump растёт до конца, не 0 байт. qm status 101 running без lock. pvesm list <backup-storage> показывает новый архив. Пробный restore в другой VMID — restore, не на живую 101.

Проверьте, не стоит ли у 101 lock: backup в конфиге после failed job. qm config 101 | grep lock должно быть пусто перед повтором. Если job в jobs.cfg имеет repeat-missed и падает по кругу, временно disable job в GUI, почините причину, затем один ручной vzdump 101. Циклический scheduler только увеличивает IO и lock-гонку.

Храните не меньше двух успешных точек на разные backend (PBS и каталог), если политика позволяет: тогда failed vzdump не равен «бэкапа нет».

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

• Падает только на одной VM: диск/агент/размер vs timeout.
• Падают все: target storage или IO.
• После успеха leftover snapshot — статья snapshot.
• Шифрование/PBS mixed в одном ожидании — разведите jobs.
• bwlimit настолько низкий, что timeout job — увеличьте окно, не kill.

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

• Отдельный backup storage, prune, мониторинг места.
• Алерт failed jobs.
• Guest agent в шаблонах.
• Не полный backup всех VM в одну минуту на одном NFS.
• Регулярный test restore.

FAQ

snapshot vs suspend vs stop?

snapshot — меньше простоя, нужен backend. suspend — freeze RAM. stop — выключение. Ошибка «cannot snapshot» не лечится повторным snapshot без места.

Можно ли бэкапить running VM без агента?

Да, crash-consistent snapshot. Для SQL это не замена VSS/дампа.

vzdump на тот же local, что ISO — плохо?

Забьёте корень узла. Вынесите backup.

Нужен ли --remove 0?

Не чистит неудачный файл сам по себе как стратегия. Смотрите prune job.

Почему GUI OK, CLI падает?

Другой storage/mode/compress. Сверяйте параметры один в один.

Падает только incremental PBS, vzdump snapshot жив — это эта статья?

Нет, смотрите PBS backup. Здесь vzdump на directory/NFS/local. Смешивать логи двух стеков — типичная потеря времени: fingerprint не лечит not enough free space на local.