---
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.