OpeItcLoc03/admin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2d307f2dd0e69086115a7156e914f96bac04383a
admin/future-resilient-architecture-goals.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

6.0 KiB
Raw Blame History

title, type, tags, sources, updated
title type tags sources updated
Future Resilient Architecture — цели на потом concept
planning
architecture
resilience
roadmap
todo
../sources/nas-recovery-session-2026-05-18.md
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.

Reference in New Issue View Git Blame Copy Permalink