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

69 lines
6.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
- [x] Подтверждена структура `.hbk` репо, прочитан `_Syno_TaskConfig`: задача `rsync Server 1`, без шифрования, source = `diskstation`, бэкап папок `/backup`, `/docker`, `/work`.
- [x] Подтверждён доступ к DSM удалённой синки через `http://kreknin.site:5000` (HTTPS 5001 наружу не проброшен — пароль идёт по plain HTTP, после восстановления обновить).
- [x] На удалённой синке — 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.
5. **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.