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	2026-05-19

Recovery Architecture Snapshot

Снимок production-инфраструктуры на 2026-05-19, после завершения recovery. Это рабочее, но временное состояние — single-point-of-failure на бытовом железе. Замечания по улучшению — future-resilient-architecture-goals.

Цепочка запроса от клиента до CMS

Клиент (browser)
  → DNS resolve (REGRU): *.kzntsv.site, snolla.com, rimiz.ru, labtools.pro/ru, и т.д.
       → 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
            → IIS site matched by Host header (catch-all binding)
            → MoreThenCms.Web → C:\inetpub\wwwroot\MoreThenCms.Web\
            → ASP.NET CMS code (.NET Framework 4.8)
       → Connection strings:
            → MSSQL: Data Source=10.0.2.2:1433 (VBox NAT gateway = host)
            → MinIO/storage: TBD точная схема
            → Elasticsearch: не используется CMS (там books-стек)
  → MSSQL container на host:1433
       → 5 production DB (MoreThenCms, Stayer*, stostayer, TireService)
  ← HTTP response back through chain

Запущенные 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

13 client домен-маршрутов в data/custom/:

File	Hosts	Backend
snolla.yml	snolla.com + 10 subdomains	host.docker.internal:18080
rimiz.yml	rimiz.ru, www.rimiz.ru	host.docker.internal:18080
labtools.yml	labtools.ru, www.labtools.ru	same
labtoolspro.yml	labtools.pro, www.labtools.pro	same
pilorama98.yml	pilorama98.ru, www.pilorama98.ru	same
tandemmebel.yml	tandemmebel.ru, www.tandemmebel.ru	same
emspb.yml	emspb.ru, www.emspb.ru	same
kupimknigi.yml	kupimknigi.spb.ru	same
maljarka.yml	maljarka.tandemmebel.ru	same
sestech.yml	sestech.ru, www.sestech.ru	same
isc-artmaterials.yml	ics-artmaterials.com, www.ics-artmaterials.com	same
oldstostayer.yml	(старый stostayer)	host.docker.internal:18181 (VM port 8081)
stostayer.yml	stostayer.ru или похожий	host.docker.internal:18180 (VM port 8080)

Плюс 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. MinIO/Azure storage в CMS — точная схема подключения TBD. Пользователь упомянул "не так всё".
3. acme.json HTTP-01 renewal будет фейлить для доменов с DNS не на нашем IP — нужен переезд на DNS-01 через REGRU до истечения сертификатов (~3 месяца).
4. VM один раз "повисла" в сети через 1-2 часа uptime — лечилось ipconfig /release/renew через VBoxManage guestcontrol. Нужен auto-watchdog.
5. *C:\inetpub\logs* в VM растёт (6+ GB к recovery) — нужна ротация.
6. docker.sock provider в traefik не работает — но не блокирует (всё через file-provider). См. traefik-on-windows-docker-desktop Pitfall 3.

Single Points of Failure

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

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