[2026-09-20] eagle: family/how-to/kraken-access.md family/how-to/truenas-rclone-backup.md family/plans/kraken-backup-to-truenas.md

family/how-to/kraken-access.md

@@ -135,12 +135,42 @@ EP=3  # endpoint ID на Кракене = 3, не 1!
 | cloudflared | ✅ Up | `cloudflare/cloudflared:latest`, `network_mode: host`, remote-managed по TUNNEL_TOKEN |
 | jellyfin / sonarr / radarr / prowlarr | ✅ Up | |
 | portainer / transmission / rclone / watchtower / flaresolverr | ✅ Up | |
-| hermes-kraken | ⚠️ `Restarting (1)` — crash-loop | **не связан** с гонкой docker↔mount, вёл себя так и до правок |
+| hermes-kraken | ✅ Up | crash-loop вылечен 2026-09-20 (см. ниже) |
 | homeassistant | ⏹ `Exited (128)` 2 месяца назад | не поднимался, отдельная задача |
 | timemachine + alpine-* (6 шт.) | ⏹ Exited (0) | одноразовые/диагностические, норма |
 
 > **Питфолл про RestartPolicy (проверено):** `hostconfig.json` на диске показывает `RestartPolicy.Name = null`, но в daemon state политика `unless-stopped` есть → контейнеры поднимаются сами. Не пугаться `null`, не нужен ручной `docker start`. Проверять живой daemon: `docker inspect --format '{{.HostConfig.RestartPolicy.Name}}' <name>`.
 
+## ✅ hermes-kraken — crash-loop вылечен 2026-09-20 (права каталога)
+
+> **Симптом:** `hermes-kraken` в вечном `Restarting (1)`. Логи циклично:
+> `mkdir: cannot create directory '/opt/data': Permission denied`.
+>
+> **НЕ связано** с гонкой docker↔mount (контейнер был запущен, но падал сам).
+
+| Что | Значение |
+|---|---|
+| Контейнер работает под | **UID 1000:1000** (`kraken`, задан в образе, не в compose) |
+| `/opt/data` примонтирован из | `…/docker/hermes/config` |
+| Владелец на хосте (было) | **10000:10000**, `drwx------` (700), mtime **Sep 15 15:37** |
+| Итог | 1000 ≠ 10000 + mode 700 → `Permission denied` на `mkdir /opt/data` |
+
+**Корень:** каталог `docker/hermes/config` после перерегистрации диска (15 сен) получил **чужой UID 10000** — след старого OMV-маппинга. `10000` больше нигде в `…/docker/` не встречается: все прочие каталоги либо `root:root`, либо `1000:1000`. Данные (`.env`, `auth.json`, `sessions/`, `cron/`, `response_store.db`) были целы — только владелец не тот.
+
+**Фикс:**
+```bash
+# top-level — мгновенно
+sudo chown 1000:1000 /srv/dev-disk-by-uuid-6194539b-.../docker/hermes/config
+# рекурсивно — долго (медленный USB-HDD), запускать в фоне, НЕ блокируясь на SSH:
+sudo systemd-run --unit=hermes-chown --collect --property=Type=oneshot \
+  chown -R 1000:1000 /srv/dev-disk-by-uuid-6194539b-.../docker/hermes/config
+```
+Проверка: `sudo find …/docker/hermes -uid 10000` → пусто; контейнер `Up`; API `http://localhost:8642/` отвечает (`404` на `/` — норма, эндпоинт `/v1/chat/completions`).
+
+**Питфоллы:**
+- `chown -R` по большому дереву на USB-HDD идёт **минуты** → **обычный ssh-вызов рвётся по таймауту и правка НЕ применяется**. Запускать через `systemd-run … --collect` в фоне, потом проверять `systemctl is-active hermes-chown` и `ls -ldn` каталога.
+- Логи после старта содержат «хвост» прежних `mkdir` ошибок из буфера — не пугаться, если дальше идёт `Hermes Gateway Starting...` и скиллы синхронизированы.
+
 ## Cloudflared туннель — публичные маршруты (состояние на 2026-09-04)
 
 Туннель `kraken` в Zero Trust, remote-managed по `TUNNEL_TOKEN`, `network_mode: host`, образ `cloudflare/cloudflared:latest`. Актуальный ingress конфиг (виден в логах cloudflared на Kraken, `INF Updated to new configuration`):

family/how-to/truenas-rclone-backup.md

