git_admin/obsidian-vault

Fork 0

Files

T

Taiga d5ede3f69c [2026-09-02 12:14:08] taiga-vault: merge conflict — committed markers

2026-09-02 12:14:08 +00:00

47 KiB

Raw Blame History

TrueNAS — SATA порты и пулы

<<<<<<< HEAD

Обновлено: 2026-08-17

✅ РЕШЕНО: HGST 12TB завёлся — проблема была в 3.3V PWDIS, НЕ в карте

=======

Обновлено: 2026-08-21 (данные спасены, пул RED_2TB OFFLINE, готовность к пересозданию). СТАТУС: выгрузка данных на IronWolf завершена успешно (4.56T на /mnt/IRONWOLF, подтверждено Alex). Пул RED_2TB OFFLINE (не импортирован), диски физически на месте. Идёт подготовка к пересозданию пула с новой топологией (добавляем WD2TB#2 зеркалом к WD2TB#1). HGST сломан (см. ниже).

✅ РЕШЕНО (2026-08-21): пул RED_2TB — данные спасены, пул OFFLINE, готовность к пересозданию

ВЫГРУЗКА ДАННЫХ ЗАВЕРШЕНА УСПЕШНО. Alex подтвердил: «операция завершилась успешно, ничего не было перезаписано». Данные RED_2TB (4.56T) лежат на IronWolf 12TB — пул DEST, /mnt/IRONWOLF. Ключевые конфиги подтверждены на /mnt/IRONWOLF: system/tunnel.sh+tunnel_key+.pub (критичный SSH-туннель), docker.bak/ (309M), docker/ (1.1G), immich-photos-upload, dedupe_rm.sh, files.txt.xz. storage/obsidian и storage/git существуют (Permission denied для truenas_admin из-за NFSv4 ACL, transmission-owner — это нормально, НЕ потеря).

Текущее состояние (2026-08-21, live-проверка):

RED_2TB пул — статус OFFLINE в БД TrueNAS (midclt call pool.query → id=1, guid 3817880812699166755), пул НЕ импортирован. zpool export RED_2TB → no such pool (уже выгружен/не в активном контексте).
zpool import -d /dev всё ещё видит RED_2TB как ONLINE импортируемый, члены: sdc2 (simplex WD2TB#1) + mirror-1 {sde2 WD4TB, sdd2 Seagate4TB}.
rsync не запущен — проверочный прогон завершён.
Диски физически на месте (by-id, см. таблицу портов ниже).

Актуальная раскладка дисков (2026-08-21, по /dev/disk/by-id, стабильные имена):

Диск	by-id/model	Роль
sda	`ata-KINGSTON_SA400S37120G_50026B77844E881C`	Boot SSD (не трогать)
sdb	`ata-ST12000NT001-3LX101_WV700FQ5`	⭐ IronWolf 12TB = DEST, `/mnt/IRONWOLF` (целевой, данные выгружены)
sdc	`ata-WDC_WD20EFAX-68B2RN1_WD-WXH2A31D5HDJ`	WD2TB#1 (исходный simplex-член RED_2TB)
sdd	`ata-ST4000DM004-2CV104_WFN66CM2`	Seagate4TB (mirror-1 второй член)
sde	`ata-WDC_WD40EZAZ-00SF3B0_WD-WX22D51JJFZ7`	WD4TB (mirror-1 первый член)
sdf	`ata-WDC_WD20EFAX-68B2RN1_WD-WXJ2A31CUNNT`	WD2TB#2 (доп., НЕ в исходном пуле)

⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1 (ЗАКРЫТО, история): пул RED_2TB импортирован READONLY, данные выгружались rsync

Пан-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) как целевой диск для спасения данных. На нём создан пул-приёмник DEST (rw, ONLINE, ~10.6T свободно), монтируется на /mnt/IRONWOLF. Первая попытка rsync скопировала только 355G (см. блок 2026-08-18 ниже).
WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны.

⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения

2026-08-17 вечер. HGST (HUH721212ALE600, сер. 8CKD08RE) уронили на пол, будучи подключённым. Развитие сценария (как происходило):

После удара — сектор 0 стал нечитаем (по USB-мосту): ядро давало critical medium error, dev sdf, sector 0 → Add. Sense: Unrecovered read error → unable to read partition table / unable to read RDB block 0. Разметка (sdf1/sdf2) пропала. Это НЕ ошибка моста/кабеля — hostbyte=DID_OK driverbyte=DRIVER_OK, ошибку вернул сам диск.
smartctl мог прочитать INFO-секцию (Model: HGST HUH721212ALE600, 8CKD08RE, FW LEBDT3P2, 512e, SATA 6.0 Gb/s, SMART enabled) — контроллер жив, линк поднят.
На MacBook через USB-мост диск «щёлкает» и не шуршит головкой при старте — признак механических проблем после удара (головки/мотор). КЛИК-ОФ-ДЕФ возможен, но также нельзя исключать нехватку питания через USB-мост на 12TB-диске.

Состояние (на 2026-08-17): подтверждён аппаратный отказ — диск не ремонтопригоден. Симптом: ритмичный «click-click, click-click» при работающем моторе = головки не могут выйти на дорожку/парковку (классический click of death после удара). Это механическое повреждение, НЕ лечится программно (SMART/прошивка), чинить может только профи-recovery и это дороже нового диска. Данных на нём НЕТ (не был добавлен в пул, только новая разметка sdf1/sdf2) — поэтому списан без recovery. Закрыто.

⚠️ Урок для будущего: enterprise-диск, уроненный на пол работающим — почти всегда аппаратная смерть (мотор/головки). Если на диске критичные данные — только профи-recovery, и шанс не 100%.

🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон на пол — аппаратный отказ (click of death).

✅ РЕШЕНО (исторически): HGST 12TB заводился — проблема была в 3.3V PWDIS, НЕ в карте

origin/main

2026-08-17. HGST линуется и полностью работает теперь. Ключевое изменение — отключена/обезврежена 3.3V линия (PWDIS-контакт №3 на SATA-разъёме питания). Диск:

определяется как /dev/sde, HGST HUH721212ALE600, серийник 8CKD08RE, 10.9T, секторов 23437770752 (штатная ёмкость 12TB по SFF-8447)
подключён на карте ASMedia (ata7 = 0000:02:00.0, host7) — той самой, где раньше НЕ линковался!
разметка сохранена без переразметки: sde1=200M, sde2=10.9TB (та GPT, что была и через USB)

Вывод: причина молчания была 100% в 3.3V Power Disable (PWDIS) — enterprise-диск с поддержкой PWDIS не раскручивается, когда обычный БП подаёт 3.3V на пин №3 SATA-питания. Снятие 3.3V-контакта устранило проблему. Карта ASM1166 и порт материнки при этом работали и раньше. Переразметка для решения НЕ требуется.

Материнская плата

ASUS P8H77-V LE, чипсет Intel H77. 6 SATA портов на Intel контроллере (порт от ASMedia отсутствует).

<<<<<<< HEAD

Распределение портов (текущее состояние — после перетыкания 2026-08-17)

=======

Распределение портов (актуально на конец 2026-08-17, после финального перетыкания)

origin/main

Порт (ata)	Тип	Скорость	Цвет	Диск	by-id
ata1 (SATA6G_1)	SATA 3	6 Gb/s	серый	sda — WD 2TB (WD20EFAX)	WD-WXH2A31D5HDJ
<<<<<<< HEAD
ata2 (SATA6G_2)	SATA 3	6 Gb/s	серый	sdb — WD 2TB (WD20EFAX, второй, был на карте ata9)	WD-WXJ2A31CUNNT
ata3 (SATA3G_1)	SATA 2	3 Gb/s	синий	sdc — WD 4TB (WD40EZAZ)	WD-WX22D51JJFZ7
ata4 (SATA3G_2)	SATA 2	3 Gb/s	синий	sdd — Kingston 120GB SSD (boot)	50026B77844E881C
ata5 (SATA3G_3)	SATA 2	3 Gb/s	синий	занято диском	—
ata6 (SATA3G_4)	SATA 2	3 Gb/s	синий	sde — Seagate 4TB (ST4000DM004)	WFN66CM2
(карта ASM1166)	—	—	—	НЕ В СЛОТЕ (lspci не видит)	—

⚠️ Состояние на 2026-08-17 после перетыкания:

Карта ASMedia ASM1166 физически вытащена из слота (нет в lspci); /sys/class/ata_port/ содержит только ata1–ata6 (материнка Intel H77). WD 2TB #2 перенесён с карты (ata9) на материнку ata2.
HGST 12TB и IronWolf 12TB сейчас НЕ подключены/НЕ линкуются — их нет ни в lsscsi, ни в /dev/disk/by-id. Не были бы они и на карте (карты нет). HGST мы заводили на карте, значит при её извлечении он отключился.
Несмотря на перетыкание пулы здоровы (см. раздел про пулы ниже) — подтверждено, что ZFS не зависит от порта.

⚠️ В отличие от изначального плана, диски сейчас не по плану — проверять актуальное распределение по by-id/модели, а не по буквам. Типичные буквы при стабильном подключении: sda=WD2TB#1, sdb=WD2TB#2, sdc=WD4TB, sdd=Kingston, sde=Seagate4TB. ======= | ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | sdb — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 | | ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | sdc — ⭐ IronWolf 12TB (ST12000NT001) | WV700FQ5 | | ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | sdd — Kingston 120GB SSD (boot) | 50026B77844E881C | | ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | (свободен/не иден-тиф.) | — | | ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | sde — Seagate 4TB (ST4000DM004) | WFN66CM2 | | (карта ASM1166) | — | — | — | НЕ В СЛОТЕ (вытащена) | — |

⚠️ Фактическое положение на конец сессии (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/модели, не полагаться на буквы.

⚠️ ⚡ СРОЧНО: пул RED_2TB после этого перетыкания НЕ заимпортирован (см. блок «КРИТИЧНО» в разделе пулов). Все члены на месте — нужен Import Pool.

origin/main

Плата расширения SATA в PCIe (установлена ~2026-07-30)

PCIe карта: ASMedia ASM1166 (PCI ID 1b21:1166, rev 02), на шине 02:00.0 (под PCIe bridge 0000:00:1c.0). Контроллер виден ядру (драйвер ahci активен), подсистема: ZyDAS Technology Corp.

Состояние (диагностика 2026-07-31):

Контроллер создал 32 ата-порта (ata7–ata38 на 0000:02:00.0). ⚠️ Это НЕ типичные 6 портов чистой ASM1166 — вероятно плата с расширенным числом портов / мультиплексированием. Уточнить физическое число разъёмов.
На НИ ОДНОМ порту карты нет ни одного подключённого/живого диска: у всех 32 портов в sysfs только ata_port host link power uevent, отсутствуют target* и блок-устройства.
lsscsi показывает диски только на Intel-хостах 0,1,2,3,5. Хосты карты (7–38) без дисков.
В /dev/disk/by-id только 5 дисков — все на материнке.

Целевой диск: HGST 12TB (Ultrastar) — для него и покупалась PCIe SATA-карта. В плане значился как «по USB определяется как sde, USB-карман не нужен, вставить по SATA».

✅ Заключение после решающего теста (карта исправна, дело в HGST):

Карта 100% исправна. При подключении заведомо рабочего WD 2TB (второго WD20EFAX, WD-WXJ2A31CUNNT) в порт карты она определилась — появился host9→target9:0:0 с блок-устройством /dev/sde. Значит слот/порты/кабель AHCI работают, питания хватает.
У карты нет отдельного разъёма питания (питается от PCIe-слота). Диск питается от БП напрямую.
Проверены физические порты карты 1 и 6 — оба без линка для HGST.

✅ Дополнительный тест HGST через USB (2026-08-01) — диск полностью исправен:

HGST 12TB подключён через USB-мост JMicron (152d:0578, "USB to ATA/ATAPI Bridge") на xHCI-порт (usb3/3-1).
Ядро определило его как /dev/sdf, модель HGST HUH721212ALE600, полная ёмкость 10.9 TB (23 437 770 752 сектора × 512 B — точно размер 12TB-драйва).
Диск размечен: sdf1 = 200M, sdf2 = 10.9TB.
Через USB диск заводится, читается на всю ёмкость и виден целиком.

➡️ Уточнённый диагноз: проблема именно в паре HGST SATA-интерфейс ↔ SATA-карта ASMedia, а не в самом диске. Диск работоспособен. Две вероятные причины не-линка по SATA в карте: (1) питание с SATA-разъёма БП до диска в карте не доходит (в USB-боксе питание даёт мост/свой блок, потому и работает), либо (2) enterprise-диск (4Kn/особый PHY) не поднимает линк на ASM1166. USB-мост — рабочий способ диагностики, но ненадёжен как постоянное решение для ZFS.

✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает

<<<<<<< HEAD

⚠️ Актуальный статус на 2026-08-17 вечер: хоть HGST и завёлся (см. ниже КАК), в финальном перетыкании карта ASM1166 вытащена из слота, HGST и IronWolf сейчас НЕ подключены (подробнее в таблице портов выше). Этот блок фиксирует как была решена причина не-линка — пригодится, когда диск вернётся в систему. ======= ⚠️ Актуальный статус на 2026-08-17 ночь: HGST УРОНЕН НА ПОЛ и сломан (см. блок КРИТИЧНО в самом верху). Карта ASM1166 вытащена из слота, IronWolf подключён на материнку. Этот блок фиксирует как изначально решалась причина не-линка (PWDIS) — полезно для понимания, но теперь диск вышел из строя механически.

origin/main

Проблема не-линка HGST по SATA решена: это 3.3V PWDIS на SATA-питании. Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Когда диск снова будет подключён — добавить в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок.

Что было/что стало:

Было: HGST не давал target* ни на одном порту карты ASM1166 (USB-мост работал, потому что питание подавал мост, не затрагивая PWDIS).
Стало: после отключения 3.3V-контакта HGST линкуется на той же карте (ata7/02:00.0) — карта и материнка исправны, дело было в питании.
Переразметка для решения не нужна — проблема на уровне PHY/питания, а не данных.

⚠️ Если такой же enterprise-диск (HGST/WD Ultrastar/Seagate Exos c PWDIS) снова «молчит» по SATA — первым делом проверить 3.3V-пин №3 питания: Molex→SATA адаптер (без 3.3V) или изоляция пина №3 решают.

⚠️ NB: буквы дисков (sda/sdb/...) shift-аются при перетыкивании — сейчас на материнке: [0]=WD2TB, [2]=WD4TB, [3]=Kingston boot, [5]=Seagate4TB, IronWolf на [1]. Не полагаться на буквы, проверять по by-id/модели.

Когда диск заведётся и добавится в пул — обновить таблицу портов выше и удалить этот блок «Следующие шаги».

Диагностические команды (полезно для будущих проверок)

# какие диски видит система и где
lsscsi -H; lsscsi -g
# какие порты создала карта и живы ли (target = есть диск)
ls /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/ata*
# для каждого порта карты — есть ли подключённое устройство (target*):
for a in /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/ata*/host*; do
  tgt=$(ls -d "$a"/target* 2>/dev/null); [ -n "$tgt" ] && echo "$a: $tgt"
done
# контроллеры
lspci -k | grep -i sata

Подключение дисков (исходный план)

HGST 12TB (sde, USB) — при подключении по SATA: в серый порт SATA6G_2 (ata2). Диск enterprise, 6Gb/s. Ему не нужен USB-карман.
Seagate IronWolf — в синий порт SATA3G_3 (ata5). HDD не упирается в 3Gb/s (~300MB/s пропускная), смысла в 6Gb/s нет.
Kingston SSD (boot) — оставить в синем порту SATA3G_2 (ata4). Вся активность только при загрузке, система работает из RAM.
WD 2TB — серый SATA6G_1 (ata1), занят.

Важно про ZFS и перетыкание

ZFS не привязана к букве диска или SATA порту. TrueNAS распознаёт пул по GUID на дисках. <<<<<<< HEAD
Можно перетыкать диски в любые порты — TrueNAS поднимет пул автоматически (подтверждено 2026-08-17).
Если пул не поднялся автоматически: WebUI → Storage → Import Pool. =======
Перетыкание НЕ всегда поднимает пул автоматически (2026-08-17: RED_2TB не заимпортировался сам после перетыкания, см. «КРИТИЧНО» ниже). Если пул не виден в zpool list — нужен ручной Import (WebUI Storage → Import Pool или zpool import <pool> под root). Данные при этом целы, пока все члены ONLINE.

origin/main

Проверка пула после перетыкания: /sbin/zpool status <pool> — убедиться что все члены ONLINE, ошибки 0 0 0.

Пулы TrueNAS (проверено 2026-08-17)

Имена пулов, топология и члены — проверять статус через /sbin/zpool (см. ниже про PATH).

<<<<<<< HEAD

Пул	Размер	Члены (по /dev со стабильным подключением)	Топология	Монтирование
RED_2TB	5.44T (4.60T занято)	mirror: `sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB)	1 диск (sda2) + mirror-1 (2 диска)	`/mnt`
boot-pool	111G (7.65G занято)	`sdd3` (Kingston 120GB boot SSD)	1 диск	—

RED_2TB: HEALTH ONLINE, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. =======

Пул	Размер	Члены (по `/sbin/zpool status` от 2026-08-17)	Топология	Монтирование
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 по zpool status (readonly-импорт не паникует), scrub «завис» на ~72% (при readonly не доходит — но это НЕ фикс, см. ниже). Все ошибки 0 0 0 — данные целы. Один vdev (WD2TB#1) simplex — без зеркала; WD2TB#1 сейчас физически отключён.

✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена

Рабочий рецепт получения доступа к данным подтверждён на практике. Члены пула физически на месте: sda2=WD2TB#1 (ata1), sdb2=WD4TB (ata2, буква сменилась), sde2=Seagate4TB (ata6).

Что сработало (пошагово):

Тюнабели zfs.zfs_recover=1 zfs.zil_replay_disable=1 в GRUB → НЕ помогли (всё равно паника). rd.break=pre-mount и rd.break → тоже НЕ помогли.
ЕДИНСТВЕННЫЙ рабочий способ загрузиться без паники: физически ОТКЛЮЧИТЬ все диски проблемного пула (чтобы дойти до рабочего shell/WebUI), затем вставить обратно.
- Включить с отключёнными дисками RED_2TB (WD2TB#, WD4TB, Seagate4TB) → boot-pool поднимается, паники нет.
- Вставить диски обратно (горячо) в те же порты.
READONLY-импорт не паникует (по mav из iXsystems: «read-only import doesn't even read space maps»):
```
zpool import -o readonly=on RED_2TB
```
→ Import was successful — паники нет, метаданные прочитаны! (попытка zpool import -nRED_2TB без -F невозможна; -n требует -F синтаксиса.)
⚠️ Текущий блок: после readonly-импорта выдаются ошибки монтирования:
```
cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system
Import was successful, but unable to mount some datasets
```
Причина: корневая ФС readonly (после обхода паники). Точки монтирования не создаются.

СЛЕДУЮЩИЙ ШАГ (не завершён): смонтировать datasets вручную в существующую/записываемую точку (корневая / readonly). Порядок:

zfs list -r RED_2TB   # какие datasets есть (zfs list работает без mount)
# смонтировать в существующую пустую папку, не создавая новую (или через tmpfs/rw-точку)
# например:
#   mkdir -p /mnt/rec 2>/dev/null;  (если /mnt rw — иначе выбрать rw-точку)
#   zfs set mountpoint=/mnt/rec RED_2TB  (или mount -o)
# затем выгружать данные на запасные диски rsync

Критичные ограничения (выяснены по ходу):

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 (идеально байт-в-байт со снимками, но требует пула-приёмника и снимка).

⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок.

🆕 ПРОГРЕСС (2026-08-18): datasets смонтированы под root, выгрузка идёт rsync — НЕ send|recv

Смонтирование дочерних datasets — РАБОТАЕТ под root. Это снимает блокер «datasets не смонтированы» из прошлой сессии:

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):

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>): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления.

✅ ПЕРЕСОЗДАНИЕ ПУЛА (2026-08-21) — ВЫПОЛНЕНО

Решение (подтверждено Alex): пересоздаём RED_2TB с новой топологией — ВКЛЮЧАЕМ WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc). В итоге: mirror {sdc, sdf} + mirror {sde, sdd} — оба исходных simplex-члена получают зеркала (ранее WD2TB#1 был simplex без защиты).

✅ СТАТУС (2026-08-21, live): пул СОЗДАН успешно. zpool create RED_2TB mirror /dev/sdc /dev/sdf mirror /dev/sde /dev/sdd → state: ONLINE, 0 0 0 ошибок, No known data errors, SIZE 5.44T, ALLOC 384K, HEALTH ONLINE. Пул пустой (данные ещё возвращаются).

Записи TrueNAS, которые важно знать (2026-08-21):

midclt call pool.query → id=1, name=RED_2TB, status=OFFLINE, topology:null. Устаревшая запись в БД.
midclt call pool.delete 1 НЕ существует в этом билде ('PoolService' object has no attribute 'do_delete') — запись через API не удалить. Пользоваться командной строкой zpool (root) или UI.
zpool labelclear -f принимает только ОДИН vdev за раз — «too many arguments» при передаче нескольких дисков.

Команды пересоздания (под root, на консоли TrueNAS):

# 1. Стереть старые метки ZFS с ПАРТИЦИЙ (пул был построен на разделах *2, НЕ на целых дисках!)
zpool labelclear -f /dev/sdc2
zpool labelclear -f /dev/sdf2
zpool labelclear -f /dev/sde2
zpool labelclear -f /dev/sdd2

# 2. Проверить, что RED_2TB исчез из импортируемых
zpool import -d /dev

# 3. Создать пул заново на ЦЕЛЫХ дисках (TrueNAS создаст свои разделы *2)
zpool create RED_2TB mirror /dev/sdc /dev/sdf mirror /dev/sde /dev/sdd

# 4. Проверить
zpool status RED_2TB
zpool list RED_2TB

⚠️ КРИТИЧЕСКИЕ ЛОВУШКИ labelclear (из openzfs issues #18027, #3156, #14869):

Целиться надо в ПАРТИЦИИ (*2), а не в целый диск. TrueNAS строит пулы на разделах ...2. zpool labelclear -f /dev/sdc (целый диск) даёт failed to clear label for /dev/sdc — метки лежат внутри раздела sdc2, на целом диске их «не видит» целиком.
failed to clear label также выводится, когда метки УЖЕ стёрты (issue #18027) — не обязательно ошибка. Если после labelclear zpool import -d /dev не показывает RED_2TB — значит метки стёрты, всё ок.
labelclear сам по себе может не стереть оба набора меток (#14869), если чистить не ту цель — поэтому чистить по разделам, которые реально добавлялись.

🧭 НОВАЯ ТОПОЛОГИЯ ПОСЛЕ ПЕРЕСОЗДАНИЯ:

vdev	Члены	Назначение
mirror-0	sdc (WD2TB#1) + sdf (WD2TB#2)	Пара WD 2TB (зеркалирование)
mirror-1	sde (WD4TB) + sdd (Seagate4TB)	Пара 4TB (зеркалирование)

После создания пула — НЕ забыть:

пересоздать datasets по red2tb-dataset-map (storage, backup, Photos, Edu, TimeMachine/guest, docker, old-bu, iocage; .system/ix-apps TrueNAS создаст сама);
решить судьбу данных ВНЕ датасетов (system/, docker.bak/, immich-photos-upload/, корневые файлы) — после пересоздания окажутся в корневом dataset;
вернуть данные: rsync -aHAX /mnt/IRONWOLF/ /RED_2TB/;
восстановить инфраструктуру (docker: caddy, transmission, HA, immich...), доступы, cron-бэкапы, Obsidian sync.

✅ LIVE-СТАТУС ПОСЛЕ ПЕРЕСОЗДАНИЯ (2026-08-24, проверка Китом)

Пул УЖЕ зарегистрирован в TrueNAS и работает — перезагрузка/импорт НЕ нужны:

zpool status RED_2TB → ONLINE (mirror-0 {sdc,sdf} + mirror-1 {sde,sdd}), ошибки 0 0 0.
midclt call pool.query → id=1, name=RED_2TB, status=ONLINE, topology заполнена новой (оба mirror, GUIDs). БД TrueNAS привязала пул по GUID, запись обновлена под новую топологию.
Пул смонтирован (/mnt/RED_2TB/, mounted=yes), CAP 79% (5.44T, ALLOC 4.35T, FREE 1.09T).
rsync возврата данных ЗАВЕРШЁН. Вернулись все datasets: storage 3.29T, immich-photos-upload 353G, backup 287G, Edu 214G, Photos 146G, old-bu 65.2G, docker 2.92G, docker.bak 789M, system 112K. Корни IronWolf↔RED_2TB идентичны по ls.

⚠️ НЕ ЗАКРЫТО: TimeMachine (~277G) НЕ вернулся. Причина: на IronWolf /mnt/IRONWOLF/TimeMachine/ существует (277G), но root-only NFSv4 ACL → truenas_admin НЕ может прочитать (Permission denied) → rsync его не докопировал. На RED_2TB датасет TimeMachine НЕ воссоздан (нет в zfs list, каталога нет). TODO под root: создать dataset RED_2TB/TimeMachine (+ дочерний guest как было) и rsync -aHAX /mnt/IRONWOLF/TimeMachine/ /mnt/RED_2TB/TimeMachine/. iocage-каталог восстановлен, но старые jails не нужны (всё в docker) — решено ранее.

⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №3 (2026-08-24): Docker/слой приложений НЕ поднят — контейнеры лежат

Пул с файлами работает, но слой приложений (docker/TrueNAS Apps) НЕ восстановлен. Проверка live (Кит):

docker ps → Cannot connect to the Docker daemon. systemctl status docker → inactive (dead), disabled.
docker daemon.json (/etc/docker/daemon.json): {"data-root": "/mnt/.ix-apps/docker", "exec-opts": ["native.cgroupdriver=cgroupfs"], "iptables": true, "storage-driver": "overlay2", "default-address-pools": [{"base": "172.17.0.0/12", "size": 24}]} → это классическая схема TrueNAS Apps.
Датасета .ix-apps/ix-applications НЕТ в zfs list на пересозданном пуле → docker storage/образы/volumes (в старом пуле это был датасет ix-apps, docker 23.6G) НЕ мигрировали / потеряны.
Конфиги ВСЕХ приложений на месте в /mnt/RED_2TB/docker/ (29 каталогов): arr, backups, caddy, cups, filebrowser, gitea, ha, hermes, homeassistant, immich, inpx-web, inpxer, library, mbusd, modbus-bridge, mosquitto, nodered, portainer, portainer-mcp, python, rclone, ser2net, syncthing, transmission, vless-proxy, watchtower, webdav, xray-admin, zigbee2mqtt.
override.conf (/etc/systemd/system/docker.service.d/override.conf): только ExecStartPost=iptables -P FORWARD ACCEPT && ip6tables -P FORWARD ACCEPT — применяется при старте docker.

Вывод: /mnt/RED_2TB/docker/ — это конфиги; docker-образы (layers) не сохранились → контейнеры надо пересоздавать с перекачкой образов.

ПЛАН ВОЗВРАТА КОНФИГА В СТРОЙ (4 шага, пока НЕ выполнен):

WebUI TrueNAS → Apps → Settings → Choose Pool → RED_2TB. TrueNAS сама создаст датасет приложений (ним ix-applications), примонтирует docker storage в /mnt/ix-applications (data-root .ix-apps/docker), поднимет docker.service. (docker сейчас disabled — старт произойдёт именно через настройку Apps, не вручную.)
Конфиги приложений уже лежат в /mnt/RED_2TB/docker/<app> — трогать не надо.
Пересоздать каждый контейнер (WebUI Apps нативный/Custom App) с bind-mount /mnt/RED_2TB/docker/<app> → внутрь контейнера. Образы перекачаются при старте, контейнер подхватит свой существующий конфиг.
Разовое: override.conf (iptables FORWARD) применится сам при старте docker; порты/сеть прежние; данные приложений (immich library, transmission downloads и т.д.) уже в /mnt/RED_2TB/.

⚠️ Перезагрузка НЕ поможет поднять контейнеры: docker disabled + пул приложений не настроен. Перезагрузка полезна только ПОСЛЕ шага 1. ⚠️ Вопрос к Alex: docker storage .ix-apps (образы, ~23.6G) точно НЕ переносили на IronWolf? Если перенесли — указать куда, вернуть и настройка упростится (образы сохранятся). Если нет — только перекачка.

⚠️ НЕ ВХОДИТЬ В RW-ИМПОРТ ПОВРЕЖДЁННоГО ПУЛА

Импорт RED_2TB в не-readonly режиме (zpool import без -o readonly=on) — ВСЕГДА даёт kernel panic (zfs: adding existent segment to range tree). Это правило подтверждено много раз. При пересоздании пул НЕ импортировать — только стереть метки (labelclear) и создать заново. zpool import -d /dev (dry-list) безопасен, но не запускает пул.

origin/main

Идёт регулярный scrub (запускается ночью воскресенья).
zpool не в PATH для zsh truenas_admin — вызывать через абсолютный путь /sbin/zpool или /usr/sbin/zpool (иначе command not found).

Запрещено

Boot pool (Kingston 120GB SSD) — нельзя использовать для Docker, файлов, app data. TrueNAS обновления могут пересоздать boot pool. Размер 120GB мал для логов/образов.

SATA кабель

Любой стандартный SATA кабель подходит. Разницы между кабелями для SATA 2 и SATA 3 нет.

47 KiB Raw Blame History Unescape Escape

TrueNAS — SATA порты и пулы

✅ РЕШЕНО: HGST 12TB завёлся — проблема была в 3.3V PWDIS, НЕ в карте

✅ РЕШЕНО (2026-08-21): пул RED_2TB — данные спасены, пул OFFLINE, готовность к пересозданию

⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1 (ЗАКРЫТО, история): пул RED_2TB импортирован READONLY, данные выгружались rsync

⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения

✅ РЕШЕНО (исторически): HGST 12TB заводился — проблема была в 3.3V PWDIS, НЕ в карте

Материнская плата

Распределение портов (текущее состояние — после перетыкания 2026-08-17)

Распределение портов (актуально на конец 2026-08-17, после финального перетыкания)

Плата расширения SATA в PCIe (установлена ~2026-07-30)

✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает

Диагностические команды (полезно для будущих проверок)

Подключение дисков (исходный план)

Важно про ZFS и перетыкание

Пулы TrueNAS (проверено 2026-08-17)

✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена

🆕 ПРОГРЕСС (2026-08-18): datasets смонтированы под root, выгрузка идёт rsync — НЕ send|recv

✅ ПЕРЕСОЗДАНИЕ ПУЛА (2026-08-21) — ВЫПОЛНЕНО

✅ LIVE-СТАТУС ПОСЛЕ ПЕРЕСОЗДАНИЯ (2026-08-24, проверка Китом)

⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №3 (2026-08-24): Docker/слой приложений НЕ поднят — контейнеры лежат

⚠️ НЕ ВХОДИТЬ В RW-ИМПОРТ ПОВРЕЖДЁННоГО ПУЛА

Запрещено

SATA кабель

47 KiB

Raw Blame History