admin/recovery-architecture-snapshot.md

title, type, tags, sources, updated

title	type	tags	sources	updated
Recovery architecture — текущая инфраструктура (2026-05-19)	concept	architecture current-state snapshot recovery	../sources/nas-recovery-session-2026-05-18.md ../sources/iis-host-migration-2026-05-19.md	2026-05-19

Recovery Architecture Snapshot

Снимок production-инфраструктуры на конец 2026-05-19, после отката миграции (попытка миграции на host-IIS не удалась — см. iis-migration-2026-05-19-postmortem). Prod снова через VM snolla-recovery, как было до session start. Это рабочее, но временное состояние — single-point-of-failure на бытовом железе. Замечания по улучшению — future-resilient-architecture-goals.

Цепочка запроса от клиента до CMS (после revert 2026-05-19)

Клиент (browser)
  → DNS resolve (REGRU): *.kzntsv.site, snolla.com, labtools.pro/ru, pilorama98.ru,
       tandemmebel.ru, emspb.ru, kupimknigi.spb.ru, maljarka.tandemmebel.ru,
       sestech.ru, ics-artmaterials.com (rimiz.ru — резолвится, но CMS отдаёт 404)
       → 94.19.247.14 (public IP, статический у провайдера)
  → router OpenWRT (192.168.1.1) [[openwrt-router]]
       → NAT 443 → 192.168.1.143:4443
       → NAT 80 → 192.168.1.143:8000
  → Windows-PC (192.168.1.143) [[windows-recovery-host]]
       → traefik 2.6.6 на 4443/8000
            → TLS termination, certResolver=letsEncrypt из acme.json
            → match по Host header (file-provider rules в data/custom/*.yml)
            → backend = http://host.docker.internal:18080/
       → host:18080 = VBox NAT port forward → VM:80
  → snolla-recovery VM [[snolla-recovery-vm]]
       → IIS на :80, site MoreThenCms.Web (catch-all)
       → ASP.NET CMS code (.NET Framework 4.8)
       → Connection strings:
            → MSSQL: Data Source=10.0.2.2:1433 (VBox NAT gateway = host)
            → MinIO/storage: вопрос снят пользователем
            → Elasticsearch: не используется CMS
  → MSSQL container на host:1433
       → 5 production DB (MoreThenCms, Stayer*, stostayer, TireService)
  ← HTTP response back through chain

Цепочка для stayer'ов (тоже через VM)

Клиент → ... → traefik
       → backend = host.docker.internal:18180 (stostayer) или :18181 (stostayer.old)
  → VBox NAT port forward → VM:8080 или VM:8081
  → IIS в [[snolla-recovery-vm]]
       → stostayer: Data Source=89.253.219.2,1433 (НЕ работающий внешний сервер — но stayer'ы и так не отвечают, по словам user'а)
       → stostayer.old subapps (calc/price/tireService) — отдельные pools

Внимание: stostayer-DB на 89.253.219.2 мёртвая. В host-копии (C:\sites\stostayer\Web.config) уже patched на новый www.stostayer.ru,1433 (user stayer_site) с XML-escape & в password — но это inert. При следующей попытке миграции — этот патч уже готов.

На хосте параллельно (inert, не на prod-пути)

См. windows-recovery-host "Inert" — C:\sites\{snolla, stostayer, stostayer.old, snolla-identity-manager} + IIS sites/pools snolla, stostayer, stostayer.old готовы к переключению traefik, но не активны.

Запущенные docker контейнеры на хосте

Container	Image	Port (host)	Volume
traefik	traefik:v2.6.6	4443, 8000, 8080	named: traefik_traefik_letsencrypt; bind: data/traefik.yml, data/custom/
mssql	mcr.microsoft.com/mssql/server:2019-latest	1433	named: mssql_mssql_data (filled from production tar)
minio	minio/minio:RELEASE.2020-07-13T18-09-56Z	9000	bind: ./data
imgproxy	darthsim/imgproxy:latest	8787	(нет state)
imgproxy-nginx	nginx:alpine	8788	bind: ./nginx/cache, ./nginx/nginx.conf
elasticsearch	elasticsearch:7.10.1	9200	bind: ./data

Все на docker network proxy (external) — это позволяет traefik резолвить minio, elasticsearch, imgproxy-nginx напрямую по docker DNS.

Traefik routes (после revert 2026-05-19)

Все активные routes снова указывают на VM (как было до session). Backups сохранены для следующей попытки миграции.

File	Hosts	Backend	Статус
snolla.yml	snolla.com + 10 subdomains	host.docker.internal:18080 → VM	active
rimiz.yml	rimiz.ru, www.rimiz.ru	host.docker.internal:18080 → VM	active (но CMS отдаёт 404 — известное)
labtools.yml	labtools.ru, www.labtools.ru	host.docker.internal:18080 → VM	active
labtoolspro.yml	labtools.pro, www.labtools.pro	host.docker.internal:18080 → VM	active
pilorama98.yml	pilorama98.ru, www.pilorama98.ru	host.docker.internal:18080 → VM	active
tandemmebel.yml	tandemmebel.ru, www.tandemmebel.ru	host.docker.internal:18080 → VM	active
emspb.yml	emspb.ru, www.emspb.ru	host.docker.internal:18080 → VM	active
kupimknigi.yml	kupimknigi.spb.ru	host.docker.internal:18080 → VM	active
maljarka.yml	maljarka.tandemmebel.ru	host.docker.internal:18080 → VM	active
sestech.yml	sestech.ru, www.sestech.ru	host.docker.internal:18080 → VM	active
isc-artmaterials.yml	ics-artmaterials.com, www.ics-artmaterials.com	host.docker.internal:18080 → VM	active
stostayer.yml	stostayer.snolla.com	host.docker.internal:18180 → VM:8080	active
oldstostayer.yml	old.stostayer.ru	host.docker.internal:18181 → VM:8081	active

Backup-stamp файлы (накопились — для следующей попытки):

• *.yml.bak-phase3-2026-05-19 — original state до Phase 3 (всё указывает на VM). Это именно та конфигурация что сейчас live (свежескопировано в active).
• *.yml.bak-hostip-2026-05-19 — попытка переключения на host.docker.internal:80 (создала loop, см. iis-migration-2026-05-19-postmortem).
• stostayer.yml.bak-stayer-switch-2026-05-19, oldstostayer.yml.bak-stayer-switch-2026-05-19 — попытка stayer'ов на host :8090/:8091 (live теперь снова на VM).

Плюс file-provider маршруты для инфраструктурных хостов:

File	Host	Backend
elasticsearch.yml	elasticold.kzntsv.site	http://elasticsearch:9200 + basicAuth books:...
minio.yml	minio.kzntsv.site	http://minio:9000
imgproxy.yml	imgproxy.kzntsv.site	http://imgproxy-nginx:80

И мёртвые (не отключены, но смотрят в никуда):

• disk.yml → 192.168.1.10:5005 (Synology disk на мёртвой синке)
• dsm.yml → 192.168.1.10:5000 (DSM мёртвой синки)

DNS

Все домены остались указывать на 94.19.247.14 (public IP, статический). REGRU как registrar/DNS. Никаких DNS-изменений во время recovery не требовалось — only router NAT перенастроен.

Backup инфраструктура

Текущая (на момент 2026-05-19):

• kreknin-synology держит Hyper Backup репо мёртвой синки (~430 GB). Новых бэкапов с recovered Windows-PC НЕТ — рабочее состояние на Windows-PC не бэкапится никуда.
• Локально на Windows-PC: C:\nas-recovery\vm-sites\ (~11 GB, дамп IIS sites из VM) — резерв если VM полностью умрёт.

Дыра: если Windows-PC сгорит — ВСЁ ляжет. Никакой репликации, никакого off-site backup для нового рабочего состояния.

SSH ключи и доступ

• windows-recovery-host → kreknin-synology: id_ed25519_kreknin (vitya@195.19.90.188)
• windows-recovery-host → openwrt-router: id_ed25519_openwrt (root@192.168.1.1)
• windows-recovery-host → snolla-recovery-vm: id_ed25519_snolla_vm (vitya@127.0.0.1:8022)

После recovery — отозвать публичные ключи Claude из этих 3 машин (~/.ssh/authorized_keys или эквивалент). См. соответствующие entity-страницы.

Известные открытые баги

1. X-Forwarded headers не передаются от traefik в IIS → CMS делает редирект с :4443 в URL. См. traefik-on-windows-docker-desktop Pitfall 5.
2. rimiz.ru → 404. CMS-side, не инфра — mapping host header → CMS-сайт в БД.
3. acme.json HTTP-01 renewal будет фейлить для доменов с DNS не на нашем IP — нужен переезд на DNS-01 через REGRU до истечения сертификатов (~3 месяца).
4. *C:\inetpub\logs* в VM растёт (6+ GB к recovery). На хосте та же беда если когда-то переключимся.
5. docker.sock provider в traefik не работает — но не блокирует (всё через file-provider). См. traefik-on-windows-docker-desktop Pitfall 3.
6. stostayer DB в VM указывает на мёртвый 89.253.219.2 — stayer'ы публично возможно не работают полноценно (user сказал "стайеры и на VM не работает" — подтвердил). Host-копия уже patched на новый www.stostayer.ru,1433, в VM не правили.
7. MinIO/Azure storage в CMS — вопрос пользователем снят, оставлено как есть.
8. VM network adapter "виснет" периодически (recipe ipconfig /release /renew через guestcontrol в vbox-windows-stability-tuning). Подтверждено ещё раз в сессии 2026-05-19.

Single Points of Failure

• Один Windows-PC (если сгорит — всё ляжет)
• Один публичный IP / провайдер
• Один WiFi-канал
• Один OpenWRT-роутер
• Одна VBox VM snolla-recovery — single instance, обслуживает весь CMS-трафик (после revert)
• Один MSSQL контейнер (single primary, нет replica)
• Один MinIO (single drive, не distributed)

Каждый SPOF — кандидат на улучшение в future-resilient-architecture-goals.