Files
admin/recovery-architecture-snapshot.md
vitya 19422352ba 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

128 lines
7.5 KiB
Markdown
Raw 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.
---
title: Recovery architecture — текущая инфраструктура (2026-05-19)
type: concept
tags: [architecture, current-state, snapshot, recovery]
sources: [../sources/nas-recovery-session-2026-05-18.md]
updated: 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]].