Files

vitya 19422352ba docs(.wiki): ingest NAS recovery session 2026-05-18/19

15-hour cross-hypervisor recovery from WD40EFAX SMR RAID5
cascade failure. 5 entities + 7 concepts + 1 source documenting:

- Root cause: WD40EFAX SMR cascade in 3-disk RAID 5
- Hyper Backup .hbk structure + SFTP-jail / ACL workarounds
- OVA from Synology VMM (KVM) → VirtualBox: SCSI→SATA,
  Hyper-V driver disable, paravirt=kvm, GA install, NAT switch
- MSSQL restore via named volume + chown, sqlcmd -x, mssql-conf
- Web.config UTF-16 vs UTF-8 BOM IIS 500.19 trap
- Traefik on Windows DD: configFile, named volume for acme.json,
  file-provider as docker.sock workaround
- Snapshot of current recovery architecture + SPOF list
- Placeholder for future resilient-architecture work

Plus .tasks/nas-recovery.md and STATUS.md updates closing the task.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-19 11:07:38 +03:00

6.2 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

WD40EFAX SMR Cascade

Сценарий смерти RAID 5 на WD Red WD40EFAX (SMR-диски). Случился 2026-05-18 на dead-synology-diskstation. Известная community-проблема, не уникальная.

Что такое SMR

SMR (Shingled Magnetic Recording) — способ записи на пластины, где дорожки наезжают друг на друга как черепица. Плюс: больше плотность, дешевле гигабайт. Минус: запись на одну дорожку физически портит соседние → нужна re-write whole "zone". Запись стала зональной (вместо random-access).

CMR (Conventional Magnetic Recording) — стандарт, дорожки независимые.

Где SMR ломается

Сценарий	CMR	SMR
Sequential write	✅	✅
Чтение	✅	✅
Random writes (БД, активная FS)	✅	❌ просаживается
RAID rebuild	✅	❌❌ смертельно

Во время RAID-rebuild диск получает долгую sustained-нагрузку: parity-чтение + запись на новый диск. SMR-firmware пытается жонглировать зонами; внутренний CMR-кэш (есть в начале диска) забивается. Performance падает в 5-10 раз → command timeouts → RAID-контроллер выкидывает диск из массива.

Скандал WD

WD в 2018-2020 тихо перевёл часть линейки "WD Red" (заточена под NAS) на SMR, не указав в маркировке. Community catch'нуло (Reddit, Servethehome, forum.synology). Class-action в США 2020, WD settled. После — WD переименовал CMR-варианты в "WD Red Plus" / "WD Red Pro"; "WD Red" без Plus остался SMR.

WD40EFAX-68JH4N1, WD40EFAX-68JN4N0 — главные жертвы. Если в RAID — лотерея.

Конкретный путь к смерти (наш кейс)

3-диск RAID 5 на WD40EFAX. Storage pool в DSM на cachedev_0, 7 TB usable.
Начало мая 2026 — один из 3 дисков вылетел (вероятно тайм-аут под нагрузкой, не физический отказ).
Пул degraded. RAID 5 на 3 дисках теперь толерирует 0 дополнительных отказов.
2 недели пользователь не заменил failed диск. Пул работал в degraded; оставшиеся 2 SMR-диска делают parity-чтение для любого запроса.
Под этой нагрузкой второй WD40EFAX накопил тайм-ауты (известный паттерн для SMR в degraded-RAID).
2026-05-18 ~17:00 MSK — второй вылет. Пул past redundancy, "Сбой сборки" в DSM Storage Manager.
Виден только Disk 3 + Disk 8 (третий, который вылетел первым, физически не определяется системой даже).

Ключевая ошибка

2 недели в degraded не лечатся. В нормальном RAID 5 на CMR — можно прожить недели без последствий (всё работает). На SMR — каждый день в degraded повышает шанс второго отказа из-за SMR-induced таймаутов.

Правило: при SMR в RAID 5 — 24-48 часов на замену failed диска. Дольше — лотерея. Поэтому SMR в RAID запрещён de facto для серьёзных продакшнов.

Что НЕ делать после второго отказа

❌ Repair / Online Assembly в DSM — пул past redundancy, mdadm не соберёт.
❌ Менять disks в degraded-пуле — может ускорить deterioration оставшихся.
❌ Запускать mdadm --assemble руками с force — без знания внутренней структуры → разрушение partial-data.

Что МОЖНО (но дорого)

Pro data recovery (Storelab/R.LAB/Ace Lab клиенты): $500-3000 typical. Контора берёт диски (все 3, включая failed), делает offline-reconstruct parity, восстанавливает file-tree. Подходит для возврата 9-дневного окна между последним бэкапом (2026-05-09) и инцидентом (2026-05-18).
Условие: диски физически живы (головки не упали). У нас 2 видимых "Исправно" + 1 не определяемый — стандартный кейс для recovery service.

Lessons для будущего

Для следующего NAS-пула:

CMR-only. Никаких WD40EFAX/EFRX/EFAZ/EFGX (если они SMR). Кандидаты:
- WD Red Plus (CMR, маркировка "Plus" — важно)
- WD Red Pro (CMR, enterprise-grade)
- Seagate IronWolf 4TB+ (CMR — модели <4TB могут быть SMR, проверять по datasheet)
- HGST/WD Ultrastar (enterprise CMR)
RAID 6 / SHR-2 при 4+ дисках — толерирует 2 отказа. Один отказ + один SMR-cascade не убивает массив.
Дисциплина replace failed disk в 24-48 часов — в degraded долго не сидеть.
Hot spare если есть place в шасси.
Hyper Backup ежедневно (а не "по триггеру") + retention 30+ дней.
Тест восстановления раз в квартал — мы впервые узнали что наш backup рабочий только когда случился инцидент. Это нехорошо.

6.2 KiB Raw Blame History Unescape Escape