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

2026-09-20 11:34:45 +06:00
1 parent 7f4faf0a19
commit d295d69a4c
@@ -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`):
@@ -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 (одинаковые имена).

 ## Добавить что-то в бэкап