@@ -37,10 +37,52 @@
 > 📌 **Следствие (2026-09-14): всё, положенное в `/mnt/RED_2TB/backup/*`, уезжает в Mail.ru автоматически** — правка `backup.sh` не нужна. Именно поэтому бэкап конфигов t610 кладётся в `/mnt/RED_2TB/backup/t610/` (датасет `nas:nas` 770, создан 2026-09-14) — см. [[family/plans/t610-backup-to-truenas]].
 > 📌 Крон запускается **внутри контейнера rclone от root**, поэтому права `nas:nas 770` чтению не мешают.
 
+## ⚠️ Бэкап Kraken — отдельный rclone-контейнер НА Kraken (НЕ на TrueNAS)
+
+> **Уточнено 2026-09-20.** Kraken бэкапится **самостоятельно**, не через TrueNAS.
+
+```
+Kraken  /srv/.../docker  ──rclone (вс 03:00)──►  mailru-crypt:kraken/docker   (Mail.ru, шифровано)
+TrueNAS /mnt/RED_2TB/{docker,backup}  ──rclone──►  mailru-crypt:              (Mail.ru, шифровано)
+```
+**Между Kraken и TrueNAS бэкапа НЕТ** — каждая машина льёт сама в Mail.ru. Kraken на TrueNAS не бэкапится (ни в `backup.sh`, ни папкой в `/mnt/RED_2TB/`).
+
+- Контейнер: `rclone` на Kraken (`/srv/.../docker/rclone/`, образ `rclone/rclone:latest`, `restart: always`).
+- Маппинги: `…/docker/rclone/config` → `/config/rclone`, `…/` (весь диск) → `/data`.
+- Расписание: `0 3 * * 0` (вс 03:00) через `crond -f` внутри контейнера, **только crontab** — пропущенное окно НЕ догоняется.
+- Скрипт `/config/rclone/backup.sh`: `run_sync /data/docker mailru-crypt:kraken/docker`.
+- Лог: `/config/rclone/backup.log` (растёт до 65 МБ+ — исключать из архива при бэкапе на NAS).
+- Remotes: `mailru`, `mailru-crypt` (crypt поверх `mailru:backup`).
+
+### ❌ Бэкап Kraken фактически НЕПОЛНЫЙ (обнаружено 2026-09-20)
+
+| Факт | Значение |
+|---|---|
+| Последний прогон | **13 сентября**, 3 ч 30 мин |
+| Передано | 3.37 GiB, 40021 файл (99%) |
+| Ошибок | **292** — сначала `507 Insufficient Storage`, затем `400 Bad Request` |
+| Итог | `Failed to sync with 292 errors` |
+
+**Причина:** **на Mail.ru кончилось место** → WebDAV отдаёт `507 Insufficient Storage`, затем `400 Bad Request` на любые запросы. Alex подтвердил («в курсе»).
+`rclone sync` при ошибках **не удаляет** файлы в облаке (`not deleting files as there were IO errors`) — состояние «столько, сколько влезло».
+
+**Плюс:** прогон **20 сентября не состоялся** — контейнер `rclone` поднялся только в 11:00 (после фикса гонки docker↔mount), а crontab пропущенное окно не догоняет.
+
+### 📋 План (согласовывается 2026-09-20): бэкап Kraken → TrueNAS рядом с t610
+
+**Цель:** как t610 — Kraken-архив кладётся в `/mnt/RED_2TB/backup/kraken/`, оттуда существующим скриптом уезжает в Mail.ru. `backup.sh` TrueNAS **не трогаем**.
+
+**Развилка (Kraken за NAT — нет белого IP):**
+- **Вариант A (рекомендован): PUSH с Kraken** — Kraken по крону сам льёт архив на `mallexxx.duckdns.org:22` (порт OPEN, ping 102 ms, проверено). NAT не мешает.
+- **Вариант B: PULL с TrueNAS** (как t610) — требует SSH-туннеля к NAT-хосту. Сложно.
+
+**Детали для реализации:** источник `/srv/.../6194539b.../docker` (2.2G; jellyfin metadata 1.5G можно исключить; `rclone/config/backup.log` 65MB — исключить); целевой датасет `/mnt/RED_2TB/backup/kraken` (`nas:nas 770`, как `backup/t610`); крон TrueNAS ~04:00 (после t610 в 03:30); отдельный pull/push-ключ с `from=` + `no-pty`; ротация 14. Ожидает решения Alex по варианту A/B и составу архива.
+
 ## Remotes
 
 - **mailru** — WebDAV, Mail.ru Cloud (`webdav.cloud.mail.ru`), user: `mallexxx@mail.ru`
 - **mailru-crypt** — rclone crypt поверх `mailru:backup`, шифрование имён файлов и директорий (`standard`)
+- Оба remotes есть и на TrueNAS, и на Kraken (одинаковые имена).
 
 ## Добавить что-то в бэкап
 

family/plans/kraken-backup-to-truenas.md

