From 6eecf719145a10e95dfcc0963026ce44d9ec3046 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 18 Aug 2026 11:19:58 +0600 Subject: [PATCH] [2026-08-18] eagle: family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md --- family/how-to/truenas-infrastructure.md | 8 ++--- .../truenas-sata-ports-and-zfs-pools.md | 36 ++++++++++++++++--- personal/tech/truenas-zfs-panic-recovery.md | 17 ++++++--- 3 files changed, 48 insertions(+), 13 deletions(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 4ddf7ae1..9d4b0eca 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,10 +1,10 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-08-17 (конец сессии) +> Обновлено: 2026-08-18 (datasets смонтированы, выгрузка rsync идёт) -> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB — kernel panic, данные НЕ выгружены, нужен root-доступ -> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ РЕШЕНО.** -> **Статус на конец 2026-08-17:** пан-loop преодолён (загрузка с физически отключёнными дисками пула → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **НО datasets не смонтированы и данные НЕ выгружены.** Блокер — **нужен root** (truenas_admin не root; sudo просит пароль). Целевой диск для выгрузки: **IronWolf 12TB** подключён (`sdc`). Полный рецепт и картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы») и `personal/tech/truenas-zfs-panic-recovery.md`. ВАЖНО: тюнабели GRUB (`zfs.zfs_recover` и др.) и `rd.break` НЕ помогли — рабочий способ только «диски отключены при загрузке + readonly-импорт». Инфраструктура на `/mnt/RED_2TB` не работает. +> ## ⚠️⚠️ АКТИВНО (2026-08-18): пул RED_2TB — kernel panic, datasets смонтированы, выгрузка данных rsync на IronWolf +> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ ВОССТАНОВЛЕНО** — данные в процессе спасения. +> **Статус на 2026-08-18:** пан-loop преодолён (загрузка с физически отключёнными дисками → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **ПРОГРЕСС: дочерние datasets смонтированы под root** (`zfs mount -a` после `mount -o remount,rw /`) — затем rsync на целевой пул **DEST** (IronWolf 12TB, `/mnt/IRONWOLF`, rw, 10.6T свободно). ⚠️ Первая попытка rsync дала только 355G из-за НЕ смонтированных дочерних datasets — после монтирования перезапущен. **`zfs send|recv` НЕ работает** на этом пуле (signal received / Bad file descriptor). Полный рецепт — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы», блок 2026-08-18) и `personal/tech/truenas-zfs-panic-recovery.md`. Инфраструктура на `/mnt/RED_2TB` пока не работает (только спасение данных). ## Доступ diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index f611abd3..1f33d908 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,15 +1,15 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 (через время после readonly-импорта). СТАТУС: данные RED_2TB ещё НЕ выгружены. IronWolf 12TB подключён как целевой диск для спасения. Блокер: для `zpool import`/`mount` нужен root, а `truenas_admin` не root. HGST сломан (см. ниже). +> Обновлено: 2026-08-18 (datasets смонтированы под root, rsync перезапущен). СТАТУС: данные RED_2TB на этапе выгрузки на IronWolf — смонтированные дочерние datasets готовы к rsync. IronWolf 12TB = целевой пул `DEST` (rw, 10.6T свободно). HGST сломан (см. ниже). -## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы, данные НЕ выгружены +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, datasets смонтированы, данные выгружаются rsync -Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **Осталось:** смонтировать datasets вручную и выгрузить данные на IronWolf. Это приоритет №1 — данные есть, но пул восстановится только пересозданием, so спасаем. +Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **ПРОГРЕСС 2026-08-18:** дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) **успешно смонтированы под root** (`zfs mount -a` + при необходимости `mount -o remount,rw /`). Данные видны. Выгрузка на IronWolf идёт **rsync** (см. блок ниже). **ТЕКУЩИЙ БЛОКЕР (конец сессии):** - `zpool import`/`mount` требуют **root** (`some devices require root privileges`). `truenas_admin` НЕ root (sudo просит пароль). Все операции с пулом — только под root. - **Нужно добыть root:** SSH → включить root login (`PermitRootLogin`), или выполнять команды через WebUI-админ/консоль. -- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём ещё не создан пул-приёмник. +- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём **создан пул-приёмник `DEST`** (rw, ONLINE, ~10.6T свободно), монтируется на `/mnt/IRONWOLF`. Первая попытка rsync скопировала только 355G (см. блок 2026-08-18 ниже). - **WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН** — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны. ## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения @@ -191,6 +191,34 @@ zfs list -r RED_2TB # какие datasets есть (zfs list работает > ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок. +### 🆕 ПРОГРЕСС (2026-08-18): datasets смонтированы под root, выгрузка идёт rsync — НЕ send|recv + +**Смонтирование дочерних datasets — РАБОТАЕТ под root.** Это снимает блокер «datasets не смонтированы» из прошлой сессии: +```bash +mount -o remount,rw / # если корневая ФС readonly мешает создавать mountpoint-ы +zfs mount -a # смонтировать все datasets +# проверить: +df -h /RED_2TB # должно показать ~4.6T, а НЕ 1.1T/362G родительского +ls /RED_2TB/storage | head # должно быть не пусто (Cartoons, Downloads, Movies...) +``` +После `zfs mount -a` в `mount` видны все дочерние datasets на `/RED_2TB/*` (все `ro` — readonly, для чтения rsync это норм). + +**⚠️ СМОНТИРОВАТЬ datasets под `truenas_admin` НЕЛЬЗЯ** — `zfs mount -a` даёт `Insufficient privileges`. Монтирование и выгрузка — только **под root**. + +**🐛 Причина «только 355G» на первой выгрузке rsync (разгадана):** первая попытка `rsync /RED_2TB/ /mnt/IRONWOLF/` запускалась, когда **дочерние datasets НЕ были смонтированы**, поэтому `/RED_2TB/storage` (3.24T), `/RED_2TB/backup` (287G) и т.д. были **пустыми mountpoint-дирами**. rsync скопировал только ~355G, лежащих прямо в родительском dataset `RED_2TB` (REFER 362G: `.DS_Store`, `dedupe_rm.sh`, `files.txt.xz`, `docker.bak`, `system`, `immich-photos-upload`). **rsync не сломался — ему просто нечего было копировать из не смонтированных дочерних datasets.** После монтирования данных стало ~4.6T — rsync перезапущен. + +**❌ `zfs send | zfs recv` НЕ работает на повреждённом пуле — использовать rsync:** при `zfs send RED_2TB/storage | zfs recv DEST/storage` (под root) recv падает с `signal received` / `Bad file descriptor` / `IOT instruction (core dumped)`, exit 1. ZFS не может прочитать данные/метаданные из пула с повреждённой space map на лету при stream-чтении. **rsync — правильный и единственный надёжный способ** (переживает ошибки чтения отдельных файлов, exit 23, копирует остальное). + +**⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n RED_2TB/docker` возвращал **exit 0 без ошибок** — это ОБМАНЧИВО. Реальный `zfs send` (без `-n`) даёт `warning: cannot send 'RED_2TB/docker': permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send. + +**Команды выгрузки (под root):** +```bash +rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 & +# прогресс: +while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2.log; pgrep -a rsync >/dev/null && echo RUNNING || echo DONE; sleep 15; done +``` +**Итог выгрузки:** после монтирования datasets и перезапуска rsync должны лечь все ~4.6T (storage, backup, Edu, Photos, TimeMachine/guest, old-bu, docker...). После завершения — сверка `du -sh /mnt/IRONWOLF/` vs `zfs list RED_2TB` и обновить таблицу членов пула. + **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md index fc042d5f..9ec6f3c5 100644 --- a/personal/tech/truenas-zfs-panic-recovery.md +++ b/personal/tech/truenas-zfs-panic-recovery.md @@ -35,21 +35,27 @@ panic - not syncing: zfs: adding existent segment to range tree ``` → `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо. -### 3. Монтирование datasets вручную (root ФС readonly): +### 3. Монтирование datasets (2026-08-18: подтверждено под root) -Ошибка `cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system` — из-за READONLY корневой ФС. Монтируй вручную в записываемую точку: +Если корневая ФС readonly мешает создавать mountpoint-ы (`cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system`) — сначала сделать root ФС rw, затем смонтировать всё: ```bash -zfs list -r RED_2TB # список datasets (работает без mount) -zfs set mountpoint=/mnt/rec RED_2TB # или mount -o +mount -o remount,rw / +zfs mount -a ``` +После этого дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) видны на `/RED_2TB/*` (все `ro` — readonly; для чтения rsync это ок). Проверка: `df -h /RED_2TB` покажет ~4.6T (НЕ 1.1T родительского), `ls /RED_2TB/storage` не пуст. +> ⚠️ Монтирование — **только под root**. Под `truenas_admin` `zfs mount -a` даёт `Insufficient privileges`. ### 4. Выгрузка: ```bash -rsync -av --ignore-existing --ignore-errors // <резервный-диск>/ +rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 & ``` Лучше в tmux. Затем `zpool destroy` + пересоздать пул. +**⚠️ ВАЖНО (2026-08-18): использовать именно `rsync`, НЕ `zfs send | zfs recv`.** `zfs send` на пуле с повреждённой space map падает (`signal received` / `Bad file descriptor` / `IOT (core dumped)`, exit 1) — ZFS не может прочитать данные на лету при stream-чтении. rsync переживает ошибки чтения отдельных файлов (exit 23) и копирует остальное. + +**⚠️ Почему первая попытка rsync дала только 355G (разгадано 2026-08-18):** дочерние datasets НЕ были смонтированы, поэтому `/RED_2TB/storage` и др. были пустыми mountpoint-дирами; rsync скопировал только ~355G из родительского dataset. **Сначала смонтировать datasets (`zfs mount -a`), потом rsync** — иначе скопируется лишь несколько сотен ГБ. + **Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных). **Что на RED_2TB спасать (структура datasets от 2026-08-17):** @@ -70,6 +76,7 @@ rsync -av --ignore-existing --ignore-errors // <резервный-дис - `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`). - **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly. - `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum). +- **⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n` возвращал exit 0 без ошибок — обманчиво. Реальный `zfs send` даёт `permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send. - Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление). - **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest. - Буквы дисков shift-аются — сверять по by-id/модели, не по буквам.