Ошибки при организации систем хранения данных: как избежать и исправить

Семь ошибок закрывают почти все аварии в системах хранения данных: перегруженный пул, отсутствие запаса по ёмкости, плохое охлаждение дисков, неверно выбранный уровень RAID, хаотичная маркировка, неработающее резервное копирование и игнорирование износа накопителей. Каждая проявляется не сразу, поэтому диагностика строится на регулярных проверках, а не на реакции после отказа. Ниже разбор каждой ошибки: причина, последствия и конкретное исправление с командами для ZFS и TrueNAS.

Почему ошибки в хранилищах обходятся дорого

Аппаратный отказ диска предсказуем. По публичным отчётам Backblaze, среднегодовой процент отказов (AFR) в парке из сотен тысяч накопителей в 2025 году держался около 1,5%, а отдельные модели доходили до 3-4%. Для сервера на 24 диска это примерно один отказ за три года, без поправки на партии, нагрев и вибрацию.

Ошибка конфигурации бьёт раньше и сильнее. Пул на 95% заполнения, отсутствие проверенного бэкапа, RAIDZ1 из восьми дисков по 16 ТБ дают отказ именно тогда, когда данные нужны. При этом причиной потери чаще становится не железо, а решение, принятое при проектировании.

Температура ускоряет деградацию. В тех же отчётах Backblaze диски, работающие выше 45°C, показывают заметно более высокий AFR, чем накопители в диапазоне 25-35°C, а разница между 30°C и 50°C измеряется кратно. Корпус 1U с восемью дисками 3.5 дюйма под длительной записью почти всегда уходит за 50°C.

Цена складывается из простоя сервиса, часов работы инженера и потерянных данных. Первые две части считаются деньгами, третья не измеряется. Дальше разберём, где именно системы ломаются и как переделать уже собранные.

Аудит текущей системы хранения: находим слабые места

Аудит занимает 20-30 минут и отвечает на один вопрос: где система порвётся первой. Чек-лист из 10 пунктов, для каждого указан способ проверки.

1. Заполнение пулов. zpool list -o name,size,alloc,free,capacity,health и df -h. Порог тревоги 80%, критический 90-95%.
2. Состояние массивов. zpool status -v: деградация, ошибки чтения и записи, дата последнего scrub.
3. Место на томах и datasets. zfs list -o name,used,avail,refer,quota,reservation.
4. Температура дисков. smartctl -A /dev/sda | grep -i temperature, обход всех устройств из lsblk.
5. Рост переназначенных секторов. smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable".
6. Ошибки ядра и контроллера. dmesg -T | grep -iE "error|fail|ata|nvme|mpt|reset".
7. Дата последнего scrub. zpool status | grep scrub. Норма для домашнего NAS раз в месяц, для нагруженного продакшена раз в две недели.
8. Уровень RAID и число допустимых отказов. Сверить с таблицей ниже и с числом дисков в каждом vdev.
9. Свежесть бэкапов. Проверять не факт создания задачи, а дату последнего успешного запуска и результат тестового восстановления.
10. Документация. Схема подключения и таблица дисков должны совпадать с реальностью, иначе замену диска делать опасно.

Подробности по созданию пулов, настройке SMB и NFS для разных клиентов собраны в практическом руководстве по настройке TrueNAS.

Команды для быстрой диагностики

Пулы и файловые системы:
zpool list -o name,size,alloc,free,capacity,fragmentation,health
zpool status -v
zfs list -o name,used,avail,refer,quota,mountpoint
df -h /mnt/tank

Диски:
lsblk -o NAME,SIZE,MODEL,SERIAL,HCTL,MOUNTPOINT
smartctl -a /dev/sda
smartctl -A /dev/sda | grep -iE "temperature|reallocated|pending|uncorrectable|load_cycle"

События и ошибки:
dmesg -T | grep -iE "error|fail|reset|timeout"
journalctl -k -p err -b

На что смотреть в выводе: health со значением DEGRADED или FAULTED, ненулевые READ и WRITE в ошибках пула, capacity выше 80%, temperature выше 45, растущее Reallocated_Sector_Ct, а также записи об отвалах линка и таймаутах в dmesg. Веб-интерфейс TrueNAS даёт те же данные в Reporting, но CLI показывает историю ошибок и детали vdev, которые в UI скрыты.

Ошибка 1: Перегруз пулов и томов

