Files

vitya d0f4d1f4ab 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.3 KiB

Raw Blame History

nas-recovery

Goal

Поднять клиентские сайты MoreThenCms на локальной Windows-машине пользователя после краха исходной Synology NAS. Источник данных — Hyper Backup репо /volume1/NetBackup/diskstation_1.hbk на удалённой живой синке (195.19.90.188, kreknin.site:5000), без шифрования, 430 GB, забэкаплены /backup, /docker, /work мёртвой синки.

Key files

_Syno_TaskConfig на удалённой синке — метаданные задачи Hyper Backup (rsync Server 1, source diskstation).
C:\Users\vitya\projects\MoreThenCms\Web.config — connection strings CMS, надо будет переписать на localhost:<port>.

Decisions log

2026-05-18: восстанавливаем не через HBE/SFTP-пулл всего .hbk, а через selective restore на самой удалённой синке → SFTP-пулл только плоских файлов (для 430 GB через узкий канал — единственный реалистичный путь).
2026-05-18: для БД — путь через .bak дамп (если есть в /backup) + RESTORE DATABASE в новый контейнер MSSQL на Windows. Fallback — extract из docker volume.
2026-05-18: VM с мёртвой синки не восстанавливаем — она была runtime, не data. CMS гоняем нативно на Windows IIS.

Open questions

Что такое snolla.ova — OVA-экспорт Windows-VM с MoreThenCms или что-то другое? Если VM-снапшот — план переключается на "импорт OVA в Hyper-V на Windows-PC", всё остальное (IIS, .bak, MSSQL container, MinIO config) становится опциональным fallback.
Свежесть OVA-экспорта (если это он)?
Точная мажорная версия MSSQL? (от неё зависит тег image локального контейнера — нельзя восстанавливать .bak в младшую версию)
Что лежит в /work (взят целиком)?

Inventory с remote (видно в DSM summary восстановления, версия 09.05.2026):

backup/: SRV-1135520-1, books, snolla (← вероятно SQL-дампы для MoreThenCms)

docker/: buildkit, cancel-music, code-server, gitea, hermes, infrastucture (sic), mosquitto, openclaw, personal, portainer, traefik, zigbee2mqtt

work/ — взят целиком, состав смотрим на месте.

Выбраны для restore (10.05.2026, в работе): всё перечисленное выше.

Completed steps

Подтверждена структура .hbk репо, прочитан _Syno_TaskConfig: задача rsync Server 1, без шифрования, source = diskstation, бэкап папок /backup, /docker, /work.
Подтверждён доступ к DSM удалённой синки через http://kreknin.site:5000 (HTTPS 5001 наружу не проброшен — пароль идёт по plain HTTP, после восстановления обновить).
На удалённой синке — root в SSH, юзер vitya — DSM admin. 6 TB свободно — selective restore в /volume1/NetBackup/restore-tmp/ влезает.

Notes

Этапы в правильном порядке (актуальная редакция после находки snolla.ova + ежедневных .bak):

Phase 1 — DB via .bak dump (✅ путь определён):
- SFTP с ~/sftp-pickup/MoreThenCms202605090301.zip на Windows.
- Expand-Archive → получаем .bak.
- В MSSQL-контейнере (уже работает на localhost:1433) → RESTORE FILELISTONLY → потом RESTORE DATABASE ... WITH MOVE.
Phase 2 — MinIO data (после распаковки /docker/personal/minio/ на синке):
- sftp-pickup → tar/zip → SFTP на Windows → распаковка в C:\Users\vitya\projects\docker\diskstation\minio\data\.
- docker compose up -d в minio/.
Phase 3 — OVA в VirtualBox (главный runtime):
- FileZilla тянет snolla.ova (42.5 GB).
- Импорт в VirtualBox 7.2.8 (уже установлен).
- Стартуем VM, проверяем что IIS поднялся.
- Правим Web.config: connection strings → MSSQL <windows-host-ip>:1433 и MinIO <windows-host-ip>:9000.
- Сайты отвечают локально.
Phase 4 — delta файлов (по ситуации):
- 3-4 GB файлов между состоянием Oct 2024 (в OVA) и May 2026 (свежие данные).
- Источник — /work/ из restore, или билд из локального git-репо MoreThenCms.

Архитектура важно: IIS внутри VirtualBox VM (из OVA), НЕ на Windows-хосте. Host-IIS (W3SVC), который установлен — избыточен и должен быть остановлен (Stop-Service W3SVC; Set-Service W3SVC -StartupType Manual) перед запуском traefik, чтобы не было port-конфликта на 80/443. Traefik в Docker на хосте → forwarding на IP VM.

Phase 5 — traefik + imgproxy + DNS + Let's Encrypt (production exposure):
- SFTP /volume1/docker/traefik/ (compose + acme.json + data/) на Windows.
- SFTP imgproxy-стек (расположение TBD: возможно docker/infrastucture/imgproxy/ или docker/personal/imgproxy/ или отдельная папка). Найти через grep -ril imgproxy /volume1/docker/.
- Поднять traefik + imgproxy контейнеры с теми же middlewares.
- imgproxy указывает на локальный MinIO (http://minio:9000/<bucket>/...) — connection URL внутри docker network proxy.
- DNS *.kzntsv.site → новый Windows-host IP.
- Acme.json сохраняем — сертификаты валидны до истечения, потом auto-renew через REGRU DNS-01.

6.3 KiB Raw Blame History Unescape Escape