Короткий ответ
Повреждение — это не «перезапустить Daily-VMs». Сначала докажите, какая точка ещё читается: Veeam Health Check / SureBackup / verify файла, PBS verify, WSB — попытка восстановления в другой каталог. Рабочая точка — последняя с успешной проверкой, не обязательно вчерашняя. Не удаляйте остальные точки, пока не восстановили прод: битый инкремент ещё может опираться на живой full.
Никогда не «чините» .vbk утилитами с форумов и не затирайте оригинал VM, проверяя backup.
Симптомы и как отличить
Типичная картина:
- FLR открывается, копирование файла рвётся на середине;
- Instant Recovery стартует и падает на I/O;
- PBS verify job Error на конкретный snapshot;
- WSB restore сообщает, что файл образа повреждён.
Отличия:
| Симптом | Скорее |
|---|---|
| Job Failed вчера, сегодня GUI без новой точки | Ошибка backup |
| Репозиторий недоступен целиком | Repository |
| Файл не найден в точке, другие файлы ок | Файл не восстанавливается |
| Никогда не было verify | Нет проверки restore |
Возможные причины
- Обрыв записи (место кончилось в конце session, сеть).
- Ручное удаление/перемещение части цепочки на
Repo01. - Антивирус/шифровальщик трогал файлы backup.
- Тихие ошибки RAID/диска репозитория, нет scrub.
- Незавершённый transform/synthetic оставил несогласованные файлы.
- PBS: прерванный GC, ручной
rmchunk. - Редкий: баг после обновления, несовместимый перенос репозитория copy-paste.
Диагностика
Репозиторий: \\backup.contoso.example\Repo01, job Daily-VMs, сервер VBR01.
1. Не трогать прод и не чистить точки
Зафиксируйте список точек:
Connect-VBRServer -Server 'VBR01.contoso.example'
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
Sort-Object CreationTime -Descending |
Format-Table Name, CreationTime, Type, AlgorithmСкрин/вывод в заявку. Это карта, по которой пойдёте назад во времени.
2. Verify / Health check (Veeam)
В GUI: Backup → Daily-VMs → точка → Verify (или job Health check, если настроен). Начните с последней точки, при Fail — шаг назад. SureBackup ещё лучше: VM реально стартует в изолированной сети. См. тест restore.
Не запускайте verify всех точек сразу на том же диске, если прод уже ждёт restore: вы ещё больше нагрузите больной массив. Идите бинарным поиском: последняя, середина окна RPO, oldest full.
3. PBS verify
# пример: snapshot конкретной VM в datastore Repo01
proxmox-backup-client snapshot list backup/vm/101 --repository 'backup@pbs@pbs1.contoso.example:Repo01'
# verify job в GUI PBS или:
proxmox-backup-manager verifyКрасный snapshot не удаляйте, пока нет успешного restore из соседнего.
4. WSB
wbadmin get versions -backupTarget:\\backup.contoso.example\Repo01Пробуйте restore одного файла в C:\RestoreTest\ с каждой версии назад, пока не получите целый файл. Не restore на исходный путь.
5. Диск репозитория
SMART/журнал диска, RAID degraded. Если массив сыпется — сначала скопируйте surviving файлы репозитория на другой носитель средствами, которые не переписывают источник. Приоритет: спасти байты, потом разбирать цепочку.
Решение
Сценарий A. Нашли последнюю годную точку Veeam
Восстанавливайте из неё:
- файлы — FLR в другой каталог;
- VM — в другой inventory name / другой VMID, сеть Isolated, см. VM не восстанавливается.
Зафиксируйте timestamp точки как фактический RPO инцидента. Дальше разбор, почему следующие битые.
Сценарий B. Full жив, инкременты нет
Restore из last good full. Потеря — все данные после этой full. Не склеивайте инкременты вручную.
Сценарий C. PBS: один snapshot битый
Restore из предыдущего verified snapshot в новый VMID. Битый оставьте до конца инцидента.
Сценарий D. Весь репозиторий шифрован/пуст
Это уже копии доступны ransomware и offsite/immutable. Локальный Repo01 не лечите decryptor с форума. Ищите вторую копию (tape, object lock, PBS на другой площадке).
Сценарий E. После успешного restore — ремонт репозитория
- Проверьте диск/RAID.
- Вынесите антивирус из on-access на файлы цепочки или исключите каталог документированно.
- Новый full
Daily-VMsна здоровый репозиторий. - Не мешайте старую битую цепочку с новой в одном каталоге без понимания.
Synthetic full на больной цепочке может ухудшить. Сначала good restore, потом новая цепочка.
Как проверить, что проблема устранена
Для инцидента «данные спасены»:
- контрольный файл/сервис из восстановленной точки работает в песочнице;
- checksum важного файла совпал с эталоном, если эталон был.
Для «репозиторий снова годный»:
- Health check/verify последней новой точки Success;
- пробный FLR тестового файла.
Get-VBRBackup -Name 'Daily-VMs' | Get-VBRRestorePoint |
Sort-Object CreationTime -Descending | Select-Object -First 3Не объявляйте победу по зелёному job без verify.
Если не помогло
- Все точки verify Fail: репозиторий целиком; offsite, tape, второй PBS.
- Verify OK, guest не грузится: это ОС/драйверы внутри точки, не «файл копии». Смотрите BMR/VM restore отдельно.
- Повреждается каждая новая точка: умирает массив
Repo01или шифровальщик всё ещё имеет write. Изолируйте репозиторий.
Не отключайте immutability, чтобы «перезаписать битое». Immutability как раз мешает злому перезаписыванию.
После выбора годной точки не смешивайте в одном restore «файл из понедельника и диск VM из пятницы» без записи в тикет: получите Frankenstein, который не воспроизвести. Цепочка Daily-VMs на Repo01 восстанавливается как снимок времени, не как конструктор. Если нужен файл старше, чем живая VM-точка — FLR из той даты, отдельно от Entire VM.
Профилактика
- Регулярный verify/SureBackup, не «когда припрёт». Проверка восстановления.
- Scrub/RAID patrol на репозитории.
- Offsite и immutable: одна площадка с bit rot не должна быть единственной.
- Запрет ручного delete в
Repo01. - Мониторинг Failed verify как P1, не информационный шум.
FAQ
Зелёный Daily-VMs и красный verify — чему верить?
Verify. Job мог не прочитать свои же данные обратно.
Удалить битую точку, чтобы цепочка «схлопнулась»?
Только процедурой вендора после восстановления продакшена и с пониманием, какие инкременты станут бесполезны. Не в первую ночь инцидента.
Можно открыть .vbk архиватором?
Нет. Это не zip. Используйте консоль Veeam.
PBS re-verify починит chunk?
Verify только читает. Лечение — новая копия с источника, если источник жив, или другая точка.
WSB каталог говорит, что версии есть, restore пустой
Каталог мог разъехаться с файлами. Не wbadmin delete catalog до копии оставшихся файлов образа на другой диск.
Нужен ли SureBackup всегда?
Для критичных VM — да, периодически. Health check файлов дешевле и ловит bit rot раньше, чем «VM не встала».