Причина: пул считали под текущий объём данных, а не под объём через два-три года. Свободное место забирают снапшоты, репликация, временные файлы и распаковка архивов, поэтому порог 80% проходит незаметно.

Последствия: ZFS пишет новые блоки по принципу copy-on-write, ей нужны свободные экстенты для размещения данных и обновления метаданных. Выше 80% заполнения фрагментация растёт, скорость записи падает. Выше 95% возможны отказы записи с ошибкой out of space при формально свободных гигабайтах. Практический пример: пул на 10 ТБ с 9 ТБ данных пишет в 3-5 раз медленнее, чем тот же пул на 60% заполнения, а снапшоты начинают занимать больше места, чем исходные данные.

Исправление: держать заполнение до 80%, ставить квоты на datasets и zvol, чистить устаревшие снапшоты, расширять пул заранее.

zfs set quota=2T tank/media
zfs list -t snapshot -o name,used,creation -s used tank/data
zfs destroy tank/data@daily-2026-01-05
zpool list -o name,capacity,fragmentation

Для zvol, отданных под виртуальные машины, добавляют reservation, чтобы тонкое выделение места не упёрлось внезапно в лимит пула. Ориентир по запасу: свободные 20% должны покрывать двухнедельный прирост данных плюс место под один цикл снапшотов и одну репликацию.

Как расширить пул ZFS без потери данных

1. Проверьте свободные слоты, режим HBA (для LSI и Broadcom нужен IT mode) и убедитесь, что резервная копия есть и восстанавливается. Без проверенной копии дальше идти нельзя.
2. Подключите диски и получите их стабильные идентификаторы: ls -l /dev/disk/by-id/ | grep -i wwn. Использовать /dev/sdX рискованно, буквы меняются после перезагрузки и переподключения.
3. Добавьте новый vdev того же типа, что уже есть в пуле: zpool add tank mirror wwn-0x5000c500a1b2c3d4 wwn-0x5000c500a1b2c3d5 или zpool add tank raidz2 wwn-...1 wwn-...2 wwn-...3 wwn-...4 wwn-...5 wwn-...6.
4. Дождитесь завершения инициализации и проверьте состояние: zpool status -v. Новый vdev включается в работу сразу, старые данные по нему не перераспределяются.
5. Включите авторасширение, чтобы замена дисков на более ёмкие увеличивала размер пула: zpool set autoexpand=on tank.

Ограничения, о которых забывают. Добавление vdev необратимо: удалить его штатно нельзя. В один vdev не ставят диски разного размера, ёмкость считается по минимальному. Расширить существующий vdev можно только заменой всех его дисков на большие, по одному, с ожиданием resilver между заменами. Команда zpool remove работает только для зеркал и требует свободного места под копию данных. Как выбрать HBA и посчитать ёмкость заранее, разобрано в руководстве по сборке массива хранения на TrueNAS.

Ошибка 2: Недостаточное охлаждение дисков

Причина: корпус собирали по остаточному принципу, вентиляторы выставляли на минимальные обороты ради тишины, диски размещали с шагом в один слот без направленного потока.

Последствия: HDD с температурой выше 45°C отказывают чаще, чем работающие при 25-35°C, а выше 50°C рост отказов становится кратным. Перегрев ускоряет износ механики и увеличивает число переназначенных секторов. В корпусе 1U восемь дисков 3.5 дюйма без продува выходят на 55°C и выше на длинной записи, NVMe при этом упирается в троттлинг около 70-80°C.

Исправление: сквозной поток воздуха спереди назад, вентиляторы с высоким статическим давлением, перфорированные корзины, зазор между дисками, при необходимости замена корпуса на 3U или 4U с более крупными вентиляторами. Для новых сборок считать плотность: восемь дисков в 1U дешевле, но требуют турбин и дают больше шума.

Мониторинг:
for d in /dev/sd?; do printf "%s " "$d"; smartctl -A $d | grep -i temperature; done
smartctl -l scttemp /dev/sda

В TrueNAS пороги и алерты настраиваются в Reporting и System Settings, уведомления уходят по email и в мессенджеры через Alert Services. Рабочий диапазон для HDD 30-40°C, алерт имеет смысл ставить на 42-45°C, аварийный на 50°C. Вентиляторы и фильтры пыли обслуживают раз в квартал: слой пыли на радиаторах корзины легко добавляет 5-7°C.

