[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
This commit is contained in:
Alexey Martemyanov
@@ -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` пока не работает (только спасение данных).
|
||||
|
||||
## Доступ
|
||||
|
||||
|
||||
@@ -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 <wd2tb2>`): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.
|
||||
|
||||
|
||||
|
||||
@@ -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 /<pool>/ <резервный-диск>/
|
||||
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 /<pool>/ <резервный-дис
|
||||
- `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/модели, не по буквам.
|
||||
|
||||
Reference in New Issue
Block a user