Files
admin/.wiki/entities/dead-synology-diskstation.md
vitya d25c0577c8 import: .wiki/entities/ from MoreThenCms via subtree-split
git-subtree-dir: .wiki/entities
git-subtree-mainline: 6d8d75474d
git-subtree-split: 24661c10fb
2026-05-21 13:46:38 +03:00

4.1 KiB
Raw Blame History

title, type, tags, sources, updated
title type tags sources updated
Мёртвая Synology DiskStation (source NAS) entity
hardware
nas
xpenology
raid
dead
../sources/nas-recovery-session-2026-05-18.md
2026-05-19

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, и т.д.

Shares

  • /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 отказа, рекомендуется после такого опыта
  • Тест восстановления раз в квартал.