diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 7bc5fbf0..4ddf7ae1 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-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` не работает. ## Доступ 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 c32b9394..f611abd3 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -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 ` (идея зеркала на 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 `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md index c9d5b479..fc042d5f 100644 --- a/personal/tech/truenas-zfs-panic-recovery.md +++ b/personal/tech/truenas-zfs-panic-recovery.md @@ -50,10 +50,23 @@ rsync -av --ignore-existing --ignore-errors // <резервный-дис ``` Лучше в tmux. Затем `zpool destroy` + пересоздать пул. +**Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных). + +**Что на RED_2TB спасать (структура datasets от 2026-08-17):** +- Критично (пользовательские данные): `storage` (3.24T), `backup` (287G), `Photos` (146G), `Edu` (214G), `TimeMachine` (+`guest`, 277G), `old-bu` (65.5G), `openbsd` (10.2G). +- Конфиги (если нужно): `docker` (2.98G), `iocage/*` jails (plex, emby, homeassistant, transmission, worker), `ix-apps` (24G). +- Служебное не критично: `RED_2TB/.system/*`. +- Итого ~4.6T. Для «100% восстановления с правами»: `rsync -aHAX` или `zfs send | zfs recv`. + +### 5. Пул НЕ чинится in-place — только пересоздание + +`zpool attach` (идея зеркала на 2 WD2TB) НЕ выполним в текущем состоянии — attach это write → паника. Всегда: спасти → destroy → recreate. + ## Подводные камни - `zpool` не в PATH для zsh-юзеров (`command not found`) — использовать `/sbin/zpool` или `/usr/sbin/zpool`. -- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. +- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. **На конец 2026-08-17 это главный блокер** — для импорта/монтирования/выгрузки нужен root (через WebUI-админ, консоль, или включив `PermitRootLogin` в SSH). +- **WD 2TB#1 (`sdd2` simplex-член RED_2TB) сейчас отключён** — чтобы загрузиться без паники его отсоединяли. RED_2TB импортируется без него (mirror-1 жив), но его данные частично недоступны. Учесть при восстановлении. - `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`). - **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly. - `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum).