Global HomeLab News: Риск повреждения бэкапов PBS после расширения дисков VM и как это проверить

В сообществе Proxmox описан кейс: после штатного увеличения виртуальных дисков у двух VM новые бэкапы в Proxmox Backup Server выполнялись без явной ошибки, но не проходили verify и restore из-за отсутствующего chunk. По обсуждению это больше похоже не на типовую проблему resize, а на риск в цепочке хранения и дедупликации, в том числе при S3-бэкенде. Для HomeLab это повод усилить контроль целостности после изменения дисковой геометрии.

Что произошло

Оператор с пулом примерно 50 VM сообщил о повторяемой проблеме: после расширения диска (Linux и Windows VM) резервные копии стали считаться поврежденными при проверке и восстановлении.

Симптомы:
- задания backup завершаются без явной критической ошибки;
- verify и restore показывают повреждение;
- в отчете фигурирует отсутствующий chunk;
- аномалия проявилась именно на VM, где меняли размер диска.

По комментариям других администраторов массового подтверждения бага resize нет: у части пользователей такие операции проходят корректно. Подозрение смещается к слою хранения PBS, особенно при использовании S3-совместимого хранилища.

Технические детали

Наблюдаемая цепочка:
1. Расширение виртуального диска VM в Proxmox VE.
2. Расширение раздела или файловой системы внутри гостя.
3. Последующие backup в PBS формально выполняются.
4. verify и restore выявляют missing chunk.

Что важно учитывать:
- успех backup job не равен подтвержденной восстанавливаемости;
- при дедупликации проблема одного chunk может ломать конкретные точки восстановления;
- S3 в PBS для некоторых версий имеет ограничения зрелости, поэтому версия PBS и тип datastore критичны для диагностики;
- инкрементальная цепочка после изменения диска требует обязательной повторной проверки.

Риски и ограничения

• Ложное чувство надежности: расписание backup зеленое, но restore фактически неработоспособен.
• Риск тихой деградации: проблема может касаться только части VM или снапшотов и обнаружиться поздно.
• Ограничения S3-слоя: сетевые и консистентные аномалии могут проявляться именно в verify.
• Удаление старых бэкапов до подтвержденного восстановления повышает шанс потери данных.

Практика для HomeLab (чеклист)

1. После любого resize диска сразу запускать внеплановую проверку целостности.
2. В GUI PBS: Datastore -> Verify.

3. CLI (пример):
   bash proxmox-backup-manager datastore verify <DATASTORE>

4. Делать тестовое восстановление, а не только verify.

5. Минимум: 1 Linux VM и 1 Windows VM из затронутых.

6. Критерий успеха: VM загружается, ФС читается, ключевые сервисы стартуют.

7. Проверить версии PVE и PBS, а также backend хранения.

8. Зафиксировать:
   bash pveversion -v proxmox-backup-manager version

9. Если используется S3-таргет, сверить поддержку и ограничения для вашей версии PBS.

10. Не удалять старую цепочку бэкапов до успешного restore drill.

11. Правило: verify плюс restore test, затем prune и cleanup.

12. Для проблемной VM выполнить сброс доверия к инкрементальной цепочке.

13. Запустить новый full backup, затем verify.

14. Критерий успеха: нет missing chunk, restore проходит.

15. Включить регулярный контроль восстанавливаемости.

16. Ночной verify плюс ежемесячный restore drill на выборке критичных VM.
17. Алертинг по ключевым словам: missing chunk, corrupt, verification failed.

Источник:
- https://www.reddit.com/r/Proxmox/comments/1tn7rf0/pbs_corrupted_backups_after_vm_disk_expansion/
- https://www.reddit.com/r/proxmox/new.json?limit=20