# 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», «План ремонта».