Ошибка 3: Неверный выбор уровня RAID

Причина: уровень выбирали по принципу "RAID 5 даёт больше места" или по привычке времён дисков на 500 ГБ. Для ёмких HDD такое решение устарело, потому что время пересборки выросло на порядок.

Последствия: RAID 5 и RAIDZ1 на дисках от 4 ТБ пересобираются от 10 до 40 часов, и всё это время массив работает без избыточности. Любая нечитаемая область на оставшихся дисках в этот период заканчивается потерей пула. Чем больше диск, тем выше шанс встретить нечитаемый сектор во время rebuild.

Исправление: выбирать уровень по числу дисков и профилю нагрузки.

Ориентиры по времени пересборки: HDD на 8 ТБ восстанавливается примерно за 10-20 часов, на 16 ТБ за 25-40 часов, на 20 ТБ может уйти больше двух суток. Всё это время избыточность массива снижена. Практическое правило: RAIDZ2 для шести и более дисков, зеркала для баз данных и виртуальных машин, RAIDZ1 только для небольших массивов и холодного архива. Разница между зеркалами и RAID-Z на реальных нагрузках разобрана в материале про проектирование отказоустойчивого NAS на TrueNAS.

Как изменить уровень RAID в ZFS

Сменить уровень на лету нельзя: геометрия vdev фиксируется при создании пула. Работающих вариантов два.

1. Собрать новый пул на свободных дисках с нужным уровнем, перенести данные через zfs send и zfs receive, переключить точки монтирования, старый пул погасить.
2. Освободить диски постепенно, если места хватает: вывести зеркальный vdev командой zpool remove, дождаться перераспределения данных и собрать новый пул.

Схема миграции с минимальным простоем:

zpool create tank2 raidz2 wwn-...1 wwn-...2 wwn-...3 wwn-...4 wwn-...5 wwn-...6
zfs snapshot -r tank/data@migrate-2026-09
zfs send -R tank/data@migrate-2026-09 | zfs receive -F tank2/data
zfs set mountpoint=/mnt/tank2/data tank2/data

Флаг -R переносит снапшоты и свойства. Перед снятием старого пула сверьте данные командой zfs diff и выборочным сравнением контрольных сумм, убедитесь, что сервисы видят новые точки монтирования. Старый пул оставьте выключенным и не уничтожайте минимум неделю: это дешёвая страховка от ошибки в новом массиве.

Ошибка 4: Хаотичная маркировка и отсутствие документации

Причина: сервер собрали быстро, серийные номера не переписали, схема подключения живёт в голове администратора.

Последствия: при замене диска с высокой вероятностью вынимается рабочий. В RAIDZ потеря двух дисков из одного vdev означает потерю пула целиком, а восстановление в этом случае идёт только из резервной копии. Через год никто не помнит, какой диск к какому порту подключён и в каком vdev работает.

Исправление: наклейка на каждом диске с последними символами серийного номера, номером слота и датой установки; таблица инвентаризации в NetBox, DokuWiki или обычном документе; привязка дисков в командах по /dev/disk/by-id, а не по /dev/sdX.

Подсветить нужный диск без выключения помогает функция Identify в TrueNAS и её аналоги: sesutil locate da3 on в FreeBSD, ledctl locate=/dev/sdc в Linux с пакетом ledmon. Работают они при наличии backplane с поддержкой SES. Если подсветки нет, опирайтесь на серийные номера: smartctl -i /dev/sdc и lsblk -o NAME,SERIAL,MODEL,HCTL. Минимум, который стоит завести сегодня: текстовый файл со схемой подключения, скопированный на второй носитель и распечатанный.

Ошибка 5: Отсутствие резервного копирования или его неправильная настройка

Причина: считается, что RAID и снапшоты заменяют бэкап. RAID защищает от отказа диска, снапшоты от ошибочного удаления файла, но ни одно из них не спасает от уничтожения пула, шифровальщика, скачка напряжения или ошибки файловой системы.

Последствия: потеря всех данных сразу, без промежуточных вариантов. Типичная картина: единственная копия на том же сервере, расписание отключили после сбоя и не включили обратно, восстановление никогда не проверялось.

Исправление: правило 3-2-1. Три копии данных, два разных носителя, одна копия в другом месте. Для ZFS это снапшоты по расписанию, отправка через zfs send на второй сервер и отдельная копия вне основной площадки.

