diff --git a/family/how-to/red2tb-dataset-map.md b/family/how-to/red2tb-dataset-map.md index dcf5e871..8d597fcd 100644 --- a/family/how-to/red2tb-dataset-map.md +++ b/family/how-to/red2tb-dataset-map.md @@ -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`. ## Ссылки diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 9d4b0eca..89188315 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -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`. ## Доступ 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 1f33d908..10c0f12d 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/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 `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. +### 🆕 ПЕРЕСОЗДАНИЕ ПУЛА (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 (запускается ночью воскресенья).