Files

vitya 13c23b9bc5 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

5.1 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

Kreknin Synology

Удалённая (географически в другом месте) Synology, которая держит Hyper Backup-репо мёртвой синки и сама работает как живой сервер.

Доступ

Public IP: 195.19.90.188
DDNS: kreknin.site (резолвится на 195.19.90.188)
DSM web: http://kreknin.site:5000 (HTTP; HTTPS 5001 наружу НЕ проброшен)
SSH: vitya@195.19.90.188:22 (был пароль, сейчас SSH-ключ установлен — id_ed25519_kreknin)
Канал: "не очень надёжный" по словам пользователя — поэтому неудобно держать там production-сайты.

Ограничения SFTP

SFTP-подсистема DSM запускается отдельно от SSH — Control Panel → File Services → FTP → SFTP. Изначально не была включена.
После включения SFTP — DSM jail-chroot'ит подсистему в home юзера. То есть vitya через SFTP видит только /volume1/homes/vitya/, не /volume1/backup/....
Обход: scp -O (legacy SCP протокол) использует чистый SSH-channel мимо SFTP-subsystem → даёт доступ ко всему, что shell-пользователь видит.

Структура

Volume: один том /volume1, 7.0 TB, ~1.2 TB used до восстановления.
/volume1/NetBackup/diskstation_1.hbk — Hyper Backup репо с мёртвой синки. 430 GB compressed (deduplicated), последняя успешная backup-версия 2026-05-09 05:06.
Hyper Backup Vault установлен как пакет на этой синке (см. hyper-backup-structure-and-recovery).
Owner данных в репо — vitya:users (POSIX) с ACL под +. ACL даёт vitya read, но individual файлы .bak/.acme.json могут иметь -rw------- — для них нужен chmod -R a+rX из root SSH.

VMM статус

Установлен (виден @SavedVM в /volume1/).
В сессии 2026-05-18 рассматривался вариант поднять snolla.ova прямо здесь через VMM как альтернатива переезду на Windows — отвергнут потому что канал не надёжный.

Роль в recovery

Источник всех данных: OVA, sql дампы, docker volumes (mssql, minio, elasticsearch, imgproxy/nginx) — всё тащилось отсюда.
Не было записи на этот NAS во время recovery — только чтение / Hyper Backup restore во временную папку /volume1/NetBackup/restore-tmp/, потом backup-shares /volume1/backup/, /volume1/docker/, /volume1/work/.

Гипотеза по будущему backup pipeline

Эта синка остаётся как backup target, на ней нет SMR-дисков (тип неизвестен на момент сессии, но кратко проверить через ls /dev/sd* + smartctl до тяжёлой нагрузки).
Будущая future-resilient-architecture-goals: добавить второй backup target (или облачный — Backblaze B2 / S3 Glacier), чтобы не зависеть от одной коробки.

Роль источника для миграции на VDS (2026-05-20)

В сессии vds-kzntsv-bootstrap-2026-05-20 kreknin сыграл вторую роль — источник данных для миграции инфра-сервисов на vds-kzntsv. Из restored backup'а (Hyper Backup .hbk мёртвой синки):

Gitea — tar c -C /volume1/docker/gitea data postgres docker-compose.yml | ssh vds tar x (sudo Pryakhin9 для read postgres datadir uid 999). 2.7G total за 8 мин.
Verdaccio — rsync /volume1/docker/personal/verdaccio/{storage,config,plugins} → vds:/opt/stacks/verdaccio/. 9G за 18 мин.
Registry — GC на kreknin (registry:2.8.3 garbage-collect -m) сжал 99G → 35G; затем user принял решение abandon миграцию и fresh install на VDS. Старый registry data остаётся на kreknin как backup-reference.

Roadmap как backup target для VDS

Планируется ежедневный pull rsync VDS → kreknin в /volume1/NetBackup/vds-kzntsv/ (см. follow-up task .tasks/vds-backup-rsync-kreknin.md). Дополнительный pipe — backup pipe для production-CMS windows-recovery-host → тут же на kreknin — пока не реализован.

5.1 KiB Raw Blame History Unescape Escape