Ниже — сжатая, но практичная инструкция: как проверять состояние дисков на сервере с виртуальными машинами и какие сценарии восстановления (и превентивные меры) стоит проработать. Разделю на: мониторинг/диагностика, профилактика, типовые сценарии отказа и пошаговые действия при восстановлении, рекомендации и чек‑лист.
1. Мониторинг и проверка состояния (что и как проверять)
- SMART (наличие и рост "плохих" атрибутов — самый базовый индикатор)
- Утилита: smartctl (smartmontools).
- Просмотр: smartctl -a /dev/sdX
- Краткий статус: smartctl -H /dev/sdX
- Ошибки: smartctl -l error /dev/sdX
- Тесты: smartctl -t short/long /dev/sdX (long — планировать в нерабочее время).
- На что смотреть в первую очередь: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, UDMA_CRC_Error_Count, Power_On_Hours, Spin_Retry_Count. Любое увеличивающееся значение Reallocated/Current_Pending — сигнал к замене диска.
- Для RAID-контроллеров аппаратных:
- Контроллер прячет физические диски: smartctl может не видеть диски напрямую.
- Используйте vendor‑утилиты: storcli / megacli / arcconf / hpacucli / perccli и т.п.
- Примеры: storcli /c0 /eall /sall show, megacli -PDList -aALL.
- Следите за статусом кэша, батареи/эмуляцией кэша (BBU/BBM), предупреждениями в логах контроллера.
- Для программных RAID (mdadm)
- cat /proc/mdstat
- mdadm --detail /dev/mdX
- mdadm --monitor --scan (для интеграции в мониторинг)
- Для ZFS и Btrfs
- ZFS: zpool status -v, zpool scrub <pool>
- Btrfs: btrfs scrub start -B /mountpoint; btrfs scrub status -R /mountpoint
- Для кластерных/распределённых хранилищ
- Ceph: ceph -s, ceph osd tree, ceph health detail, плановые scrubs
- GlusterFS: gluster volume heal <vol> info
- Для гипервизоров и VM-хранилищ
- KVM/libvirt: qemu-img check <image.qcow2> (перед использованием — сделать snapshot/backup), проверить целостность образов.
- VMware ESXi: esxcli storage core device list, проверить health в vCenter (HBA/RAID контроллер).
- Hyper-V: PowerShell Get‑PhysicalDisk / Get‑StoragePool / Get‑VirtualDisk
- Мониторинг и алерты
- Zabbix/Nagios/Prometheus + exporters/agent (smart_exporter, node_exporter с SMART, mdadm exporter, storcli exporter).
- Настроить оповещения на: изменение SMART-атрибутов, появление Current_Pending_Sector, перестал отвечать диск, degraded RAID, zpool degradation, resync > X часов, BBU failures.
- Плановые сканы SMART (cron smartctl -t short и сбор результата) + периодический long test.
2. Профилактика (чтобы минимизировать риск потерь)
- Аппаратно
- RAID (выбор уровня RAID: RAID1/10 для VM-локального хранилища; RAID6 при больших массивов для защиты от 2 отказов).
- ECC-память, надежный контроллер, UPS/источники питания, мониторинг температуры.
- Использовать hot-swap диски, поддерживаемые контроллером.
- Хранение журналов и логов контроллера.
- ПО и архитектура
- Разделять хранилище для VMs и для гостевой ОС по необходимости.
- Использовать файловые системы/пулы с самокоррекцией (ZFS/ceph) если нужна целостность.
- Регулярные снимки (snapshots) + репликация на другой хост/ДС/облако.
- Резервное копирование: образные (agentless/VM snapshot) и файловые (важные данные).
- Тестировать восстановление (периодические "restore drills").
3. Инструменты для проверки целостности образов виртуальных машин
- qemu-img check -r all image.qcow2
- Для LVM: lvdisplay, lvscan, проверка PV/VG
- Для VMware: vSphere Health, datastore alarms, vMotion/Storage vMotion (перед запланированными операциями миграция).
4. Тесты на поверхности/поведенческие тесты (с осторожностью)
- badblocks для проверки поверхности:
- read-only: badblocks -sv /dev/sdX — безопаснее (медленно).
- destructive: badblocks -w ... — ОПАСНО, не запускать на рабочем диске без бэкапа.
- fio для стресс‑тестов IO.
- Проверка логов: dmesg /var/log/messages / syslog (I/O errors, I/O timeout, firmware errors).
5. Типовые сценарии отказа и план восстановления (по архитектурам)
A) Локальный диск без RAID (одиночный диск с VMs)
- Падение: диск полностью умер или много ошибок SMART.
- Последствия: потеря образов/данных.
- Действия:
1. Немедленно остановить/изолировать сервер, чтобы не усугубить состояние.
2. Если есть последние бэкапы — план восстановления: развёртывание на другом хосте из бэкапа/реплики.
3. Если диск частично читается — попытаться скопировать важные образы (ddrescue — для извлечения читаемых данных) на другой диск/НFS.
4. После извлечения/копирования — заменить диск, восстановить ОС/образы из бэкапа, проверить целостность VM.
- Профилактика: никогда не держать критичные VMs на одном диске без резервного копирования.
B) Программный RAID (mdadm), один диск вышел из строя (RAID1/5/6/10)
- Падение: забота mdadm покажет degraded.
- Действия:
1. Проверить /proc/mdstat и mdadm --detail.
2. Если диск явно помечен failed — заменить (hot-swap), добавить в массив: mdadm --manage /dev/md0 --add /dev/sdX.
3. Мониторить пересборку (resync) в /proc/mdstat.
4. После ресинка — проверить ФС (fsck) на монтируемых разделах.
- Если несколько дисков упали и RAID не восстановим — восстановление только из бэкапов (или сложные попытки восстановления с mdadm --assemble --force с экспертным анализом метаданных).
C) Аппаратный RAID (LSI, Dell PERC и т.п.)
- Падение: контроллер сообщит failed/ongoing rebuild.
- Действия:
1. Через утилиту контроллера проверить статус, логи и идентифицировать физический диск.
2. Вытащить/заменить faulty диск (hot-swap).
3. Запустить rebuild (часто автоматический).
4. Мониторить прогресс; после завершения — проверить FS.
5. При множественном отказе (RAID5 потеря 2 дисков) — восстановление из бэкапа.
- Важно: при аппаратном RAID SMART на дисках часто недоступен; полагайтесь на контроллер и его логи.
D) ZFS pool
- Падение: zpool status покажет DEGRADED/FAULTED.
- Действия:
1. Проверить какие vdevs affected.
2. Для выведенного диска: zpool replace pool olddev newdev; ждать resilver.
3. После resilver — zpool scrub pool и анализ scrub results.
4. Если потери данных — восстанавливать из резервной копии или реплики.
- Профилактика: зеркала/RAIDZ2 для защиты от 2 отказов, регулярные scrubs.
E) Ceph/RADOS
- Падение OSD
- ceph health detail показывает недоступные OSD
- Восстановление: перезапуск/восстановление OSD или пересоздать OSD на новом диске/узле; CRUSH репликация восстановит данные по кластерам.
- Риски: если количество недоступных OSD > репликации, потребуется восстановление из бэкапа.
F) Хранилище по сети (NFS/iSCSI/VMFS)
- Если NFS-сервер недоступен — мигрировать VMs (если есть реплики), восстановление из бэкапов. Проверять сетевые проблемы, mount options, lock issues.
- Для iSCSI/SAN — проверять состояние LUN на сторендже; при падении контроллера SAN — аварийный план с восстановлением VM из бэкапов или запуск на реплике.
6. Инструменты для извлечения данных при частичной доступности
- ddrescue (gnu ddrescue) — лучший инструмент для извлечения данных с медленно деградирующих дисков.
- TestDisk/PhotoRec — для восстановления partition/файлов.
- Специализированные сервисы по восстановлению (в сложных случаях, когда диск механически повреждён).
7. Процедуры и приказ действий (runbook) — образец
- Сценарий: обнаружен диск с увеличением Current_Pending_Sector / Reallocated_Count
1. Зафиксировать состояние (smartctl -a, логи контроллера).
2. Поместить диск в список на замену; если массив пока здрав — запланировать замену в maintenance window.
3. Сделать свежие бэкапы/снимки перед заменой.
4. Заменить диск (hot-swap) и запустить rebuild.
5. Мониторить rebuild и делать post-check (fsck / zpool scrub).
6. После успешной замены — удалить диск из списка и обновить документацию и мониторинг.
- Сценарий: внезапный полный отказ диска в рабочее время
1. Оценить impact (какие VMs затронуты).
2. Если RAID/кластеры покрывают отказ — мониторить, уведомить команду, заменить диск.
3. Если нет резервирования — переключиться на резервный хост/восстановить из бэкапа по приоритетам (RTO/RPO).
8. Рекомендации по резервному копированию и RTO/RPO
- Понимать RPO (сколько данных вы можете потерять) и RTO (сколько времени можно быть неработоспособным).
- Для критичных VMs:
- Реал‑тайм репликация на другой узел или облако (VM replication, DR tools).
- Частые инкрементальные бэкапы + ежесуточный full.
- Immutable/air‑gapped backups для защиты от раansomware.
- Для менее критичных — периодические бэкапы/снапшоты.
9. Полезные напоминания и "подводные камни"
- Никогда не делать long SMART test / badblocks / destructive тесты без актуального бэкапа и вне окна нагрузки.
- Не полагаться только на RAID как на бэкап — RAID защищает от отказа диска, но не от удаления/коррупции/малваре.
- Регулярно обновлять прошивки дисков/контроллеров и драйверы, но тестировать эти обновления.
- Проверять целостность бэкапов (restore drill) — бэкап, который не восстанавливается, бесполезен.
- Документировать процедуры замены и контакты поставщиков/waranty.
10. Чек‑лист для внедрения в инфраструктуру прямо сейчас
- Включить SMART мониторинг и алерты (Reallocated, Pending, Uncorrectable).
- Включить мониторинг RAID контроллера и BBU.
- Настроить ежедневные бэкапы и репликацию критичных VMs.
- Проводить периодические scrubs (ZFS) / fsck / mdadm check (вне пиков).
- Подготовить runbook: шаги при degraded, при failed disk, при multi‑disk failure, при контроллер failure.
- Регулярно тестировать восстановление (минимум раз в квартал).
Если хотите, могу:
- Подготовить конкретный runbook под вашу конфигурацию (KVM + mdadm + LVM; или ESXi на аппаратном RAID; или ZFS pool; укажите конфигурацию).
- Составить список команд и мониторинговых алертов с порогами и примерами правил для Zabbix/Prometheus.