[2026-08-17] 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-17 (конец сессии)
|
||||
|
||||
> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB вызывает KERNEL PANIC — все данные/контейнеры/в vault на этом пуле недоступны
|
||||
> **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 bootloop из-за повреждённой space map (ошибка `adding existent segment to range tree` при `import -F`).
|
||||
> **Рецепт восстановления и полная картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md`** (раздел «Пулы»): тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем аккуратный `zpool import`. ПОКА НЕ РЕШЕНО — инфраструктура, завязанная на `/mnt/RED_2TB`, не работает.
|
||||
> ## ⚠️⚠️ КРИТИЧНО (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` не работает.
|
||||
|
||||
## Доступ
|
||||
|
||||
|
||||
@@ -1,10 +1,16 @@
|
||||
# TrueNAS — SATA порты и пулы
|
||||
|
||||
> Обновлено: 2026-08-17 глубокая ночь (РО: HGST упал и сломан; RED_2TB импортирован READONLY — смонтировать datasets и выгрузить — см. раздел пулов)
|
||||
> Обновлено: 2026-08-17 (через время после readonly-импорта). СТАТУС: данные RED_2TB ещё НЕ выгружены. IronWolf 12TB подключён как целевой диск для спасения. Блокер: для `zpool import`/`mount` нужен root, а `truenas_admin` не root. HGST сломан (см. ниже).
|
||||
|
||||
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы (данные ещё НЕ выгружены)
|
||||
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы, данные НЕ выгружены
|
||||
|
||||
См. раздел «Пулы TrueNAS» → блок «RED_2TB readonly-импорт». **Прогресс:** пан-loop преодолён (см. рецепт ниже), RD_2TB импортирован readonly успешно. **Осталось смонтировать datasets вручную и выгрузить данные** — точка монтирования не создалась из-за read-only корневой ФС. Это приоритет №1 — данные есть.
|
||||
Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **Осталось:** смонтировать datasets вручную и выгрузить данные на IronWolf. Это приоритет №1 — данные есть, но пул восстановится только пересозданием, so спасаем.
|
||||
|
||||
**ТЕКУЩИЙ БЛОКЕР (конец сессии):**
|
||||
- `zpool import`/`mount` требуют **root** (`some devices require root privileges`). `truenas_admin` НЕ root (sudo просит пароль). Все операции с пулом — только под root.
|
||||
- **Нужно добыть root:** SSH → включить root login (`PermitRootLogin`), или выполнять команды через WebUI-админ/консоль.
|
||||
- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём ещё не создан пул-приёмник.
|
||||
- **WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН** — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны.
|
||||
|
||||
## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения
|
||||
|
||||
@@ -48,11 +54,11 @@
|
||||
| ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sde** — Seagate 4TB (ST4000DM004) | WFN66CM2 |
|
||||
| *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (вытащена) | — |
|
||||
|
||||
**⚠️ Фактическое положение на конец сессии (2026-08-17):**
|
||||
- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`) и не относящийся к делу PCIe-to-PCI bridge ASM1083. WD 2TB#2 перенесён с карты на материнку.
|
||||
- **⭐ IronWolf 12TB теперь ПОДКЛЮЧЁН и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он не в пуле (новый диск).
|
||||
- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) НАМЕРЕННО отключён** пользователем (2026-08-17). Раньше был `sdb` (перенесён с карты), затем Alex его отключил «это норм». Сейчас отсутствует по замыслу, а не по ошибке.
|
||||
- **HGST 12TB (`HUH721212ALE600`)** — был подключён по USB (виден как `sdf`, model HGST, WWN `0x5000cca26fefbc05`) и после удара о пол НЕ работает надёжно (см. блок КРИТИЧНО в самом верху). На текущий момент считаем его вышедшим из строя.
|
||||
**⚠️ Фактическое положение на конец сессии (2026-08-17, после подключения IronWolf для спасения):**
|
||||
- **Буквы разъехались ещё раз.** Финальный `lsscsi`: **sda=WD4TB**, **sdb=Kingston boot**, **sdc=⭐ IronWolf 12TB (целевой для спасения)**, **sdd=Seagate4TB**. **WD 2TB#1 (`WD-WXH2A31D5HDJ`) СЕЙЧАС ОТКЛЮЧЁН / НЕ в системе** (отсоединяли, чтобы загрузиться без паники).
|
||||
- **⭐ IronWolf 12TB подключён к материнке и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он свободен (не в пуле) и определён как **целевой диск для спасения данных с RED_2TB**. На нём ещё НЕ создан пул-приёмник.
|
||||
- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`). WD 2TB#2 перенесён с карты, затем был намеренно отключён пользователем.
|
||||
- **HGST 12TB (`HUH721212ALE600`)** — УРОНЕН НА ПОЛ, аппаратный отказ (см. блок КРИТИЧНО), считается вышедшим из строя.
|
||||
|
||||
> ⚠️ Буквы (`sda`/`sdb`) **shift-аются при перетыкании** и сейчас разъехались: `sdb` = WD4TB (не WD2TB#2!), `sdc` = IronWolf. **Всегда сверять по by-id/модели, не полагаться на буквы.**
|
||||
|
||||
@@ -132,12 +138,12 @@ lspci -k | grep -i sata
|
||||
|
||||
Имена пулов, топология и члены — проверять статус через `/sbin/zpool` (см. ниже про PATH).
|
||||
|
||||
| Пул | Размер | Члены (по /dev со стабильным подключением) | Топология | Монтирование |
|
||||
| Пул | Размер | Члены (по `/sbin/zpool status` от 2026-08-17) | Топология | Монтирование |
|
||||
|-----|--------|-----------|-----------|--------------|
|
||||
| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdb2`/`sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` — **⚠️ ПОТРЕБУЕТСЯ IMPORT, см. ниже** |
|
||||
| **boot-pool** | 111G (7.65G занято) | `sdd3` (Kingston 120GB boot SSD) | 1 диск | — |
|
||||
| **RED_2TB** | 5.44T (4.60T занято) | **state ONLINE, 0 0 0 ошибок, "No known data errors"**: `sdd2` (WD2TB#1) + mirror-1 `{sdc2 WD4TB, sdb2 Seagate4TB}` — буквы по последнему status, сверять by-id (буквы shift-аются) | 1 диsk (`WD2TB#1`) + mirror-1 (WD4TB+Seagate) | `/mnt` — **readonly-импорт, datasets не смонтированы, данные НЕ выгружены** |
|
||||
| **boot-pool** | 111G (7.65G занято) | `sdb3` (Kingston 120GB boot SSD) | 1 диск | — |
|
||||
|
||||
- RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала.
|
||||
- RED_2TB: HEALTH **ONLINE** по `zpool status` (readonly-импорт не паникует), scrub «завис» на ~72% (при readonly не доходит — но это НЕ фикс, см. ниже). Все ошибки 0 0 0 — **данные целы**. Один vdev (`WD2TB#1`) simplex — без зеркала; WD2TB#1 сейчас физически отключён.
|
||||
|
||||
### ✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена
|
||||
|
||||
@@ -171,10 +177,18 @@ zfs list -r RED_2TB # какие datasets есть (zfs list работает
|
||||
```
|
||||
|
||||
**Критичные ограничения (выяснены по ходу):**
|
||||
- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root.
|
||||
- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root. **На конец сессии это главный блокер** — без root не смонтировать/выгрузить.
|
||||
- Раньше при readonly-импорте в тредах было: datasets показываются но пути «not found», и полностью нечитаемы (permission denied) если данные повреждены. Здесь readonly-импорт прошёл чисто (no panic) — но монтирование ещё не доведено до конца.
|
||||
- **Данные на пуле важно выгрузить на другие диски** (пул восстановится только пересозданием — аппаратная метаданная ошибка). Это главный незавершённый шаг.
|
||||
|
||||
**🧪 ИТОГ ПО «ПОЧИНИТЬ ПУЛ» (2026-08-17, важно для будущих сессий):**
|
||||
- **In-place «починки» НЕТ.** По mav (лидер OS-команды iXsystems) в тредах: *"I don't know a way to recover from this situation without data offload and pool recreation"*. Паника на space map не лечится флагами.
|
||||
- **Опции это НЕ решают:** `zfs.zfs_recover=1`, `zfs.zil_replay_disable=1` (в GRUB), `rd.break=pre-mount`, `rd.break` — все НЕ помогли (паника осталась). Readonly-импорт («doesn't even read space maps») — единственное, что не паникует и даёт доступ к данным.
|
||||
- **`-F` (восстановление) уже показал панику** в этой сессии (`adding existent segment to range tree`). Повторный `-F` на повреждённом пуле рискован — может углубить повреждение. Не жать вслепую.
|
||||
- **`zpool attach RED_2TB <wd2tb2>` (идея зеркала на 2 WD2TB) НЕ выполнима в текущем состоянии**: attach — это write, он пишет в space maps (обновляет метаданные) → паника. Readonly-импорт не даст attach; переимпорт в rw вернёт панику. Также 2TB не влезет под 4.6T данных целиком. Идея зеркала валидна только ПОСЛЕ пересоздания пула из спасённых данных.
|
||||
- **Правильная дорога (единственная надёжная):** readonly-импорт → смонтировать datasets вручную → выгрузить данные на целевой пул (IronWolf 12TB) → пересоздать RED_2TB → вернуть данные. Попытки «починить rw» возможны, но только ПОСЛЕ спасения данных и на свой риск.
|
||||
- **Для «100% восстановления с правами»:** `rsync -aHAX` (права, владельцы, ACL, xattr, хардлинки) или `zfs send | zfs recv` (идеально байт-в-байт со снимками, но требует пула-приёмника и снимка).
|
||||
|
||||
> ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок.
|
||||
|
||||
**Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB <wd2tb2>`): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.
|
||||
|
||||
Reference in New Issue
Block a user