Files
admin/.tasks/nas-recovery.md
vitya c55cb11948 tasks: merge imported MoreThenCms task history with admin live agenda
- 7 admin per-task files moved from .tasks-imported/ to .tasks/ (renames)
- NEXT-SESSION-PROMPT.md (iis-migration session handoff) kept as sibling
- .tasks-imported/STATUS.md removed (content merged into admin STATUS.md)
- admin STATUS.md gains 'Imported from MoreThenCms' section with all 7 admin
  done tasks verbatim. 4 CMS-domain task blocks excluded (stay in MoreThenCms):
  cms-admin-assets-root-folders-seed, cms-port-leak-fix,
  traefik-maljarka-502-bug, cms-maljarka-https-mode-bug-fix
- morecms-subtree-split marked done (acceptance: 4 split branches exist with
  per-file history)
- admin-subtree-import-and-cleanup marked active (in-progress this session)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-21 13:51:48 +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):

  1. Phase 1 — DB via .bak dump ( путь определён):

    • SFTP с ~/sftp-pickup/MoreThenCms202605090301.zip на Windows.
    • Expand-Archive → получаем .bak.
    • В MSSQL-контейнере (уже работает на localhost:1433) → RESTORE FILELISTONLY → потом RESTORE DATABASE ... WITH MOVE.
  2. 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/.
  3. 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.
    • Сайты отвечают локально.
  4. 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.

  1. 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.