zfs snapshot -r tank/data@2026-09-15
zfs send -R tank/data@2026-09-15 | ssh backup zfs receive -F backup/data
zfs list -t snapshot -o name,used,creation -s creation tank/data

Настройка репликации ZFS в TrueNAS

1. Data Protection, Periodic Snapshot Tasks: создать расписание снапшотов, например каждый час с хранением 24 копий плюс ежедневные с ретенцией 30 дней.
2. Credentials, SSH Keypairs и SSH Connections: добавить удалённый сервер. Ключ создаётся автоматически, публичную часть импортируют на приёмник.
3. Data Protection, Replication Tasks, Add: указать источник, назначение, наборы данных, расписание и срок хранения снапшотов на приёмнике.
4. Включить шифрование канала, если репликация идёт через недоверенную сеть, и шифрование самих данных на приёмнике.
5. Проверить статус задачи в Reporting и убедиться, что места на приёмнике хватает минимум на два цикла ретенции.

Для копии, физически недоступной из сети, настраивают отправку на внешние диски или ленточные накопители с ручной ротацией носителей: шифровальщик до такого носителя не дотянется. Порядок настройки разобран в отдельном материале про Air-Gap резервное копирование TrueNAS. Восстановление проверяют раз в квартал: выбирают случайный снапшот, разворачивают его в отдельный dataset и сверяют контрольные суммы файлов. Если своей второй площадки нет, внеплощадочную копию удобно держать на арендованном сервере, например в Timeweb Cloud: машина принимает zfs send по SSH и хранит копию вне вашей стойки.

Ошибка 6: Игнорирование контроля износа дисков

Причина: SMART собирается, но на динамику никто не смотрит. Разовый снимок атрибутов не говорит ничего, значение имеет изменение во времени.

Последствия: диск выпадает из массива внезапно и запускает resilver в самый неподходящий момент, иногда вместе со вторым диском из той же партии.

Исправление: отслеживать четыре атрибута.

• Reallocated_Sector_Ct (ID 5): рост от нуля означает деградацию поверхности. Стабильно растущее значение, диск меняют.
• Current_Pending_Sector (ID 197): секторы, которые не читаются и ждут переназначения. Ненулевое значение при активном обращении опасно.
• Offline_Uncorrectable (ID 198): ошибки, которые не удалось исправить. Даже единичные случаи требуют немедленного scrub и проверки кабелей.
• Load_Cycle_Count (ID 193): число парковок головки. Для моделей с рейтингом 300 000 циклов приближение к этому числу ускоряет износ, у настольных дисков порог ниже.

Дополнительно смотрят Spin_Retry_Count и Command_Timeout, а для SSD Media_Wearout_Indicator и Total_LBAs_Written.

smartctl -A /dev/sda
smartctl -H /dev/sda
smartctl -t long /dev/sda

Длинный тест занимает часы и нагружает массив, поэтому запускают его по одному диску за раз и лучше в окно обслуживания. Автоматический мониторинг закрывает smartd, строка в /etc/smartd.conf:
DEVICESCAN -a -o on -S on -n standby,q -s (S/../.././02|L/../../7/04) -W 4,45,50 -m admin@example.com

Такая строка включает проверки, короткие тесты ночью, длинные по воскресеньям и предупреждения по температуре. В TrueNAS аналогичные алерты встроены, ставить внешний smartd не нужно. Раз в месяц запускайте zpool scrub tank и следите за результатом через zpool status -v. Для массивов на 8-16 ТБ scrub идёт от нескольких часов до суток и замедляет остальные операции, поэтому его планируют на ночь.

Ошибка 7: Слабые места в безопасности хранилища

Причина: шары открывали для удобства, гостевой доступ включали, чтобы не разбираться с правами, шифрование откладывали как сложное.

Последствия: шифровальщик получает доступ к смонтированным ресурсам и затирает всё, до чего дотягивается учётная запись, включая снапшоты и локальные бэкапы. Открытый NFS с опцией no_root_squash позволяет клиенту писать от имени root и менять права на данные.

Исправление: минимум прав, отдельные учётные записи для сервисов, отключение гостевого доступа, ограничение экспортов по IP, шифрование данных и защита питания.

Для NFS в /etc/exports:
/mnt/tank/data 10.20.0.0/24(rw,sync,root_squash,no_subtree_check)

