import: merge .wiki/concepts/ from temp prefix into existing dir (history preserved via merge+rename)

.wiki/concepts/future-resilient-architecture-goals.md

@@ -0,0 +1,111 @@
+---
+title: Future Resilient Architecture — цели на потом
+type: concept
+tags: [planning, architecture, resilience, roadmap, todo]
+sources: [../sources/nas-recovery-session-2026-05-18.md]
+updated: 2026-05-19
+---
+
+# Future Resilient Architecture
+
+Placeholder для глобальной задачи "выстроить отказоустойчивую архитектуру" — обсуждается **после** того как recovery полностью устаканится.
+
+Эта страница — **черновик целей**, не план. По ходу обсуждения распилится на специфичные концепты + ADR (architectural decision records).
+
+## Что сейчас не так
+
+См. [[recovery-architecture-snapshot]] → раздел "Single Points of Failure". Кратко:
+
+- ⚠️ Windows-PC = SPOF
+- ⚠️ Один public IP
+- ⚠️ Один MSSQL primary без replica
+- ⚠️ Один MinIO single-node
+- ⚠️ Backup только Hyper Backup на одну синку (Kreknin), сейчас она cold
+- ⚠️ Backup нового рабочего состояния (CMS data на recovery-host) **отсутствует**
+- ⚠️ Нет off-site backup (cloud)
+
+## Цели верхнего уровня
+
+1. **RTO** (Recovery Time Objective) — сколько максимум **downtime** клиенты должны видеть при отказе.
+   - Текущий по факту: ~15 часов (что и было).
+   - Целевой: **< 1 час** для одиночного отказа, **< 4 часов** для каскадного.
+2. **RPO** (Recovery Point Objective) — сколько максимум **данных потерять** при отказе.
+   - Текущий: до 24 часов (если успеет бэкап после изменения) — больше если бэкап не успел.
+   - Целевой: **< 1 час**, в идеале continuous (replication).
+3. **Стоимость** — bounded by разумным % от выручки клиентов.
+4. **Operational simplicity** — никаких heroic ops по 15 часов в случае проблемы.
+
+## Технические направления (наброски)
+
+### Backup-стратегия 3-2-1
+
+Стандарт: **3** копии данных, **2** разных media, **1** off-site.
+
+- **Копия 1:** primary storage (live) на NAS / Windows-PC
+- **Копия 2:** local backup target ([[kreknin-synology]] остаётся, плюс отдельный)
+- **Копия 3:** **cloud off-site** — Backblaze B2 / Yandex Object Storage / AWS S3 Deep Archive / Hetzner Storage Box
+- Все backups encrypted client-side
+- Retention: 7 daily / 4 weekly / 12 monthly
+
+### Compute resilience
+
+Варианты:
+
+A. **Multi-host on-prem:** 2-3 физических машины с виртуализацией (Proxmox VE), HA-кластер, VMотом migration. Дорого, но автономно.
+
+B. **Cloud-first:** перенос CMS-стека в managed Kubernetes (Yandex Cloud / VK Cloud / hetzner) — managed MSSQL / managed S3 / managed Postgres. Простота операций, но vendor lock-in.
+
+C. **Гибрид:** primary on-prem (Synology с CMR), warm standby в cloud (готовый к failover за 5 мин). Compromise.
+
+### Database resilience
+
+MSSQL options:
+- **Always On Availability Groups** (требует Enterprise license — недёшево)
+- **Log Shipping** (бесплатно, но manual failover)
+- **MSSQL → PostgreSQL миграция?** (если есть полная свобода — выгоды Open Source + распространённые managed предложения).
+
+Для recovery-сценария: **continuous backup** через VDI + native MSSQL TDE backup → S3.
+
+### Network resilience
+
+- **Multi-WAN на OpenWRT:** primary провайдер + 4G/LTE USB-modem как failover. OpenWRT mwan3 package.
+- **Cloudflare Proxy / Tunnel:** перенаправление публичного трафика через Cloudflare edge. Помогает с DDoS и переключением IP без DNS-changes.
+- **Static IP пересмотр:** разные провайдеры → multi-homed setup.
+
+### Monitoring + auto-recovery
+
+- **Healthchecks** на каждый layer (TCP, HTTP, deep DB query) — Prometheus + Alertmanager или Uptime Kuma.
+- **Watchdog скрипты** — auto `ipconfig /release/renew` в VM, auto `docker compose restart` контейнера если healthcheck падает > N min.
+- **Telegram-уведомления** на инциденты (для пользователя в реал-тайм когда что-то фейлится).
+
+### Документация и runbook
+
+- Runbook на каждый процедурный сценарий (failover, restore, network swap).
+- Регулярные **failover drills** раз в квартал — буквально нажать "восстановиться" и засечь время.
+- Wiki эта — стартовая точка.
+
+## Что НЕ цели
+
+- Перестройка с нуля «потому что сейчас не идеально». Текущая архитектура работает, замена должна быть инкрементальной.
+- 99.99% uptime — нереалистично для one-person infrastructure, и не нужно для CMS-сайтов клиентов.
+
+## Следующие шаги (когда дойдут руки)
+
+1. Заменить WD40EFAX на CMR-диски, пересобрать пул [[dead-synology-diskstation]].
+2. Включить ежедневный Hyper Backup из нового пула на [[kreknin-synology]].
+3. Добавить cloud-backup target (Yandex Object Storage наиболее очевидный для RU-юрисдикции).
+4. Настроить monitoring/alerts.
+5. Документировать runbooks.
+
+Связано со всеми остальными страницами этого wiki.
+
+## Прогресс 2026-05-20
+
+✅ **Decouple инфра-сервисов от windows-recovery-host SPOF.** Поднят отдельный облачный VDS [[vds-kzntsv]] (Rusonyx 160 NVMe), туда мигрированы gitea / verdaccio / docker-registry + shared DB park (Postgres/MariaDB/Mongo/Redis). [[windows-recovery-host]] теперь хостит **только** production CMS. Это не полный multi-host resilience (VDS сам по себе SPOF), но critical infra decoupling сделан.
+
+Запланированы follow-up tasks (см. `.tasks/`):
+- `vds-backup-rsync-kreknin` — ежедневный 05:00 MSK rsync VDS → kreknin с email-нотификацией.
+- `vds-ntfy-push` — self-hosted push на Android для backup status и monitoring.
+- `vds-gc-cron` — cron GC для verdaccio + registry чтобы не повторился incident 99G на registry.
+
+Следующая фаза по originally outlined ladder — добавить **cloud off-site backup target** (Backblaze B2 / Yandex Object Storage) поверх kreknin'а, и replicated MSSQL для production CMS.