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

Живую VM 101 на pve1 не затирайте restore «в тот же ID», пока не решили, что оригинал уничтожен. Штатный путь: restore в свободный VMID (плейсхолдер 201), другой MAC, проверка boot, затем плановое переключение. Ошибки restore — место на local-lvm/rpool, offline storage, существующий volume, битый архив.

qm destroy 101 — не шаг restore.

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

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

  • GUI Restore пишет failed;
  • VM 101 already exists;
  • создался пустой 201 без диска;
  • архив .vma.zst не читается.

Отличия:

Что видноКуда
Backup не создаётсяvzdump
Restore прошёл, VM не стартуетСтарт VM
Storage красныйХранилище
PBS restorePBS как источник, этот же принцип VMID

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

  1. Целевой VMID занят.
  2. Нет места на выбранном storage.
  3. В архиве диски на storage, которого нет на этом узле.
  4. Unique: MAC, SMBIOS UUID при restore поверх.
  5. Обрезанный dump (прошлый failed backup).
  6. Права/NFS read-only на архив.

Диагностика

pveversion
pvesm status
qm list
ls -lh /mnt/pve/<backup>/dump/vzdump-qemu-101-*

Путь подставьте из вашего directory/NFS storage.

qm config 101
# свободный ID
pvesh get /cluster/nextid

Проверка архива (не разрушает):

# пример имени файла замените на фактическое
vma stat /path/vzdump-qemu-101-DATE.vma.zst

Если команда не принимает zst напрямую в вашей версии — смотрите Task log extract, не выдумывайте ключи. GUI тоже пишет причину.

Решение

Сценарий A. Конфликт ID

В GUI: Restore → VM ID 201, storage local-lvm (или куда есть место). Не Unique при живой 101 на том же L2 — получите два одинаковых MAC/IP. Для теста выключите NIC или изолируйте VLAN.

CLI-логика (имена файлов свои):

qmrestore /path/vzdump-qemu-101-DATE.vma.zst 201 --storage local-lvm
qm status 201

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

Сначала место на целевом storage, thin. Restore не сжимает диск магически до свободных 5 ГБ.

Сценарий C. Storage mapping

Архив с диском с NFS, restore на узел без этого NFS — укажите другой storage в опциях restore. Не создавайте пустой scsi0 вручную параллельно.

Сценарий D. Битый архив

Не лечится повторным restore. Берите предыдущую точку, проверяйте backup job.

Сценарий E. Нужно вернуть именно ID 101

  1. Восстановить в 201, убедиться что грузится.
  2. Окно: выключить 101, переименовать/освободить ID только осознанной процедурой (destroy после копии данных или rename), либо оставить 201 как новую боевую и сменить DNS/IP.
  3. Не restore поверх running 101.

Проверка архива, unique и сеть после появления 201

Restore в 201 создаёт новые тома. Пока не убедитесь в boot, не меняйте DNS на этот IP. Два SQL с одним hostname в одном VLAN — хуже, чем подождать.

qm config 201
qm config 101
pvesm list local-lvm | grep -E '101|201'
ip -br link | grep tap

Сравните scsi0 size у 201 с оригиналом. Если restore урезал диск из-за опции — это не «магия сжатия», вы выбрали меньший storage/лимит. MAC 201 должен отличаться, если обе VM в одном L2. smbios1 uuid — по лицензии ПО.

Если GUI restore создал VM без диска (ошибка на полпути), не Start. Разберите leftover: qm config 201, тома vm-201-*. Пустую оболочку можно destroy только 201, после сверки что не тронули vm-101-*.

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

qm status 201
qm config 201
qm start 201

Гость boot, сеть (с учётом MAC), данные на месте. Живая 101 не исчезла. pvesm list local-lvm показывает отдельные тома vm-201-disk-*. Консоль/агент отвечают. После проверки 201 либо вводите в работу, либо выключаете, чтобы не было split-brain приложения (два SQL с одним именем).

Формат архива .vma.zst / .vma.lzo / .tar должен совпадать с тем, что понимает ваша версия qmrestore на PVE 8.2/8.3. Архив с чужого гипервизора (не vzdump) сюда не кладут. Для PBS restore в GUI другой мастер, но правило VMID то же: не затирать живую 101. После успешного restore в 201 отключите NIC или поставьте link_down, пока не смените IP — иначе конфликт с оригиналом.

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

  • Restore OK, Windows «восстановление»/boot loop: внутри гостя, не PVE; не форматируйте scsi0.
  • Только PBS chunk missing: чините PBS datastore, не vzdump CLI.
  • unique не сняли: конфликт DHCP. Смените MAC на 201.
  • Очень долгий restore: IO, не ошибка; не запускайте второй restore в тот же ID.
  • После restore нет net0: добавьте bridge=vmbr0, не копируйте MAC с 101 в том же VLAN.

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

  • Test restore по расписанию в изолированный VLAN.
  • Именовать backup storage и хранить больше одной точки.
  • Документ: какой VMID куда восстанавливать при аварии.
  • Не использовать один и тот же ID как «и прод, и тест».
  • Мониторинг размера архивов vs свободное место.

FAQ

GUI «overwrite» существующей VM?

Это замена дисков. На живой прод-VM — почти всегда ошибка процедуры. Новый ID безопаснее.

Можно ли restore на другой узел кластера?

Да, если storage доступен или вы выбрали local того узла. Конфиг попадёт в /etc/pve.

pct restore для этой VM?

Нет, это LXC. QEMU — qmrestore/GUI VM restore.

Нужно ли менять SMBIOS UUID?

Для тестирования рядом с оригиналом — да (unique). Для замены железа той же лицензии — по политике ПО.

Restore в тот же VMID после destroy?

Только когда destroy был сознательный и тома не нужны. Сначала list backup, потом destroy, не наоборот.

Restore «успех», а гость просит активацию Windows — это битый архив?

Часто нет: сменился SMBIOS UUID/MAC при unique. Это лицензирование гостя, не ошибка qmrestore. Для замены железа той же VM планируйте unique заранее, не после паники пользователей.