admin/.tasks/2026-08-03-00830-kreknin-repair-md3-rebuild.md

kreknin-repair-md3-rebuild

Goal

Восстановить kreknin-synology md3 raid5 (data /volume1) до полной избыточности после продувки компрессором 2026-07-31. sdb (WD-WX32D12L8HTE) не определяется → переподключить/заменить → ребилд md3. Заодно починить кабели sda (1.5 Gbps / 213 CRC) и sdc, и вернуть ежедневные бэкапы (сейчас DISABLED).

Context

• Инцидент 2026-07-31: Алексей продул NAS пром-компрессором → срыв SATA-кабелей. sdb выпал (md3 [_UU] degraded), sdd (VMM SSD) выкинут DSM из md2 (восстановлен в тот же день: Repair пула + «Преобразовать в чтение/запись» → /volume2 rw, scrub 53GiB 0 ошибок), sda кабель (213 CRC, линк 6→1.5 Gbps), sdc bursts при трясе кабелей (без тряса стабилен).
• Rescue 2026-07-31→08-02: полный слив в /mnt/rescue (USB 2TB btrfs): netbackup/*.tar (diskstation_1.hbk 430G, windows-host 160G, vds-kzntsv 84G, ruvds-iis 62G, books-vds 24G, openwrt 20K) + userdata/*.tar (docker 130G, homes 118G, work 32G, downloads 25G, documents 5.9G). Итого 1.1TB / 726G free. Данные в безопасности → риск power-off приемлем.
• Бэкапы ЗАГЛУШЕНЫ (не нагружать больной массив): vds-kzntsv /etc/cron.d/vds-backup (05:00), books-vds /etc/cron.d/books-vds-backup (06:00) — строки закомментированы (#DISABLED-kreknin-sick), бэкап-файлы .bak.20260731 сохранены.

Open questions

• Координация power-off с Алексеем (физическая работа на месте).
• Свежие SATA-кабели наготове?
• sdb реально мёртв или просто отвал кабеля? (решится после перетыка)
• 4TB замена, если sdb дохлый.

Steps

1. Подготовка (до power-off)
   • Rescue полный и .tar на месте (проверено: 11 файлов, 1.1TB, все rc=0 кроме docker rc=1 = норма для живых данных)
   • Бэкапы DISABLED (проверено: оба cron закомментированы)
2. Power-off — плановый, с Алексеем. Graceful shutdown DSM (synopoweroff / DSM Shutdown), не грубое выдёргивание.
3. Переподключение кабелей (Алексей физически)
   • sda (ata1): свежий SATA data + питание
   • sdc (ata3): свежий SATA data + питание
   • sdb: питание + SATA
   • sdd (ata4): проверить контакт (уже восстановлен, перетык не помешает)
4. Power-on + верификация
   • все в /dev/sd?: sda sdc sdd (и sdb если ожил)
   • SMART каждого: CRC/pending/reallocated
   • sda линк 6.0 Gbps (не 1.5), CRC не растёт
   • mdstat: md0/1/2 healthy, md3 всё ещё [_UU] (sdb ещё не в массиве — норм)
   • /volume1 rw, /volume2 rw
5. sdb recovery
   • sdb определился + SMART ок → DSM Storage Manager → Repair md3 (выбрать sdb) → ребилд
   • sdb не определился/дохлый → 4TB замена → Repair md3
6. Мониторинг ребилда
   • /proc/mdstat resync %, скорость, ETA
   • sda/sdc НЕ дают новых ошибок во время ребилда (кабель-фикс должен удержать)
   • не выключать и не трогать кабели до завершения
7. Пост-ремонт
   • md3 [UUU] clean
   • btrfs scrub /volume1 (верификация целостности после долгого degraded-периода)
   • VMM виртуалки (sdd) работают, /volume2 rw
8. Вернуть бэкапы
   • vds-kzntsv: раскомментировать /etc/cron.d/vds-backup
   • books-vds: раскомментировать /etc/cron.d/books-vds-backup
   • ручной прогон каждого rsync → green (email/ntfy)
   • снять .bak.20260731 после успешного прогона
9. Hygiene
   • Rescue-диск /mnt/rescue: решить судьбу (оставить/отключить, содержимое = доп. копия)
   • обновить вики/память статусом после ремонта

Verification

• cat /proc/mdstat → md3 [UUU] active clean, resync не бежит
• smartctl -d ata -A /dev/sda → CRC 199 стабилен (не растёт), линк 6.0 Gbps
• btrfs scrub /volume1 → 0 errors
• /volume1/NetBackup/vds-kzntsv/latest свежий (новый rsync-проход)
• backup cron активен (оба раскомментированы), один реальный прогон green

Notes

• Порядок критичен: кабели зафиксировать и проверить ДО запуска ребилда md3 (rebuild — самый стрессовый момент для массива).
• Урок сессии: GNU tar на DSM = --numeric-owner, НЕ --numeric-ids (это bsdtar).
• Урок сессии: DSM «Преобразовать в чтение/запись» снимает ro-состояние btrfs после transient EIO (sdd case) — без mdadm-ручнины.
• Rescue-содержимое и диск-раскладка: .wiki/entities/kreknin-synology.md § «Диски», «Rescue», «План ремонта».