vitya
19422352ba
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>
101 lines
6.0 KiB
Markdown
101 lines
6.0 KiB
Markdown
---
|
||
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.
|