Шифрование ZFS включается на уровне dataset и наследуется потомками:

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/secure
zfs get encryption,keyformat,keystatus tank/secure

Накладные расходы AES-256-GCM на процессорах с AES-NI держатся в пределах 5-15% по пропускной способности, на слабых CPU без аппаратного ускорения потери выше. Ключ хранят отдельно от сервера, иначе шифрование не защищает от кражи железа. Для NFS с Kerberos используют опцию sec=krb5p, которая даёт аутентификацию и шифрование трафика. Питание закрывают через UPS с корректным выключением: пакет nut в Linux или NUT в TrueNAS, чтобы пул успевал сбросить кэш и завершить работу без повреждения.

Практические кейсы: как переделать уже собранную систему

Кейс 1: пул 6x8 ТБ в RAIDZ1 заполнен на 90%

Исходно: один пул из шести дисков 8 ТБ в RAIDZ1, полезная ёмкость около 40 ТБ, занято 36 ТБ. Проблемы: скорость записи просела, места под снапшоты почти нет, защита от одного отказа на дисках 8 ТБ уже рискованна.

Что сделали: добавили шесть дисков 8 ТБ, собрали второй пул в RAIDZ2, перенесли данные и вывели старый массив.

zpool create tank_new raidz2 wwn-...1 wwn-...2 wwn-...3 wwn-...4 wwn-...5 wwn-...6
zfs snapshot -r tank/data@migrate
zfs send -R tank/data@migrate | zfs receive -F tank_new/data
zfs set mountpoint=/mnt/tank_new/data tank_new/data

Перенос 36 ТБ по сети 10 Гбит/с занял около 12 часов. Результат: полезная ёмкость выросла до 58 ТБ, пул терпит два отказа, заполнение упало до 62%.

Кейс 2: перегрев дисков в корпусе 2U

Исходно: 12 дисков 3.5 дюйма в 2U, штатные вентиляторы на пониженных оборотах, температура 52-56°C на длинной записи, у двух дисков начал расти Reallocated_Sector_Ct.

Что сделали: заменили корзины на перфорированные, поставили вентиляторы с высоким статическим давлением, разнесли диски зазорами, добавили алерт на 42°C.

Результат: температура стабилизировалась на 34-38°C, переназначенные секторы на проблемных дисках перестали расти, шум вырос умеренно.

Кейс 3: бэкапов нет, есть только локальные снапшоты

Исходно: NAS на восемь дисков, снапшоты каждый час с хранением 48 часов, копии только на том же сервере.

Что сделали: подняли второй NAS, настроили репликацию ZFS по SSH с ретенцией 30 дней, добавили внеплощадочную копию ключевых datasets и квартальную проверку восстановления.

Результат: тестовое восстановление 2 ТБ из снапшота заняло 40 минут и подтвердило целостность данных, окно возможной потери сократилось до одного часа.

Профилактика: как поддерживать хранилище в форме

Регламент, который закрывает большинство сюрпризов.

• Ежедневно: проверить алерты по здоровью пулов, температуре и SMART, убедиться, что ночная репликация и снапшоты завершились успешно.
• Еженедельно: заполнение пулов, свободное место под снапшоты, статус задач, ошибки в dmesg.
• Ежемесячно: scrub пулов, удаление устаревших снапшотов, разбор журналов SMART, проверка восстановления небольшого набора файлов.
• Ежеквартально: полный тест восстановления на отдельном стенде, обновление прошивок HBA и дисков, пересмотр ретенции бэкапов.
• Ежегодно: ревизия документации и схемы подключения, замена дисков с растущими переназначенными секторами, проверка UPS и сценария корректного выключения.

Автоматизация убирает рутину, но не отменяет проверок. Скрипт на cron раз в сутки собирает zpool status, zfs list и smartctl, отправляет отчёт в почту или в Grafana. Аварийный план держат на бумаге: что делать при выпадении двух дисков, где лежат ключи шифрования, как поднять систему после сбоя загрузчика. Порядок действий в такой ситуации описан в материале про критическое восстановление TrueNAS. Если пул потерян безвозвратно, единственный путь возврата данных, развёртывание последней резервной копии и повторная настройка шар по документации.

Начните с двух действий сегодня: проверьте заполнение пулов командой zpool list -o name,capacity и убедитесь, что последняя резервная копия действительно восстанавливается. Эти десять минут закрывают самые дорогие ошибки из списка.