142 lines
18 KiB
Markdown
142 lines
18 KiB
Markdown
---
|
||
title: Kreknin Synology (backup target + DDNS)
|
||
type: entity
|
||
tags: [hardware, nas, synology, backup, hyperbackup]
|
||
sources: [../sources/nas-recovery-session-2026-05-18.md]
|
||
updated: 2026-08-10
|
||
---
|
||
|
||
# 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`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) kreknin сыграл вторую роль — **источник данных** для миграции инфра-сервисов на [`vds-kzntsv`](vds-kzntsv.md). Из restored backup'а ([Hyper Backup](../concepts/hyper-backup-structure-and-recovery.md) `.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`](windows-recovery-host.md) → тут же на kreknin — пока не реализован.
|
||
|
||
## Диски (инвентарь, после инцидента 2026-07-31)
|
||
|
||
**Xpenology** (DSM 7.1.1, apollolake) на **обычном ПК-корпусе** — НЕ настоящий Synology, без hot-swap лотков, диски на обычных SATA-кабелях. **Урок: компрессорная продувка срывает SATA-кабели.**
|
||
|
||
| Диск | Порт | Модель | Роль | Статус 2026-07-31 |
|
||
|---|---|---|---|---|
|
||
| sda | ata1 | WD40EFPX-68C6CN0 4TB (6682ч) | md3 raid5 slot 3 | жив; **213 UDMA CRC, линк упал до 1.5 Gbps** = кабель |
|
||
| sdb | — | WD-WX32D12L8HTE (4TB) | md3 raid5 slot 0 | **не определяется** — отвал кабеля (питание/дата) после продувки, вероятно оживает перетыком |
|
||
| sdc | ata3 | WD40EFAX-68JH4N1 4TB **SMR** (30373ч) | md3 raid5 slot 1 | жив; WRITE FPDMA bursts 09:58/12:09 — только при ручном трясе кабелей |
|
||
| sdd | ata4 | Kingston SA400S37120G SSD (30460ч) | **md2 raid1** = VMM volume `/volume2` | восстановлен 2026-07-31 |
|
||
|
||
md3 = `/volume1` (btrfs, бэкапы), degraded `[_UU]` (sdb выпал), держится на sda+sdc.
|
||
|
||
## Инцидент 2026-07-31 (продувка компрессором)
|
||
|
||
Алексей продул NAS пром-компрессором → срыв SATA-кабелей:
|
||
- **sdb исчез** (не определяется), md3 degraded
|
||
- **sdd** DSM выкинул из md2 при загрузочной тряске (07:47) → /volume2 ушёл в **ro** (transient EIO)
|
||
- **sda**: 213 CRC, линк 6→1.5 Gbps; **sdc**: bursts при трясе, без тряса стабилен
|
||
|
||
## Ремонт (сделано 2026-07-31)
|
||
|
||
- **sdd/md2**: DSM Storage Manager → Repair пула → sdd вернулся (но `faulty active sync`), затем в DSM на `/volume2` кнопка **«Преобразовать в чтение/запись»** → rw, scrub 53GiB 0 ошибок. **Урок: «Convert to read/write» в DSM снимает ro-состояние после transient EIO без mdadm-ручнины.**
|
||
- **Ежедневные бэкапы на kreknin ЗАГЛУШЕНЫ** (не нагружать больной массив):
|
||
- vds-kzntsv: `/etc/cron.d/vds-backup` (05:00) — закомментирован, бэкап `.bak.20260731`
|
||
- books-vds: `/etc/cron.d/books-vds-backup` (06:00) — закомментирован, бэкап `.bak.20260731`
|
||
- ⚠️ **ВЕРНУТЬ после починки** (раскомментировать строку)
|
||
|
||
## Rescue 2026-07-31 → 08-02 (полный)
|
||
|
||
USB **2TB WD20EARX** (sdq) отформатирован в один btrfs, смонтирован `/mnt/rescue`. GNU tar `--numeric-owner` (хардлинки preserved; `--numeric-ids` — НЕ GNU-флаг, это bsdtar).
|
||
|
||
- `/mnt/rescue/netbackup/`: `diskstation_1.hbk.tar` **430G**, `windows-host.tar` 160G, `vds-kzntsv.tar` 84G, `ruvds-iis.tar` 62G, `books-vds.tar` 24G, `openwrt.tar` 20K
|
||
- `/mnt/rescue/userdata/`: `docker.tar` 130G (rc=1 — файлы менялись при чтении, архив валиден), `homes.tar` 118G, `work.tar` 32G, `downloads.tar` 25G, `documents.tar` 5.9G
|
||
- Итого 1.1TB / 726G свободно. Массив за 2 суток последовательного чтения — **ноль новых ошибок**.
|
||
|
||
## Ремонт 2026-08-10 (кабели перетыкнуты vitya, rebuild запущен)
|
||
|
||
Съезд к Алексею: power-off, переподключены SATA (sda/sdc/sdb), свежие кабели. Проверка через SSH (ключ `id_ed25519_kreknin`):
|
||
|
||
- **sdb** (WD-WX32D12L8HTE) — снова определяется, разделы на месте, SMART **PASSED** (0 realloc/pending)
|
||
- **sda** (WD40EFPX) — линк вернулся на **6.0 Gbps** (было 1.5), SMART PASSED, **CRC=10** (не растёт)
|
||
- **sdc** (WD40EFAX SMR) — SMART PASSED, CRC=213 (историческое, кабельное)
|
||
- Все 3 диска на 6.0 Gb/s. Заметка: в таблице выше у sda/sdc POH перепутаны местами — реально WD40EFPX=30492ч, WD40EFAX=6800ч.
|
||
|
||
**Repair md3:** `mdadm --add /dev/md3 /dev/sdb3` (sdb3 валидный stale-член, тот же UUID `717d6154…`, роль slot 0, Events 82069 vs массив 132876). Rebuild запущен 2026-08-10 07:57, `State: active, degraded, recovering`, sdb3 = `spare rebuilding`. **Скорость ~10-25 MB/s, оценка 43-106 ч** — старые диски (30k ч) + live-нагрузка (ownCloud cron, VMM etcd, docker). Не форсировать — массив живой.
|
||
|
||
**btrfs /volume1:** `corruption_errs 1` (счётчик с инцидента) — после ребилда прогнать `btrfs scrub`.
|
||
|
||
**VMM (win10):** md2/volume2 здоровы (clean, rw OK). ВМ `win10` (4 vcpu, autorun=1, vdisk 91GiB на /volume2/@iSCSI/LUN/VDISK_BLUN/8c809cc5/…32c7a0be…_00000) — **RESOLVED 2026-08-10**: застряла в «Приостановлено» (statevalue 10, от 5 авг) с неработающим resume. Корень: USB-проброс двух **RuToken ECP (0a89:0030)** на жёсткие адреса bus:1 dev6/dev7; после перетыков свистки вставали на другие dev → libvirt «Did not find USB device». Лечение: кнопка **«Игнорировать»** в VMM сбросила зависшее состояние → при старте свистки пере-нумеровались на 6,7 (совпало с конфигом) → ВМ запустилась, оба RuToken проброшены. Если свисток снова потеряется — перепривязать в GUI (Edit → USB). win10-old (репо 4cfcdd90 на /volume1) — НЕ трогать. libvirtd/etcd живы.
|
||
|
||
**Системные разделы (md0/md1) починены 2026-08-10:** DSM ругался «Отказ системного раздела» на sda/sdb/sdc — после инцидента при загрузке в 16-слотовое boot-зеркало собрался только sdd, системные разделы HDD остались вне массива (superblock'и валидны, UUID совпадали). `mdadm --add /dev/md0 {sda1,sdb1,sdc1}` + `mdadm --add /dev/md1 {sda2,sdb2,sdc2}` → ресинхронизация, диски **зелёные** в DSM. На md3 не влияло (копейки I/O: 8MB+2GB).
|
||
|
||
**Бэкапы ВОЗВРАЩЕНЫ 2026-08-10 (18:00)** по прямому указанию vitya (ДО завершения ребилда — ребилд в фоне на idle-IO). Cron-строки раскомментированы: vds-kzntsv `0 5 * * *`, books-vds `0 6 * * *` (снят префикс `#DISABLED-kreknin-sick `). Оба прогнаны вручную и **ПОДТВЕРЖДЕНЫ на kreknin**: vds-kzntsv `2026-08-10` 66G (7 снапшотов), books-vds `2026-08-10` 15G (7 снапшотов), latest→08-10, `/volume1` 5.4T free (24%).
|
||
**Находка:** бэкапы books-vds НЕ доезжали до kreknin с **08-05** — run.sh гонялся 08-01..08-09 + 08-10 06:05 (локальные ES-снапшоты создавались), но rsync падал (`Connection timed out` / `No route to host`). Другого триггера кроме cron.d-строки не найдено (нет crontab/systemd-таймера) — вероятно ручные запуски. vds-kzntsv отключение держалось (не ходил с 07-31). Застрявший ES-снапшот `daily-2026-08-10` от упавшего прогона удалён (коллизия имён → 400 убил бы следующий прогон). Осталось после ребилда: `btrfs scrub /volume1`.
|
||
|
||
**Отключение питания 2026-08-10 (~11:40, деревня, временно):** NAS недоступен с 2 сетей (рабочая станция + VDS); роутер/WAN жив (traceroute доходит до 195.19.90.188 ~5мс — на UPS/другой линии). Причина — временное отключение электричества у Алексея, не поломка. После возврата питания (16:20) md3 собрался деградированным `[_UU]` (sdb3 сам в массив не вернулся), **md0/md1 — все 4 диска `[UUUU]`** (утренний ремонт пережил ребут), md2 здоров. Прогресс ребилда утра **сброшен** — `mdadm --add /dev/md3 /dev/sdb3` повторён (валидный член, UUID 717d6154…), recovery с 0.0%, ETA ~4+ дня (разгон с ~3МБ/с до 10-25). **Урок: прогресс mdadm-rebuild НЕ переживает жёсткое отключение** (контрольной точки нет) — после power-loss надо проверять /proc/mdstat и пере-dadd sdb3.
|
||
|
||
## Gitea + Traefik (2026-08-12)
|
||
|
||
Поставлен Gitea для Алексея (обещание vitya). Свежая чистая установка.
|
||
|
||
- **Gitea 1.27.1 + postgres:16-alpine** — контейнеры `gitea` + `gitea-db` в `/volume1/docker/gitea/` (compose + `.env` с паролем БД). Данные БД на `/volume1` (НЕ на SSD — требование vitya; volume1 с SSD-кэшем, после завершения raid5-rebuild скорость нормальная).
|
||
- **Админ:** `kreknin` / пароль в `pass kreknin/gitea` (admin=true).
|
||
- **Домен:** `https://git.kreknin.site/` — LE-серт (traefik httpChallenge, выписан 2026-08-12), redirect http→https.
|
||
- **Traefik** (v2.6.6, порты 8000/4443/8080): лежал с 07-31 (restart policy был `no`, упал на инциденте) — починен: `restart: unless-stopped`. **Урок: traefik без restart policy после ребута не поднимается.**
|
||
- **Проброс на Keenetic:** 80→192.168.1.43:8000, 443→192.168.1.43:4443 (правила в панели, сделал vitya/Алексей в GUI — KeeneticOS Viva API закрыт для curl-автоматизации).
|
||
- **NAT loopback у Алексея СЛОМАН** — **РЕШЕНО (2026-08-12)**: KeeneticOS 5.1.3 hairpin не чинит (проверено). Двойное решение:
|
||
1. **DNS-override на Keenetic** (RCI): `git.kreknin.site`/`kreknin.site` → `192.168.1.43` (ip host через POST /rci/ parse)
|
||
2. **Reverse proxy на DSM nginx**: 443 занят встроенным nginx DSM → добавлен server block `git.kreknin.site:443 → proxy_pass https://127.0.0.1:4443` (traefik), файл `/usr/local/etc/nginx/sites-available/0a73bdfc-…w3conf` (server.ReverseProxy.conf) + `nginx -s reload`. ⚠️ Важно: traefik на 4443 — TLS-entrypoint, поэтому `proxy_pass https://` + `proxy_ssl_verify off` + `proxy_ssl_name git.kreknin.site` (HTTP на 4443 даёт 404). **LE-серт в nginx**: извлечён из traefik `/volume1/docker/traefik/letsencrypt/acme.json` (base64 из Certificate/Key) → `/usr/local/etc/nginx/ssl_git_kreknin.{pem,key}` (LE, до 2026-11-10). DSM-пароль НЕ нужен (root SSH). **Автосинк**: `/volume1/scripts/acme-nginx-sync.sh` + cron `/etc/cron.d/acme-nginx-sync` (каждые 15 мин) — при ротации traefik-серта сам копирует в nginx и делает reload. Лог: `/var/tmp/acme-nginx-sync.log`.
|
||
- **Keenetic admin-пароль:** `pass kreknin/keenetic` (t3r1a4k314; 3steaks1eGG — НЕ для роутера).
|
||
- Установка через web-форму падала (xorm nil-pointer panic на sqlite) → обход: `INSTALL_LOCK=true` в [security] + CLI `admin user create`. Gitea CLI: `docker exec -u 1026:100 gitea gitea --config /data/gitea/conf/app.ini admin user ...` (новый синтаксис `admin user create`, не `create-user`).
|
||
|
||
## План ремонта (статус)
|
||
|
||
1. ~~Power-off~~ ✅ сделано vitya 2026-08-10
|
||
2. ~~Переподключить SATA~~ ✅ сделано (sda/sdc/sdb), все на 6 Gbps
|
||
3. **Repair md3 — В ПРОЦЕССЕ** (rebuild ~4 дня, DSM «оптимизация»)
|
||
4. ✅ sda вернулся на 6 Gbps, CRC=10 (не растёт)
|
||
5. ✅ **Бэкапы возвращены ДОСРОЧНО** 2026-08-10 (указание vitya — ребилд фоновый); `btrfs scrub /volume1` — после завершения ребилда
|
||
6. ⏳ VMM win10 — проверить в GUI (storage здоров)
|