admin/.wiki/entities/kreknin-synology.md

title, type, tags, sources, updated

title	type	tags	sources	updated
Kreknin Synology (backup target + DDNS)	entity	hardware nas synology backup hyperbackup	../sources/nas-recovery-session-2026-05-18.md	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 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 — пока не реализован.

Диски (инвентарь, после инцидента 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 у Алексея СЛОМАН (из его LAN внешние адреса не открывались): РЕШЕНО 2026-08-12 через DNS-override — статичные DNS-записи на Keenetic: git.kreknin.site → 192.168.1.43, kreknin.site → 192.168.1.43 (добавлены через RCI API, см. концепт keenetic-rci-api). Проверено с LAN: git.kreknin.site → 200, kreknin.site:5000 → 200. KeeneticOS 5.1.3 hairpin НЕ чинит (проверено после обновления) — DNS-override это единственное рабочее решение.
• 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 здоров)