Растущий счётчик Reallocated Sector Count в выводе smartctl на хосте Proxmox — первый сигнал, что диск, на котором лежат виртуальные машины, начал деградировать, и проверку нужно проводить немедленно, а не после отказа массива. Гипервизор Proxmox VE работает поверх Debian, поэтому вся диагностика накопителей выполняется стандартными Linux-инструментами, но с поправкой на специфику виртуализации: диски могут быть заняты пулами ZFS, томами LVM-thin или проброшены в гостевые системы.
В этой статье разберём, как проверить физическое состояние диска через SMART, протестировать поверхность на битые сектора, диагностировать ошибки файловых систем и пулов хранения, а также настроить регулярный мониторинг. Все команды выполняются из консоли узла — через SSH или веб-интерфейс (кнопка Shell в правом верхнем углу панели Proxmox).
Просмотр списка дисков и общей информации
Прежде чем запускать проверки, нужно точно понять, какие накопители видит система и как они используются. Базовая команда для обзора блочных устройств:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODELВывод покажет имена устройств (sda, nvme0n1), их размер, тип и точки монтирования. Обратите внимание на диски без файловой системы — они могут входить в пул ZFS или RAID-контроллер. Дополнительно полезно посмотреть серийные номера, чтобы при замене не перепутать физический диск:
ls -l /dev/disk/by-id/В веб-интерфейсе Proxmox та же информация доступна в разделе узла: Datacenter → узел → Disks. Там отображаются модели, серийные номера, статус SMART и использование дисков. Это удобная отправная точка, но детальную диагностику удобнее проводить из терминала.
- 💾
lsblk— дерево блочных устройств и разделов - 🔍
ls -l /dev/disk/by-id/— привязка устройств к серийным номерам - 📊
df -h— занятое место на смонтированных ФС - 🧩
zpool status— состояние пулов ZFS, если используются
Проверка SMART через smartctl
Основной инструмент диагностики — пакет smartmontools, который в Proxmox установлен по умолчанию. Команда для полного снятия атрибутов SMART:
smartctl -a /dev/sdaВ выводе смотрите на ключевые атрибуты: Reallocated Sector Count, Current Pending Sectors, Offline Uncorrectable, Power-On Hours и Temperature. Для NVMe-накопителей набор атрибутов другой — там важны Percentage Used (износ в процентах от ресурса) и Media and Data Integrity Errors. Любое ненулевое значение переназначенных или ожидающих секторов — повод планировать замену диска, особенно если счётчик растёт.
SMART поддерживает встроенные самотесты накопителя. Короткий тест занимает пару минут, расширенный — от десятков минут до нескольких часов в зависимости от объёма:
smartctl -t short /dev/sda
smartctl -t long /dev/sda
smartctl -a /dev/sda | grep -A 10 "Self-test"
⚠️ Внимание: если диск подключён через аппаратный RAID-контроллер, прямой доступ к SMART может быть недоступен. Для контроллеров LSI/Broadcom обычно требуется указание типа устройства, например smartctl -a -d megaraid,0 /dev/sda, а точный синтаксис зависит от модели контроллера — сверяйтесь с его документацией.
Если smartctl сообщает, что SMART отключён, включите его командой smartctl -s on /dev/sda. На некоторых USB-дисках и дешёвых адаптерах SMART может быть недоступен в принципе — это ограничение моста, а не неисправность.
Проверка поверхности диска с помощью badblocks
Утилита badblocks сканирует устройство на нечитаемые блоки. Для безопасной проверки без потери данных используется режим неразрушающего чтения:
badblocks -sv /dev/sdaПараметр -s показывает прогресс, -v — подробный вывод. Такая проверка только читает данные и не изменяет содержимое диска, поэтому её можно запускать на занятом накопителе, хотя нагрузка на дисковую подсистему заметно вырастет.
⚠️ Внимание: режимbadblocks -wвыполняет разрушающую запись и безвозвратно стирает все данные на устройстве. Его допустимо применять только к новому или заведомо пустому диску, и перед запуском трижды проверьте имя устройства черезlsblkи/dev/disk/by-id/.
Длительный тест большого диска удобно запускать в screen или tmux, чтобы разрыв SSH-сессии не прервал проверку. Найденные битые блоки на современном диске — почти всегда признак необратимой деградации: накопитель должен был переназначить их сам, и если badblocks их видит, резервная область уже исчерпана или механика отказывает.
Диагностика ZFS, LVM и файловых систем
Если хранилище построено на ZFS, логика проверки меняется: целостность данных контролирует сама файловая система. Состояние пула и ошибки чтения/записи/контрольных сумм показывает команда:
zpool status -vНенулевые счётчики READ, WRITE или CKSUM у конкретного диска указывают на проблемное устройство. Проверка целостности всех данных выполняется скрабом:
zpool scrub rpoolСкраб идёт в фоне и безопасен для работающих ВМ, но нагружает диски. Прогресс виден в том же zpool status. Если скраб находит ошибки контрольных сумм и пул избыточен (mirror, raidz), ZFS исправит их автоматически из целых копий.
Для классических файловых систем (ext4, XFS) на размонтированных разделах применяется fsck. Проверять смонтированный корневой раздел «на живую» нельзя — для системного тома проверку назначают при перезагрузке через shutdown -rF now либо выполняют с rescue-носителя. Журнал ядра также помогает выявить дисковые ошибки:
dmesg -T | grep -iE "error|fail|ata|nvme"| Инструмент | Что проверяет | Разрушает данные | Когда применять |
|---|---|---|---|
| smartctl -a | Атрибуты SMART, история ошибок | Нет | Регулярно, первым шагом |
| smartctl -t long | Встроенный самотест накопителя | Нет | При подозрительных атрибутах |
| badblocks -sv | Нечитаемые блоки поверхности | Нет (режим чтения) | Подозрение на бэд-блоки |
| zpool scrub | Целостность данных и контрольных сумм ZFS | Нет | Планово и при ошибках пула |
| fsck | Структуру файловой системы | Нет (только на размонтированной ФС) | После сбоев, некорректного отключения |
Настройка автоматического мониторинга
Разовая проверка не защитит от внезапного отказа — нужен постоянный надзор. Демон smartd отслеживает изменения атрибутов SMART и запускает тесты по расписанию. В Proxmox он обычно уже активен; конфигурация находится в файле /etc/smartd.conf. Типовая строка для наблюдения за всеми дисками:
DEVICESCAN -a -o on -S on -s (S/../.././02|L/../../6/03)Эта запись включает короткий тест ежедневно в 02:00 и расширенный — в ночь на субботу. После правки перезапустите службу: systemctl restart smartd. Для получения уведомлений на почту убедитесь, что в Proxmox настроен адрес администратора (Datacenter → Permissions → Users) и работает локальная почтовая отправка.
- 📧 Настройте отправку писем с узла, чтобы smartd мог оповещать о деградации SMART
- 🗓️ Для ZFS добавьте регулярный скраб — в свежих версиях Proxmox он уже присутствует в заданиях
cronили systemd-таймерах - 📈 Периодически сравнивайте атрибуты SMART с прошлыми значениями: тренд важнее разового снимка
- 🌡️ Контролируйте температуру дисков через тот же
smartctl— перегрев ускоряет износ
☑️ Регламент проверки дисков на узле Proxmox
Что делать, если SMART «зелёный», но ВМ тормозят
Смотрите задержки дискового стека: iostat -x 2 из пакета sysstat. Высокий %util и await при формально исправном SMART указывают на перегрузку, деградацию кэша RAID-контроллера или износ SSD, который ещё не отразился в атрибутах. Также проверьте, не идёт ли в фоне scrub ZFS или rebuild массива — они законно съедают производительность.
Признаки, что диск пора менять
Не каждая ошибка означает немедленную замену, но ряд симптомов трактуется однозначно. Растущий счётчик переназначенных секторов, ошибки чтения в dmesg, состояние DEGRADED у пула ZFS или регулярные зависания ввода-вывода — веские основания готовить замену. Для SSD критичен показатель износа (Percentage Used у NVMe, Wear Leveling Count у SATA): при приближении к пределу производителя накопитель подлежит замене даже без видимых сбоев.
Порядок действий при замене зависит от схемы хранения. В ZFS новый диск добавляется через zpool replace, в аппаратном RAID — средствами утилиты контроллера. Перед извлечением диска убедитесь, что резервные копии всех важных ВМ актуальны и проверены на восстановление: избыточность массива не заменяет бэкап.
Часто задаваемые вопросы
Можно ли проверять диск, на котором запущены виртуальные машины?
SMART-опрос и self-test безопасны при работающих ВМ, как и скраб ZFS. Неразрушающий badblocks тоже допустим, но создаёт высокую нагрузку — лучше запускать его в период минимальной активности. Разрушающие тесты (badblocks -w) и fsck на смонтированной ФС недопустимы.
smartctl выдаёт ошибку доступа к диску за RAID-контроллером. Что делать?
Аппаратные контроллеры скрывают физические диски. Используйте передачу типа устройства (например, -d megaraid,N для LSI/Broadcom, -d cciss,N для старых HP) или фирменную утилиту контроллера. Точный синтаксис зависит от модели — сверяйтесь с её документацией.
Как проверить NVMe-диск в Proxmox?
Тем же smartctl: smartctl -a /dev/nvme0. Ключевые поля — Percentage Used, Available Spare и Media Errors. Дополнительно можно использовать утилиту nvme (пакет nvme-cli): nvme smart-log /dev/nvme0 и nvme error-log /dev/nvme0.
ZFS сообщает о повреждённых файлах после скраба. Они восстановятся?
Если пул избыточен, ZFS исправляет ошибки автоматически из целых копий. Если избыточности нет, повреждённые файлы перечислены в zpool status -v — их можно восстановить только из резервной копии.
Как часто нужно проверять диски на гипервизоре?
Разумный минимум: непрерывный мониторинг через smartd с почтовыми уведомлениями, короткий self-test ежедневно, расширенный — раз в неделю, скраб ZFS — раз в несколько недель. Ручной разбор атрибутов имеет смысл делать ежемесячно, чтобы отслеживать динамику.