@@ -0,0 +1,98 @@
+# Kraken → TrueNAS — автобэкап стека
+
+> **Создано:** 2026-09-20
+> **Статус:** 📋 ПЛАН СОГЛАСОВАН (вариант A + исключение jellyfin-метаданных), к реализации
+> **Задача:** бэкап стека Kraken складывать на TrueNAS в `/mnt/RED_2TB/backup/kraken/`, откуда он автоматически уезжает в Mail.ru Cloud существующим rclone-скриптом TrueNAS (**скрипт не трогаем**).
+
+## Почему появилась задача
+
+2026-09-20 при разборе падения `vless reverse proxy` и `cloudflared ssh tunnel` выяснилось:
+- Бэкап Kraken **был** — контейнер `rclone` на Kraken, вс 03:00, `/data/docker` → `mailru-crypt:kraken/docker`.
+- Но **последний успешный прогон — до 13.09.2026**. 13-го прогон упал с **292 ошибками**: сначала `507 Insufficient Storage` (место на Mail.ru кончилось), затем `400 Bad Request`.
+- Прогон **20.09 не состоялся вообще** — контейнер `rclone` не был запущен (docker-гонка: dockerd стартовал раньше монтирования USB-диска, см. [[personal/tech/docker-data-root-mount-race]]). Crontab пропущенное окно не догоняет.
+- `rclone sync` при ошибках **не удаляет** → в облаке застряло неполное состояние.
+
+**Решение Alex (2026-09-20):** перенастроить так, чтобы бэкап Kraken шёл **на TrueNAS** в общую папку `backup/`, рядом с `t610`, и уезжал в Mail.ru **существующим скриптом**. Часть «TrueNAS → Mail.ru» **не трогать**.
+
+## Схема (принята 2026-09-20)
+
+```
+Kraken: /srv/dev-disk-by-uuid-6194539b-.../docker   (весь стек конфигов)
+   │  tar czf -   (собирается НА Kraken, локально)
+   │  rsync/scp  ──────────►  mallexxx.duckdns.org:22  (порт открыт, ping ~102ms)
+   ▼
+TrueNAS: /mnt/RED_2TB/backup/kraken/kraken-docker-<ts>.tar.gz
+   │  ротация N архивов
+   ▼
+rclone backup.sh (вс 03:00, контейнер rclone)   ← ⛔ НЕ ТРОГАЕМ
+   │  run_sync "backup" /data/backup "mailru-crypt:"
+   ▼
+Mail.ru Cloud (зашифровано)
+```
+
+**Ключевой принцип:** `/mnt/RED_2TB/backup/*` **уже целиком** уходит в `mailru-crypt:` строкой `run_sync "backup" /data/backup "mailru-crypt:"`. Значит всё, положенное в `backup/kraken/`, уезжает в облако **автоматически** — **правок в `backup.sh` не требуется**. Тот же приём, что у [[family/plans/t610-backup-to-truenas]].
+
+## Решения и обоснование
+
+1. **Вариант A — PUSH с Kraken** (выбрал Alex 2026-09-20).
+   **Почему не PULL (как у t610):** Kraken **за NAT**, белого IP нет → TrueNAS не может к нему подключиться. PULL потребовал бы SSH-туннель. PUSH работает через уже открытый порт `mallexxx.duckdns.org:22`.
+   **Минус PULL-схемы t610 здесь непреодолим:** у t610 адрес в локалке TrueNAS (`192.168.2.176`), у Kraken — другая сеть (`192.168.1.x`) + NAT.
+
+2. **Что бэкапим:** весь `/srv/dev-disk-by-uuid-6194539b-.../docker` (**2.2G**), **кроме**:
+   - `docker/jellyfin/` (**1.5G**) — метаданные/картинки, **перекачиваемы**. Alex: «метаданные не надо».
+   - `docker/rclone/config/backup.log` (**65 МБ**) — растущий лог самого бэкапа, бессмысленно таскать в архив.
+   **Итого к бэкапу ≈ 700 МБ минус логи.**
+   Состав, который уезжает: `hermes` (249M — **данные Hermes-агента: sessions, .env, auth.json, cron**), `radarr` 119M, `media-pipeline` 90M, `sonarr` 82M, `rclone/config` 63M (минус лог), `prowlarr` 56M, `transmission` 12M, `homeassistant` 6.6M, `portainer`, `scripts`, `hermes-build`, `cloudflared`, `watchtower`, `compose.sh`.
+
+3. **Целевой датасет:** `/mnt/RED_2TB/backup/kraken` — внутри `backup`, уезжает в Mail.ru автоматически.
+   ⚠️ Создавать как t610: parent `/mnt/RED_2TB/backup`, ACL Mode = `Passthrough` (не DISCARD!), ACL Type = NFSv4, права `nas:nas 770`.
+
+4. **Расписание:** крон **на Kraken**, ежедневно, время **после** t610 (03:30) — предлагается **04:00**. Ротация **14** архивов.
+   ⚠️ **Питфолл:** crontab **не догоняет** пропущенное окно. Если Kraken лежал — бэкап за тот день потерян. Вариант улучшения: `@reboot` + проверка «архив за сегодня есть?» (обсуждаемо).
+
+5. **Транспорт:** `rsync` c SSH-ключом. Отдельный pull/push-ключ (ограничить `from=` + `no-pty` на стороне TrueNAS). Ключ хранить в `/mnt/RED_2TB/backup/kraken/.ssh/` (владелец `nas`, как t610 — питфолл №9: `~nas/.ssh` недоступен).
+   ⚠️ Kraken пишет как юзер в `authorized_keys` TrueNAS. Нужен юзер с правом записи в `backup/kraken` (или `nas`).
+
+6. **Скрипт:** на Kraken (`/home/kraken/backup-to-truenas.sh`), tar + rsync. Лог рядом.
+
+## ⚠️ Проблемы, которые надо решить при реализации
+
+| # | Проблема | Решение |
+|---|---|---|
+| 1 | `nas` (uid 1000 на TrueNAS) vs юзер на Kraken — **разные uid** | Ключ с `from=` + запись в `backup/kraken` от нужного владельца; либо chown `nas:nas` |
+| 2 | У Kraken **нет ключа для TrueNAS** (в `~/.ssh` только `id_ed25519` от другого) | Сгенерировать отдельный ключ `kraken-backup-push`, pub → `authorized_keys` TrueNAS |
+| 3 | Mail.ru переполнен | **Не блокирует** доставку на TrueNAS. Разбираться отдельно (вне этой задачи) |
+| 4 | Ротация на стороне Kraken vs TrueNAS | Делать ротацию **на TrueNAS** (там архивы), rm старых |
+| 5 | `backup.log` 65 МБ растёт | Исключить из tar (`--exclude`) + рассмотреть ротацию самого лога |
+
+## Шаги реализации (черновик)
+
+1. Ключ `kraken-backup-push` (ed25519) на Kraken → pub на TrueNAS `authorized_keys` с `from="<IP Kraken>"`, `no-pty`, `no-port-forwarding`.
+2. Создать датасет `/mnt/RED_2TB/backup/kraken` (Passthrough, NFSv4, `nas:nas 770`).
+3. Скрипт на Kraken: собрать tar (exclude jellyfin, backup.log) → `rsync -e ssh` на TrueNAS `backup/kraken/`.
+4. Ротация 14 архивов (на TrueNAS).
+5. Крон на Kraken: `0 4 * * *`.
+6. Живой прогон + проверка размера архива (не <4096 байт) + проверка, что уезжает в Mail.ru.
+7. **Отключить старый бэкап Kraken → Mail.ru напрямую** (crontab в контейнере `rclone`: закомментировать `run_sync /data/docker mailru-crypt:kraken/docker`), иначе дублирование и переполнение Mail.ru.
+
+> ⚠️ **П.7 обязателен:** сейчас Kraken льёт `docker` прямо в `mailru-crypt:kraken/docker`. После перевода на TrueNAS это надо выключить — иначе двойная нагрузка и тот же 507.
+
+## Проверка результата
+
+```bash
+# 1) архив появился на TrueNAS
+ssh truenas_admin@mallexxx.duckdns.org 'ls -la /mnt/RED_2TB/backup/kraken/'
+# 2) лог прогона
+ssh truenas_admin@mallexxx.duckdns.org 'tail -20 /mnt/RED_2TB/backup/kraken/backup.log'
+# 3) уезжает в облако (после вс 03:00)
+ssh truenas_admin@mallexxx.duckdns.org 'docker exec rclone tail -30 /config/rclone/backup.log'
+```
+
+## Связанные заметки
+
+- [[family/plans/t610-backup-to-truenas]] — образец схемы (PULL), питфоллы датасетов/SMB/ключей
+- [[family/how-to/truenas-rclone-backup]] — rclone-бэкап TrueNAS → Mail.ru (куда попадает `backup/kraken`)
+- [[family/how-to/kraken-access]] — доступ к Kraken, контейнеры
+- [[personal/tech/docker-data-root-mount-race]] — гонка docker↔монтирование (причина, почему прогон 20.09 не состоялся)
+- [[personal/tech/xray-reverse-tunnel-kraken-truenas]] — разбор того же инцидента
+- [[family/how-to/openmediavault-rpi5]] — Kraken OMV