[2026-08-21] eagle: family/how-to/red2tb-dataset-map.md family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md

This commit is contained in:
Alexey Martemyanov
2026-08-21 12:07:04 +06:00
parent 1d621faa59
commit 5c67fc2139
3 changed files with 83 additions and 12 deletions
+8 -6
View File
@@ -4,12 +4,13 @@
> НАЗНАЧЕНИЕ: решить, воссоздавать ли карту датасетов как есть, или что-то поменять/добавить/убрать перед пересозданием пула RED_2TB.
> Ничего не изменялось — только сбор информации.
## Статус спасения на 2026-08-20
## Статус спасения на 2026-08-21
- **DEST (IronWolf 12TB, /mnt/IRONWOLF)**: 4.56T из 10.9T занято — данные уже выгружены rsync.
- **RED_2TB**: 4.61T занято, readonly-импорт. Все datasets видны и смонтированы.
- Идёт **проверочный rsync** (`ir-chk` на ~1.8 млн файлов) — сверка, а не первая передача.
- После проверки и сверки `du` — ПЕРЕСОЗДАНИЕ пула и возврат данных.
- **Выгрузка ЗАВЕРШЕНА УСПЕШНО** (подтверждено Alex). Данные RED_2TB (4.56T) на IronWolf — `DEST`, `/mnt/IRONWOLF`.
- **RED_2TB пул — OFFLINE** в БД TrueNAS (id=1), НЕ импортирован. `zpool export``no such pool`.
- Проверочный rsync прогон завершён (rsync не запущен).
- **РЕШЕНИЕ:** пересоздаём пул с новой топологией — ВКЛЮЧАЕМ WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc). Итог: `mirror {sdc,sdf}` + `mirror {sde,sdd}`.
- Следующий шаг: `zpool labelclear` по разделам `*2` + `zpool create` (подробно в [[truenas-sata-ports-and-zfs-pools]] → «Пересоздание пула 2026-08-21»).
## Общая сводка
@@ -62,8 +63,9 @@
- In-place починки НЕТ (битая space map, паника на rw).
- Рабочий путь: readonly-импорт → выгрузка rsync → `zpool destroy`+`create` → возврат данных rsync.
- НЕ использовать `zfs send|recv` (падает на повреждённом пуле). Только rsync.
- После пересоздания можно добавить WD2TB#2 зеркалом к WD2TB#1 (сейчас simplex, без защиты).
- **РЕШЕНО (2026-08-21):** включить WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc) при пересоздании. Топология `mirror {sdc,sdf}` + `mirror {sde,sdd}` — оба зеркалированы.
- `zpool import`/`mount`/destroy/create — ТОЛЬКО под root (truenas_admin не root).
- **НИКОГДА не импортировать RED_2TB в rw** (kernel panic). Только `labelclear` + `create`.
## Ссылки
+5 -4
View File
@@ -1,10 +1,11 @@
# TrueNAS — инфраструктура
> Обновлено: 2026-08-18 (datasets смонтированы, выгрузка rsync идёт)
> Обновлено: 2026-08-21 (данные спасены на IronWolf, пул RED_2TB OFFLINE, готовность к пересозданию)
> ## ⚠️⚠️ АКТИВНО (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` пока не работает (только спасение данных).
> ## ⚠️ СТАТУС на 2026-08-21: пул RED_2TB — данные СПАСЕНЫ, пул OFFLINE, пересоздаём
> **Выгрузка успешно завершена** (подтверждено Alex): данные RED_2TB (4.56T) на IronWolf (пул `DEST`, `/mnt/IRONWOLF`). **Пул RED_2TB — статус OFFLINE** в БД TrueNAS, НЕ импортирован. Конфиги docker (caddy, transmission, HA, immich и т.д.), Obsidian vault и git-репо спасены на `/mnt/IRONWOLF` (`system/`, `docker.bak/`, `docker/`, `storage/obsidian`, `storage/git`).
> **ПЛАН (следующий шаг):** пересоздать пул RED_2TB с новой топологией `mirror {sdc,sdf}` + `mirror {sde,sdd}` (включаем WD2TB#2 зеркалом к WD2TB#1). Команды `zpool labelclear` + `zpool create` — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пересоздание пула 2026-08-21»). Затем вернуть данные rsync с IronWolf и восстановить инфраструктуру.
> **ПРОТОКОЛ ПОВРЕЖДЕНИЯ (история):** пул паниковал на rw-импорте (`adding existent segment to range tree`, повреждённая space map). Работал только `zpool import -o readonly=on`. In-place починки нет (mav/iXsystems) — только спасать данные и пересоздавать. Полный рецепт — в `family/how-to/truenas-sata-ports-and-zfs-pools.md`.
## Доступ
@@ -1,8 +1,28 @@
# TrueNAS — SATA порты и пулы
> Обновлено: 2026-08-18 (datasets смонтированы под root, rsync перезапущен). СТАТУС: данные RED_2TB на этапе выгрузки на IronWolf — смонтированные дочерние datasets готовы к rsync. IronWolf 12TB = целевой пул `DEST` (rw, 10.6T свободно). HGST сломан (см. ниже).
> Обновлено: 2026-08-21 (данные спасены, пул RED_2TB OFFLINE, готовность к пересозданию). СТАТУС: выгрузка данных на IronWolf **завершена успешно** (4.56T на `/mnt/IRONWOLF`, подтверждено Alex). Пул RED_2TB **OFFLINE** (не импортирован), диски физически на месте. Идёт подготовка к пересозданию пула с новой топологией (добавляем WD2TB#2 зеркалом к WD2TB#1). HGST сломан (см. ниже).
## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, datasets смонтированы, данные выгружаются rsync
## ✅ РЕШЕНО (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** (см. блок ниже).
@@ -221,6 +241,54 @@ while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2
**Опция добавить 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 без защиты).
**Записи 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):**
```bash
# 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.
## ⚠️ НЕ ВХОДИТЬ В 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) безопасен, но не запускает пул.
- Идёт регулярный scrub (запускается ночью воскресенья).