Кратко — причин может быть несколько, и почти всегда это либо проблема нижнего уровня хранения (контроллер RAID / диск / кеш / файловая система / сеть для внешнего хранилища), либо массовая «человеческая/ПО»-ошибка (скрипт/обновление/удаление/шаблон/бекенд), реже — вредоносное вмешательство. Поскольку у вас повреждены файлы внутри большинства VM, но некоторые VM целы, это говорит не о локальной ошибке отдельной гостевой ОС, а о проблеме на уровне хранения/пула образов или массовой операции, затронувшей часть данных.
Ниже — список наиболее вероятных причин, последовательность действий для диагностики сейчас и рекомендации по предотвращению в будущем.
Возможные причины
- Потеря/повреждение данных на уровне RAID/контроллера:
- сбой батареи/энергозависимой кэшей контроллера (BBU/flash) — write-back cache потерял данные при внезапном отключении питания;
- баги/прошивка RAID-контроллера;
- частичные сбои на отдельных физических дисках (silent corruption), перекомпоновка данных могла повлиять не на все VM.
- Проблемы файловой системы / LVM / thin‑пула:
- повреждение метаданных LVM/LVM‑thin, исчерпание метаданных thin‑pool, неправильное управление snapshot'ами;
- повреждение на уровне ZFS/Btrfs (если используется) — ошибки в пуле, пропущенные scrub-и;
- Проблемы СХД по сети (iSCSI/NFS/FC/Ceph):
- сетевые глюки/конкуренция/ошибки на стороне NAS/СХД, баги Ceph/Gluster;
- Баги гипервизора / QEMU / Proxmox:
- известные баги в qemu/drive cache / qcow2 при определённых опциях кэша (cache=unsafe / writeback) или при несоответствии драйверов;
- Массовая человеческая ошибка или скрипт:
- некорректный restore/sync, массовое удаление, перезапись базовых образов/шаблонов;
- Вредоносное ПО / ransomware:
- если было компрометация хоста или домашней сети, злоумышленник мог изменить файлы в гостях (меньше вероятно сразу для большинства машин, но возможно при lateral movement);
- Ошибки ОЗУ (без ECC) — повреждение данных в памяти до записи на диск;
- Проблемы с кворумом/метаданными в распределённых системах (Ceph): частичная потеря OSD/мониторинга.
Что делать сейчас — срочно (сначала: сохранить доказательства)
1. Немедленно остановите дальнейшие записи:
- по возможности выключите (или заморозьте) пострадавшие VM/пулы, чтобы не перезаписать следы.
2. Сохраните логи и снимите «форензические» образы:
- скопируйте /var/log/syslog, /var/log/messages, /var/log/kern.log, dmesg;
- скопируйте логи Proxmox: /var/log/pve/tasks, /var/log/pveproxy, /var/log/qemu/*.log;
- запишите конфигурации pve: /etc/pve/*;
- сделайте побитное изображение (dd) или снимки LUN/RAID метаданных (хэшируйте).
3. Не делайте ремонтных операций на оригинальных данных до создания образов (fsck, zpool import -f и т. п.) — сначала снимок.
Команды для диагностики (выполнять аккуратно, можно прислать результаты)
- Общие сведения о системе:
- pveversion -v
- uname -a
- qm list; pct list
- Диски и RAID:
- lsblk; blkid; cat /proc/partitions
- cat /proc/mdstat; mdadm --detail /dev/mdX; mdadm --examine /dev/sdX
- smartctl -a /dev/sdX (для всех дисков)
- storcli/megacli/perccli show all (для аппаратных контроллеров) — состояние BBU/внешнего кэша
- Файловая система / пул:
- Для ZFS: zpool status -v; zpool history; zpool events; zdb -S poolname
- Для Btrfs: btrfs scrub status; btrfs check (только после бэкапа)
- Для LVM: pvs; vgs; lvs -a -o+seg_monitor; lvdisplay
- Журналы:
- journalctl -k -b | egrep -i 'error|fail|corrupt|raid|md|i/o|io error'
- grep -i 'error\|fail\|corrupt\|IO' /var/log/syslog /var/log/messages /var/log/kern.log /var/log/qemu/*
- QCOW2 и образы:
- qemu-img check -r all /path/to/image.qcow2
- сравнить контрольные суммы образов с резервными (sha256sum)
- Сеть и СХД:
- если iSCSI/NFS: lsscsi; cat /etc/exports; showmount -e <NAS>; проверка логов NAS и сети
- Память:
- dmesg | egrep -i 'memory|edac|mce|uncorrectable'
- if available: mcelog или edac-utils
- Ceph (если есть): ceph -s; ceph health detail; ceph osd tree; ceph osd lost+found
Как понять причину по симптомам
- Если в dmesg/логе RAID есть I/O errors, перепады питания или lost BBU — вероятен контроллер/кеш.
- Если zpool/ceph/бэкенд хранит ошибки/разночтения — виноват пул/распределённое хранилище.
- Если есть одно время массовых записей/удалений/cron-job/скрипт — вероятна человеческая ошибка / автоматизация.
- Если видны подозрительные соединения/процессы или модификации файлов с удалённых IP — возможна компрометация.
- Если контрольные суммы файлов изменились относительно резервной копии ровно в одни временной промежуток — посмотрите логи хоста в этот промежуток (poweroff, reboot, mdadm events).
Рекомендации по предотвращению в будущем
- Хранилище и целостность:
- по возможности использовать проверяющие файловые системы с контрольными суммами (ZFS/Btrfs) или LVM‑volume на уровне raw, не хранить критичные образы поверх ненадёжной FS;
- для аппаратного RAID — иметь рабочий BBU/flash‑backed cache или в настройках переключиться на write‑through (безопаснее) если BBU нет;
- регулярно обновлять прошивки контроллеров и дисков, но тестировать на стенде;
- включить регулярный scrub (ZFS) / проверку (btrfs) и SMART-мониторинг, настроить алерты;
- Настройки виртуальных дисков:
- избегать cache=unsafe / writeback для критичных ВМ; использовать cache=none / direct (O_DIRECT) для лучшей целостности;
- если используете qcow2, планировать регулярную проверку qemu-img и резервных копий;
- LVM raw тома (thin=false) дают более предсказуемое поведение, thin‑pools требуют мониторинга метаданных и лимитов;
- Бэкапы и тест восстановления:
- регулярные, проверяемые backup‑policies; хранить бэкапы как минимально зависимые от хоста (off‑host/remote);
- периодические тестовые восстановления;
- Аппаратное/питание:
- UPS и корректное поведение при shutdown; мониторинг событий питания;
- ECC-память для серверов, где критична целостность данных;
- Безопасность и контроль изменений:
- ограничить права доступа, использовать аудит (auditd), централизованные логи и SIEM, IDS/IPS;
- контроль и ревью автоматизированных скриптов и cron; внедрить CI/CD для изменений;
- Мониторинг:
- на уровне дисков (SMART), RAID, пулов, оперативной памяти, логов; автоматика оповещений (Zabbix/Prometheus+Alertmanager).
- Процедуры реагирования:
- иметь playbook: «сохранить логи», «изолировать СХД», «снять образы», «проанализировать», «восстановить с бэкапа».
Если хотите — могу помочь проанализировать текущее состояние:
- пришлите pveversion -v, вывод zpool status (если ZFS), cat /proc/mdstat и mdadm --detail, smartctl -a для пары дисков, dmesg (за период инцидента) и несколько строк из /var/log/syslog в момент, когда всё началось. С этими данными можно сузить список вероятных причин и дать более точные шаги восстановления и устранения.
Если необходимо — опишите, какое хранилище вы используете (аппаратный RAID + mdadm? ZFS? LVM? Ceph? NFS/iSCSI?), были ли в этот период перебои с питанием/перезагрузки/обновления, и в какое приблизительно время началось повреждение — я подскажу дальнейшую диагностическую последовательность для вашего конкретного случая.