Ошибка io error в Proxmox VE почти всегда означает, что гипервизор не может выполнить операцию чтения или записи на дисковую подсистему: виртуальная машина зависает, в журнале появляются строки вида I/O error, dev sda, а задачи бэкапа или миграции обрываются с кодом отказа. Игнорировать такой сигнал нельзя — за ним обычно стоит либо деградирующий накопитель, либо сбойный контроллер, либо проблемы с файловой системой хранилища.
В этой статье разберём, как определить источник сбоя, какие команды помогут локализовать проблему и в каком порядке действовать, чтобы не потерять данные виртуальных машин. Материал ориентирован на администраторов, работающих с Proxmox VE на локальных дисках, ZFS, LVM и сетевых хранилищах.
Что означает ошибка ввода-вывода в Proxmox
Сообщение I/O error — это отказ ядра Linux выполнить операцию с блочным устройством. В контексте Proxmox VE она проявляется по-разному: гостевая система внутри ВМ сообщает о повреждении диска, команда qm start завершается ошибкой, а в веб-интерфейсе хранилище помечается недоступным. Важно понимать, что сам по себе текст ошибки не говорит, где именно сбой — он лишь фиксирует факт неудачной операции.
Типичные источники проблемы можно разделить на несколько групп. Аппаратные: изношенный SSD с исчерпанным ресурсом записи, сыплющийся HDD, перегрев контроллера, неисправный кабель SATA или планка памяти с ошибками. Программные: повреждённая файловая система, деградировавший пул ZFS, переполненный тонкий пул LVM-thin, сбои в очереди запросов при перегруженной дисковой подсистеме.
⚠️ Внимание: при появлении I/O error не перезагружайте сервер «для проверки» и не запускайте ресурсоёмкие задачи вроде scrub или массовых бэкапов. Каждая лишняя операция записи на умирающий диск сокращает шансы спасти данные. Сначала — диагностика и резервное копирование доступного.
Первичная диагностика: логи и состояние дисков
Начните с журнала ядра — именно туда попадают первичные сообщения о сбоях блочных устройств. Выполните в консоли узла:
dmesg | grep -iE "error|fail|ata|nvme"Ищите строки с упоминанием конкретного устройства: ata1.00: failed command: READ FPDMA QUEUED, blk_update_request: I/O error, dev sdb или nvme nvme0: I/O error. Идентификатор устройства в сообщении — это первый подозреваемый. Параллельно проверьте системный журнал за последние часы: journalctl -p err --since "today" покажет ошибки служб, включая pveproxy, qemu-server и хранилища.
Далее запросите данные SMART подозреваемого диска. Утилита smartctl входит в пакет smartmontools, который присутствует в стандартной установке Proxmox:
smartctl -a /dev/sdXОбратите внимание на параметры Reallocated Sector Count, Current Pending Sectors, UDMA CRC Error Count и процент износа для SSD (Percentage Used или аналогичный атрибут вендора). Ненулевые и растущие значения переназначенных секторов — верный признак того, что накопитель нужно менять.
Проверка пулов ZFS и томов LVM
Если виртуальные диски лежат на ZFS, состояние пула смотрят командой zpool status. Обратите внимание на столбцы READ, WRITE и CKSUM — ненулевые счётчики ошибок и статус DEGRADED или FAULTED указывают на конкретный проблемный диск. Ошибки контрольных сумм при исправном «железе» иногда говорят о сбоях оперативной памяти, поэтому при массовых CKSUM-ошибках на разных дисках имеет смысл прогнать memtest.
Для LVM-thin критичен другой сценарий: переполнение тонкого пула. Когда метаданные или данные thin-пула заполнены, операции записи на виртуальные диски начинают завершаться ошибками ввода-вывода, и гостевые системы «падают» в read-only. Проверьте заполнение командой lvs -a — смотрите столбец Data% и Metadata% у тома pve/data. Если значения близки к 100%, срочно освободите место: удалите ненужные снапшоты, переместите или удалите неиспользуемые диски ВМ.
Пошаговый план восстановления
Действуйте от безопасного к рискованному. Сначала — спасение данных, потом — ремонт хранилища, и только в конце — замена оборудования. Ниже чек-лист, который помогает не пропустить критичные шаги.
☑️ Порядок действий при I/O error в Proxmox
Остановите все виртуальные машины и контейнеры, чьи диски размещены на подозрительном хранилище: qm stop и pct stop . Затем, если диск ещё читается, скопируйте образы виртуальных дисков на исправный носитель — например, через rsync или ddrescue для дисков с битой поверхностью. Утилита ddrescue предпочтительнее обычного dd: она пропускает нечитаемые области и возвращается к ним позже, что увеличивает шансы вытащить максимум данных.
После спасения данных можно заняться самим хранилищем. Для ZFS замена диска выполняется через zpool replace, для mdadm-рейда — через пометку диска сбойным и добавление нового. Файловую систему на обычных разделах проверяйте fsck только на отмонтированном томе.
⚠️ Внимание: никогда не запускайтеfsckилиzfs scrubна смонтированном и активно используемом хранилище. Проверка ФС на работающем разделе способна усугубить повреждения вплоть до полной потери тома. Сначала остановите ВМ и отмонтируйте ресурс.
Типичные причины и как их различить
Чтобы быстрее сузить круг поиска, сверяйте симптомы с таблицей ниже. Она не заменяет полноценную диагностику, но помогает выбрать направление проверки.
| Симптом | Вероятная причина | Первое действие |
|---|---|---|
| Ошибки на одном диске, растёт Reallocated Sectors | Деградация накопителя | SMART, копирование данных, замена диска |
| Все ВМ на thin-пуле упали в read-only | Переполнение LVM-thin | lvs -a, освобождение места |
| CKSUM-ошибки на нескольких дисках ZFS | Проблемы с RAM или контроллером | memtest, проверка кабелей |
| Ошибки только на NFS/iSCSI хранилище | Сеть или удалённый сервер | Проверка линка, MTU, логов СХД |
| Сбои под нагрузкой, в простое всё нормально | Перегрев, блок питания, очереди NVMe | Мониторинг температур, стресс-тест |
Отдельного упоминания заслуживают дёшевые бытовые SSD без защиты от отключения питания: в серверных сценариях с интенсивной записью (логи, своп, базы данных внутри ВМ) они быстро исчерпывают ресурс и начинают возвращать ошибки записи. Если вы используете такие накопители под ZFS или Ceph, проверяйте атрибуты износа регулярно, а не только после сбоя.
Особые случаи: сетевые хранилища и Ceph
С сетевыми хранилищами логика меняется: I/O error на стороне Proxmox может быть симптомом проблемы в сети, а не на диске. Для NFS проверьте, не «залип» ли маунт — команда df -h при мёртвом NFS-шаре может подвисать, а mount | grep nfs покажет активные подключения. Проверьте доступность сервера хранения, ошибки на сетевом интерфейсе (ip -s link) и совпадение MTU на всём пути.
В кластерах Ceph смотрите вывод ceph -s и ceph health detail: состояния HEALTH_WARN или HEALTH_ERR с недоступными OSD как раз и приводят к ошибкам ввода-вывода на RBD-дисках виртуальных машин. Не перезапускайте OSD массово — разбирайтесь с каждым сбойным демоном по логам в /var/log/ceph/.
Почему I/O error иногда «исчезает» после перезагрузки
При перезагрузке сбрасываются зависшие очереди команд контроллера и состояние шины, поэтому ошибка может временно пропасть. Это не означает решения проблемы: если сбой вызван деградацией диска или перегревом, он вернётся под нагрузкой. После такого «самоизлечения» обязательно снимите SMART и логи, пока система работает.
Профилактика: как не довести до I/O error
Большинство катастрофических сценариев предотвращается регулярным мониторингом. Вам нужно настроить автоматический контроль трёх вещей: состояния SMART всех дисков, заполнения хранилищ и здоровья пулов. В Proxmox часть этого доступна из коробки — например, уведомления о деградации ZFS приходят на почту root при настроенной почтовой подсистеме.
- 📊 Настройте
smartdс отправкой уведомлений о росте критичных атрибутов SMART. - 💾 Держите заполнение LVM-thin и ZFS-пулов с запасом — у ZFS производительность и надёжность заметно падают при высокой заполненности.
- 🧾 Проверяйте
zpool statusиlvsхотя бы раз в неделю вручную или через скрипт в cron. - 🌡️ Следите за температурами дисков через
smartctl -Aилиsensors— перегрев ускоряет износ. - 🗄️ Поддерживайте регулярные бэкапы через Proxmox Backup Server или vzdump на независимое хранилище.
И последнее: бэкапы стоит не просто создавать, а периодически проверять восстановлением на тестовую ВМ. Архив, который невозможно развернуть, при очередном I/O error не поможет.
FAQ: частые вопросы об I/O error в Proxmox
Можно ли продолжать работать, если I/O error появляется редко?
Не стоит. Редкие ошибки ввода-вывода — обычно начальная стадия деградации накопителя или нестабильности контроллера. Снимите SMART и логи, спланируйте замену диска и усильте резервное копирование. Продолжение эксплуатации без диагностики рискует закончиться внезапным полным отказом.
Виртуальная машина ушла в read-only внутри гостевой ОС — это тот же I/O error?
Чаще всего да: гипервизор вернул ошибку записи на виртуальный диск, и гостевая система перемонтировала файловую систему в режим только чтения для защиты данных. Проверяйте хранилище на стороне узла Proxmox, а не только гостевую ОС.
Поможет ли zpool scrub исправить ошибки?
Scrub лишь выявляет и, при наличии избыточности (mirror, raidz), исправляет повреждённые блоки за счёт копий. На одиночном диске или деградировавшем пуле scrub не восстановит данные, а на умирающем накопителе может ускорить отказ. Сначала диагностика и копирование критичных данных.
I/O error только при бэкапе одной конкретной ВМ — в чём дело?
Возможно, повреждён конкретный блок виртуального диска этой машины. Попробуйте скопировать диск ВМ через ddrescue на другое хранилище и проверьте гостевую ФС. Также убедитесь, что целевое хранилище бэкапов исправно и не переполнено.
Нужно ли менять диск при единичной ошибке в dmesg?
Единичная запись без роста счётчиков SMART может быть следствием временного сбоя шины или питания. Настройте мониторинг и наблюдайте: если ошибки повторяются или растут Reallocated/Pending Sectors — планируйте замену. Решение принимайте по динамике, а не по одному событию.