[2026-08-18] eagle: family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md

personal/tech/truenas-zfs-panic-recovery.md

@@ -35,21 +35,27 @@ panic - not syncing: zfs: adding existent segment to range tree
 ```
 → `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо.
 
-### 3. Монтирование datasets вручную (root ФС readonly):
+### 3. Монтирование datasets (2026-08-18: подтверждено под root)
 
-Ошибка `cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system` — из-за READONLY корневой ФС. Монтируй вручную в записываемую точку:
+Если корневая ФС readonly мешает создавать mountpoint-ы (`cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system`) — сначала сделать root ФС rw, затем смонтировать всё:
 ```bash
-zfs list -r RED_2TB                    # список datasets (работает без mount)
-zfs set mountpoint=/mnt/rec RED_2TB    # или mount -o
+mount -o remount,rw /
+zfs mount -a
 ```
+После этого дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) видны на `/RED_2TB/*` (все `ro` — readonly; для чтения rsync это ок). Проверка: `df -h /RED_2TB` покажет ~4.6T (НЕ 1.1T родительского), `ls /RED_2TB/storage` не пуст.
+> ⚠️ Монтирование — **только под root**. Под `truenas_admin` `zfs mount -a` даёт `Insufficient privileges`.
 
 ### 4. Выгрузка:
 
 ```bash
-rsync -av --ignore-existing --ignore-errors /<pool>/ <резервный-диск>/
+rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 &
 ```
 Лучше в tmux. Затем `zpool destroy` + пересоздать пул.
 
+**⚠️ ВАЖНО (2026-08-18): использовать именно `rsync`, НЕ `zfs send | zfs recv`.** `zfs send` на пуле с повреждённой space map падает (`signal received` / `Bad file descriptor` / `IOT (core dumped)`, exit 1) — ZFS не может прочитать данные на лету при stream-чтении. rsync переживает ошибки чтения отдельных файлов (exit 23) и копирует остальное.
+
+**⚠️ Почему первая попытка rsync дала только 355G (разгадано 2026-08-18):** дочерние datasets НЕ были смонтированы, поэтому `/RED_2TB/storage` и др. были пустыми mountpoint-дирами; rsync скопировал только ~355G из родительского dataset. **Сначала смонтировать datasets (`zfs mount -a`), потом rsync** — иначе скопируется лишь несколько сотен ГБ.
+
 **Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных).
 
 **Что на RED_2TB спасать (структура datasets от 2026-08-17):**
@@ -70,6 +76,7 @@ rsync -av --ignore-existing --ignore-errors /<pool>/ <резервный-дис
 - `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`).
 - **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly.
 - `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum).
+- **⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n` возвращал exit 0 без ошибок — обманчиво. Реальный `zfs send` даёт `permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send.
 - Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление).
 - **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest.
 - Буквы дисков shift-аются — сверять по by-id/модели, не по буквам.