Files

vitya c86750b75d 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

4.1 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

Dead Synology DiskStation

Source NAS, на котором хостились клиентские сайты MoreThenCms до 2026-05-18. Сейчас off / data unrecoverable средствами DSM.

Hardware

Тип: XPEnology (DSM 7 на самосборном x86, community-loader)
Шасси: 6 HDD bay
Hostname: diskstation
Bootloader: USB-флешка (внешняя относительно дисков)
System SSD: Netac SSD 120 GB (отдельный) — "Отказ системного раздела" к моменту инцидента
DSM hostname в сети: diskstation (LAN), без публичного DDNS (доступ через клиентские домены через traefik)

Storage pool

RAID 5 на 3 дисках WD Red WD40EFAX-68JH4N1 / 68JN4N0 (3.6 TB каждый)
~7 TB usable (/dev/mapper/cachedev_0 7.0T)
⚠️ WD40EFAX = SMR — см. wd40efax-smr-cascade для механики краха.

Что было на NAS

VMM

snolla VM: Windows-VM с IIS + .NET Framework 4.8 + CMS snolla-recovery-vm
MAC: 02:11:32:2A:7C:B9, IP 192.168.1.15 (DHCP-резервация на роутере)
OVA-экспорт от 2024-10-27 включён в Hyper Backup → теперь работает на VirtualBox на windows-recovery-host.

Container Manager (docker)

mssql: Server 2019, 5 БД (MoreThenCms, StayerCalculator, StayerPrice, stostayer, TireService)
minio: RELEASE.2020-07-13T18-09-56Z, 9 бакетов (artmone 2.5 GB, pilorama98 120 MB, books 5 MB, и др.)
elasticsearch: 7.10.1, 3 индекса (для books-стека, не MoreThenCms)
imgproxy + nginx-cache
traefik: 2.6.6, 13 client routes, 40 Let's Encrypt сертификатов
gitea: 2.6 GB
Прочее: jellyfin, mongo, owncloud, navidrome, mariadb, и т.д.

/docker/ — docker-стеки
/docker/personal/ — большая часть production-сервисов
/backup/ — куда писались ежедневные дампы:
- /backup/snolla/SQLServer/MoreThenCms<YYYYMMDDHHMM>.zip — ежедневный sql-script (101 MB compressed)
- /backup/snolla/snolla.ova — 42.5 GB, экспорт VM (последний 2024-10-27)
/work/ — рабочая папка разработчика (в восстановление не брали по решению пользователя)

Что произошло 2026-05-18

См. wd40efax-smr-cascade. Кратко: первый диск умер в начале мая, ~2 недели пул жил degraded, second disk вылетел 2026-05-18 → RAID 5 за пределами redundancy → пул "Сбой сборки" в DSM.

Что НЕ делать с этой коробкой

❌ Repair / Online Assembly в DSM на этом пуле — бесполезно.
❌ Вытаскивать оставшиеся 2 диска до решения "нужно ли pro data recovery".
❌ Пересоздавать пул на тех же дисках.
❌ Ставить новые WD40EFAX (если будут запасные) — же баг останется.

План восстановления железа (после ремонта инфраструктуры)

Заменить все WD40EFAX на CMR-диски (WD Red Plus / Seagate IronWolf / WD Red Pro / HGST Ultrastar).
Заменить Netac SSD на нормальный consumer SSD (Samsung 870 EVO / WD Red SA500).
Конфигурация:
- 3 CMR в RAID 5 + ежедневный Hyper Backup + дисциплина replace failed disk в течение 24-48 часов
- или 4 CMR в RAID 6 (или SHR-2) — толерирует 2 отказа, рекомендуется после такого опыта
Тест восстановления раз в квартал.

4.1 KiB Raw Blame History Unescape Escape