Files

vitya dd7c56742e docs(.wiki,.tasks): vds-kzntsv-bootstrap done — 3 phases shipped

VDS Rusonyx 160 NVMe (89.253.255.94 / vds.kzntsv.site) активирован
2026-05-20. 3 фазы за ~6 часов:

- Phase 1: harden + docker 29.5.1 + traefik v2.11 + portainer 2.21.5
- Phase 2: shared DB park (postgres 16 / mariadb 11.4 / mongo 7 /
  redis 7) via traefik raw TCP forward + self-signed TLS
- Phase 3: миграция gitea (132 repos), verdaccio (2063 pkgs), registry
  fresh install (user accepted loss old images) + Joxit GUI

Ingest 1 source + 1 entity (vds-kzntsv) + 6 concepts (traefik-tcp-
passthrough-vs-starttls / portainer-2.21-admin-password-regression /
db-tls-self-signed-via-traefik-raw-tcp / rusonyx-vps-onboarding-quirks
/ registry-gc-mount-and-modify-flag / compose-bcrypt-escape-trap).

3 follow-up ⚪ tasks: vds-gc-cron, vds-backup-rsync-kreknin, vds-ntfy-push.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-20 22:39:31 +03:00

7.1 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

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)

Цели верхнего уровня

RTO (Recovery Time Objective) — сколько максимум downtime клиенты должны видеть при отказе.
- Текущий по факту: ~15 часов (что и было).
- Целевой: < 1 час для одиночного отказа, < 4 часов для каскадного.
RPO (Recovery Point Objective) — сколько максимум данных потерять при отказе.
- Текущий: до 24 часов (если успеет бэкап после изменения) — больше если бэкап не успел.
- Целевой: < 1 час, в идеале continuous (replication).
Стоимость — bounded by разумным % от выручки клиентов.
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-сайтов клиентов.

Следующие шаги (когда дойдут руки)

Заменить WD40EFAX на CMR-диски, пересобрать пул dead-synology-diskstation.
Включить ежедневный Hyper Backup из нового пула на kreknin-synology.
Добавить cloud-backup target (Yandex Object Storage наиболее очевидный для RU-юрисдикции).
Настроить monitoring/alerts.
Документировать 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.

7.1 KiB Raw Blame History Unescape Escape