Алгоритмы восстановления файловой системы Btrfs

[!INFO] Применимость
ALT Linux 10.4–11.x · Btrfs · локальная работа через CLI/TTY · доступ root

Заметка содержит отдельные самодостаточные алгоритмы для Btrfs на:

• HDD;
• SSD и NVMe;
• собственном многодисковом массиве Btrfs;
• Linux Software RAID;
• LVM;
• Multipath и SAN LUN;
• NFS;
• SMB/DFS.

Перед работой проверить версии:

btrfs version
uname -r

Оглавление

• [[#Главные отличия Btrfs|Главные отличия Btrfs]]
• [[#Основные запреты|Основные запреты]]
• [[#Когда Btrfs ремонтировать нельзя|Когда Btrfs ремонтировать нельзя]]
• [[#Алгоритм 1. Btrfs на исправном HDD|Алгоритм 1. Btrfs на исправном HDD]]
• [[#Алгоритм 2. Btrfs на HDD с физическими ошибками|Алгоритм 2. Btrfs на HDD с физическими ошибками]]
• [[#Алгоритм 3. Btrfs на исправном SSD или NVMe|Алгоритм 3. Btrfs на исправном SSD или NVMe]]
• [[#Алгоритм 4. Btrfs на отказывающем SSD или NVMe|Алгоритм 4. Btrfs на отказывающем SSD или NVMe]]
• [[#Алгоритм 5. Ошибки контрольных сумм при наличии избыточной копии|Алгоритм 5. Ошибки контрольных сумм при наличии избыточной копии]]
• [[#Алгоритм 6. Btrfs неожиданно перешла в read-only|Алгоритм 6. Btrfs неожиданно перешла в read-only]]
• [[#Алгоритм 7. Btrfs не монтируется после сбоя журнала|Алгоритм 7. Btrfs не монтируется после сбоя журнала]]
• [[#Алгоритм 8. Btrfs не монтируется из-за повреждённого корня дерева|Алгоритм 8. Btrfs не монтируется из-за повреждённого корня дерева]]
• [[#Алгоритм 9. Повреждены суперблоки Btrfs|Алгоритм 9. Повреждены суперблоки Btrfs]]
• [[#Алгоритм 10. Повреждено дерево чанков|Алгоритм 10. Повреждено дерево чанков]]
• [[#Алгоритм 11. Btrfs заполнена и возвращает ENOSPC|Алгоритм 11. Btrfs заполнена и возвращает ENOSPC]]
• [[#Алгоритм 12. Собственный многодисковый массив Btrfs исправен, но содержит ошибки|Алгоритм 12. Собственный многодисковый массив Btrfs исправен, но содержит ошибки]]
• [[#Алгоритм 13. Отказал участник собственного массива Btrfs|Алгоритм 13. Отказал участник собственного массива Btrfs]]
• [[#Алгоритм 14. Btrfs поверх Linux Software RAID|Алгоритм 14. Btrfs поверх Linux Software RAID]]
• [[#Алгоритм 15. Btrfs поверх LVM|Алгоритм 15. Btrfs поверх LVM]]
• [[#Алгоритм 16. Btrfs поверх Multipath или SAN LUN|Алгоритм 16. Btrfs поверх Multipath или SAN LUN]]
• [[#Алгоритм 17. Каталог подключён по NFS|Алгоритм 17. Каталог подключён по NFS]]
• [[#Алгоритм 18. Каталог подключён по SMB или DFS|Алгоритм 18. Каталог подключён по SMB или DFS]]
• [[#Алгоритм 19. Файловая система не ремонтируется, но данные ещё можно извлечь|Алгоритм 19. Файловая система не ремонтируется, но данные ещё можно извлечь]]
• [[#Алгоритм 20. Крайний случай btrfs check --repair|Алгоритм 20. Крайний случай btrfs check --repair]]
• [[#Проверка после восстановления|Проверка после восстановления]]
• [[#Источники|Источники]]

Главные отличия Btrfs

В Btrfs нет универсального сценария:

размонтировать → запустить fsck → автоматически исправить

Основные механизмы различаются по назначению:

fsck.btrfs не выполняет полноценную проверку и лечение, аналогичные e2fsck.

Основные запреты

Не использовать btrfs check --repair первым шагом

Нельзя начинать с:

sudo btrfs check --repair <устройство>

Правильный первый шаг:

sudo btrfs check --readonly <устройство>

--repair применяется только после анализа конкретного повреждения и принятия риска потери данных.

Не запускать btrfs check на работающей ФС

Проверить:

findmnt --source <устройство_Btrfs>

Перед структурной проверкой отключить ФС:

sudo umount <точка_монтирования>

Не применять btrfs check --force на обычной работающей ФС.

Для корневой Btrfs загрузиться с установочного носителя ALT Linux в режиме восстановления или Rescue LiveCD.

Не считать scrub аналогом fsck

scrub:

• проверяет контрольные суммы данных и метаданных;
• читает всю используемую область;
• исправляет блок только при наличии другой корректной копии;
• не перестраивает повреждённые B-tree;
• запускается на смонтированной ФС.

На однодисковой Btrfs с профилем Data,single повреждённые данные обычно восстановить неоткуда.

Не запускать scrub на явно умирающем носителе

Не выполнять полный scrub, если обнаружены:

I/O error
critical medium error
SMART FAILED
Current_Pending_Sector > 0
Offline_Uncorrectable > 0
NVMe critical_warning != 0
media_errors > 0
повторяющиеся reset или timeout
исчезновение устройства

Не запускать полный balance для лечения ошибок

Не применять без конкретной причины:

sudo btrfs balance start <точка_монтирования>

Полный balance создаёт большую нагрузку, требует свободного рабочего пространства и не возвращает физически потерянные данные.

Не считать snapshot резервной копией

Snapshot Btrfs обычно использует те же физические блоки. Отказ носителя уничтожает и основную ФС, и snapshots на ней.

Когда Btrfs ремонтировать нельзя

Не выполнять изменяющие команды на исходной ФС, если обнаружено хотя бы одно состояние:

повторяющиеся I/O error
critical medium error
SMART FAILED
Current_Pending_Sector > 0
Offline_Uncorrectable > 0
NVMe critical_warning != 0
media_errors > 0
устройство периодически исчезает
контроллер постоянно сбрасывается
рост read_io_errs или write_io_errs
uncorrectable_errors после scrub
все пути Multipath потеряны
LVM partial
RAID dirty и degraded
неизвестно, смонтирован ли тот же LUN на другом хосте

В этой ситуации:

1. прекратить запись;
2. не запускать scrub, balance и btrfs check --repair;
3. отключить ФС;
4. скопировать доступные файлы либо снять образ;
5. ремонтировать только копию или исправный клон.

Алгоритм 1. Btrfs на исправном HDD

Применять для однодисковой Btrfs на HDD без физических ошибок.

1. Определить устройство

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Пример:

Диск:      /dev/sda
Btrfs:     /dev/sda2
Монтирование: /data

2. Проверить нижний уровень

journalctl -k -b --no-pager | grep -Ei \
'sda|I/O error|Buffer I/O|critical medium|reset|timeout|BTRFS'

sudo smartctl -x /dev/sda

Продолжать лечение на исходном устройстве разрешено, если:

• SMART не сообщает FAILED;
• ожидающие и неисправимые сектора отсутствуют;
• нет повторяющихся I/O-ошибок;
• диск стабильно определяется.

3. Проверить профиль Btrfs

sudo btrfs filesystem usage -T /data

sudo btrfs filesystem show /data

Особенно важны профили:

Data,single
Metadata,DUP
Data,RAID1
Metadata,RAID1

Metadata,DUP хранит две копии метаданных на одном диске, но не защищает от полного отказа диска.

4. Проверить накопленные ошибки

sudo btrfs device stats /data

Проверить поля:

write_io_errs
read_io_errs
flush_io_errs
corruption_errs
generation_errs

Ненулевые значения зафиксировать. Не сбрасывать счётчики до завершения диагностики.

5. Если ФС монтируется в rw

Сначала скопировать наиболее важные данные на другой носитель.

Затем выполнить scrub:

sudo btrfs scrub start -B /data

Проверить итог:

sudo btrfs scrub status /data

Если uncorrectable_errors = 0 и журнал не содержит новых ошибок, перейти к структурной проверке.

Если есть неисправимые ошибки, не считать ФС вылеченной. Скопировать доступные данные и вывести носитель из доверенной эксплуатации.

6. Отключить Btrfs

sudo fuser -vm /data
sudo umount /data

Проверить:

findmnt --source /dev/sda2

7. Сохранить образ метаданных

Сохранять на другой исправный носитель:

sudo btrfs-image /dev/sda2 /mnt/healthy/btrfs-sda2-before.img

btrfs-image сохраняет метаданные, но не пользовательские файлы.

8. Проверить структуру без изменений

sudo btrfs check --readonly /dev/sda2

Проверить код:

echo $?

0 означает успешное завершение. Ненулевой код означает ошибку проверки или обнаруженные проблемы.

9. Действия по результату

Если ошибок нет:

sudo mount -o ro /dev/sda2 /mnt/recovery

Проверить данные и журнал ядра, затем вернуть штатное монтирование.

Если структурные ошибки найдены, но данные читаются:

1. не применять --repair;
2. извлечь данные через read-only монтирование или btrfs restore;
3. пересоздать Btrfs на исправном носителе;
4. вернуть данные из копии.

Алгоритм 2. Btrfs на HDD с физическими ошибками

Применять при I/O-ошибках, SMART FAILED, pending/uncorrectable sectors, сбросах или исчезновении HDD.

1. Определить исходный диск

lsblk -d -o NAME,PATH,SIZE,MODEL,SERIAL

2. Немедленно прекратить запись

sudo umount <точка_монтирования>

Для корневой ФС загрузиться в Rescue LiveCD.

Не запускать на исходном диске:

btrfs scrub
btrfs balance
btrfs check --repair
badblocks
длительный SMART self-test

3. Зафиксировать состояние

sudo smartctl -x /dev/sda > /mnt/healthy/smart-sda.txt
journalctl -k -b --no-pager > /mnt/healthy/kernel-storage.txt

4. Подготовить исправный носитель

df -hT /mnt/recovery
command -v ddrescue

5. Снять первичный образ

sudo ddrescue -n \
  /dev/sda \
  /mnt/recovery/sda.img \
  /mnt/recovery/sda.map

6. Второй проход только при стабильном HDD

sudo ddrescue -d -r3 \
  /dev/sda \
  /mnt/recovery/sda.img \
  /mnt/recovery/sda.map

Не выполнять второй проход, если диск исчезает, щёлкает, перегревается или резко замедляется.

7. Отключить исходный HDD

Перед подключением копии исходный диск лучше физически отключить, чтобы ядро не видело две Btrfs с одинаковым FSID.

8. Подключить образ

sudo losetup -Pf --show /mnt/recovery/sda.img
lsblk -f /dev/loop0

9. Сначала извлечь данные

sudo mount -o ro,rescue=nologreplay /dev/loop0p2 /mnt/recovery-btrfs

Если не монтируется:

sudo btrfs restore -D /dev/loop0p2 /mnt/restored
sudo btrfs restore -s -x -m -S -i /dev/loop0p2 /mnt/restored

10. Структурную проверку выполнять только на копии

sudo btrfs check --readonly /dev/loop0p2

Исходный HDD после физических ошибок не возвращать в эксплуатацию.

Алгоритм 3. Btrfs на исправном SSD или NVMe

1. Определить устройство

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Примеры:

SATA SSD:       /dev/sda
Btrfs-раздел:   /dev/sda2
NVMe namespace: /dev/nvme0n1
Btrfs-раздел:   /dev/nvme0n1p2

2. Проверить аппаратное состояние

SATA SSD:

sudo smartctl -x /dev/sda

NVMe:

sudo smartctl -x /dev/nvme0

При наличии nvme-cli:

sudo nvme smart-log /dev/nvme0

Продолжать разрешено, если critical_warning = 0, media_errors = 0, SMART не сообщает FAILED, а журнал не содержит повторяющихся reset/timeout.

3. Проверить журнал и Btrfs

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|nvme|reset|timeout|BTRFS'

sudo btrfs device stats <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>

4. Скопировать важные данные

До полного scrub сохранить наиболее важные файлы на другой носитель.

5. Выполнить scrub

sudo btrfs scrub start -B <точка_монтирования>
sudo btrfs scrub status <точка_монтирования>

Если uncorrectable_errors > 0, прекратить эксплуатацию и копировать данные.

6. Отключить файловую систему

sudo umount <точка_монтирования>
findmnt --source <устройство_Btrfs>

7. Проверить структуру

sudo btrfs check --readonly <устройство_Btrfs>

Если ошибок нет:

sudo mount -o ro <устройство_Btrfs> /mnt/recovery

Если ошибки повторяются после scrub, скопировать данные и пересоздать ФС.

Алгоритм 4. Btrfs на отказывающем SSD или NVMe

Применять при SMART FAILED, critical_warning != 0, media_errors > 0, аппаратном read-only, I/O timeout или controller reset.

1. Определить устройство копирования

SATA SSD: /dev/sda
NVMe:     /dev/nvme0n1

2. Прекратить запись

sudo umount <точка_монтирования>

Не запускать:

scrub
balance
btrfs check --repair
fstrim
nvme device-self-test
длительный SMART self-test

3. Зафиксировать состояние

sudo smartctl -x /dev/sda > /mnt/healthy/smart-ssd.txt
sudo smartctl -x /dev/nvme0 > /mnt/healthy/smart-nvme.txt
journalctl -k -b --no-pager > /mnt/healthy/kernel-storage.txt

4. Создать образ

SATA SSD:

sudo ddrescue -n /dev/sda /mnt/recovery/ssd.img /mnt/recovery/ssd.map

NVMe:

sudo ddrescue -n /dev/nvme0n1 /mnt/recovery/nvme.img /mnt/recovery/nvme.map

Повторный проход выполнять только при стабильном устройстве:

sudo ddrescue -d -r3 <исходное_устройство> <файл_образа> <map-файл>

5. Отключить оригинал и подключить образ

sudo losetup -Pf --show <файл_образа>
lsblk -f /dev/loop0

6. Извлечь данные с копии

sudo mount -o ro,rescue=nologreplay /dev/loop0p2 /mnt/recovery-btrfs

Если не удалось:

sudo btrfs restore -D /dev/loop0p2 /mnt/restored
sudo btrfs restore -s -x -m -S -i /dev/loop0p2 /mnt/restored

Отказывающий SSD/NVMe не возвращать в эксплуатацию.

Алгоритм 5. Ошибки контрольных сумм при наличии избыточной копии

Применять, если нижний уровень исправен, журнал содержит csum failed или checksum verify failed, а профиль содержит DUP, RAID1, RAID10, RAID5 или RAID6.

1. Проверить профиль

sudo btrfs filesystem usage -T <точка_монтирования>

Data,single не является избыточным профилем.

2. Проверить устройства

sudo btrfs filesystem show <точка_монтирования>
sudo btrfs device stats <точка_монтирования>
journalctl -k -b --no-pager | grep -i BTRFS

Если есть физические I/O-ошибки, сначала заменить или скопировать носитель.

3. Скопировать критичные данные

Скопировать наиболее важные данные на независимый носитель.

4. Выполнить scrub

sudo btrfs scrub start -B <точка_монтирования>

5. Проверить результат

sudo btrfs scrub status <точка_монтирования>
sudo btrfs device stats <точка_монтирования>
journalctl -k -b -n 200 --no-pager

Если corrected_errors > 0, а uncorrectable_errors = 0, Btrfs восстановила блоки из другой копии. Причину повреждения всё равно нужно найти.

Если uncorrectable_errors > 0, восстановление из имеющихся копий не удалось. Скопировать читаемые данные и использовать резервную копию.

Алгоритм 6. Btrfs неожиданно перешла в read-only

1. Подтвердить состояние

findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONS | grep btrfs

2. Проверить журнал

journalctl -k -b --no-pager | grep -Ei \
'BTRFS|I/O error|Buffer I/O|read-only|reset|timeout'

3. Проверить нижний уровень

HDD/SSD:

sudo smartctl -x <физический_диск>

NVMe:

sudo smartctl -x /dev/nvme0

RAID:

cat /proc/mdstat
sudo mdadm --detail /dev/md0

Multipath:

sudo multipath -ll

Если есть аппаратные ошибки, не возвращать ФС в rw.

4. Скопировать данные из текущего ro

sudo rsync -aHAX --numeric-ids <точка_монтирования>/ <исправный_носитель>/

При отсутствии rsync:

sudo cp -a <точка_монтирования>/. <исправный_носитель>/

5. Отключить Btrfs

sudo fuser -vm <точка_монтирования>
sudo umount <точка_монтирования>

6. Проверить структуру

sudo btrfs check --readonly <устройство_Btrfs>

Если причина ENOSPC, использовать отдельный алгоритм ENOSPC. Если причина log replay, использовать отдельный алгоритм zero-log.

Не применять mount -o remount,rw без устранения причины.

Алгоритм 7. Btrfs не монтируется после сбоя журнала

Применять только при сообщениях open_ctree, replay, recover_log_trees, walk_log_tree или log_tree.

1. Определить устройство

lsblk -e 7 -o NAME,PATH,TYPE,FSTYPE,MOUNTPOINTS

2. Проверить нижний уровень

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|reset|timeout|BTRFS'

При физической нестабильности сначала создать образ.

3. Попытаться монтировать без replay журнала

sudo mount -o ro,rescue=nologreplay <устройство_Btrfs> /mnt/recovery

Если удалось, немедленно скопировать данные и не перемонтировать в rw.

4. Если mount не помог

sudo btrfs-image <устройство_Btrfs> /mnt/healthy/btrfs-before-zero-log.img

5. Очистить дерево журнала

sudo btrfs rescue zero-log <устройство_Btrfs>

Команда может потерять последние неподтверждённые изменения. Использовать только при подтверждённой ошибке replay/log tree.

6. Повторно подключить только для чтения

sudo mount -o ro <устройство_Btrfs> /mnt/recovery

Если данные читаются, сразу скопировать их.

Алгоритм 8. Btrfs не монтируется из-за повреждённого корня дерева

Применять при parent transid verify failed, failed to read tree root, open_ctree failed, bad tree block start без физических I/O-ошибок.

1. Убедиться, что ФС не смонтирована в rw

findmnt --source <устройство_Btrfs>

2. Сохранить метаданные

sudo btrfs-image <устройство_Btrfs> /mnt/healthy/btrfs-before-backup-root.img

3. Проверить резервные корни

sudo btrfs check --readonly --backup <устройство_Btrfs>

4. Попытаться mount с резервным корнем

sudo mount -o ro,rescue=usebackuproot,nologreplay <устройство_Btrfs> /mnt/recovery

Если удалось, скопировать данные. Резервный корень может отражать более раннее состояние ФС.

5. Если mount не работает

sudo btrfs restore -l <устройство_Btrfs>
sudo btrfs restore -D <устройство_Btrfs> /mnt/restored
sudo btrfs restore -s -x -m -S -i <устройство_Btrfs> /mnt/restored

Алгоритм 9. Повреждены суперблоки Btrfs

Применять при bad superblock, no valid Btrfs found, superblock checksum mismatch, cannot read superblock.

1. Проверить правильность устройства

lsblk -e 7 -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS

Использовать карту Multipath, LV или /dev/md*, если Btrfs находится на соответствующем уровне.

2. Проверить физическое состояние

journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|reset|timeout'

При аппаратных ошибках сначала создать образ.

3. Проверить копии суперблока

sudo btrfs inspect-internal dump-super -a <устройство_Btrfs>

Сохранить вывод:

sudo btrfs inspect-internal dump-super -a <устройство_Btrfs> > /mnt/healthy/btrfs-superblocks.txt

4. Сохранить метаданные

sudo btrfs-image <устройство_Btrfs> /mnt/healthy/btrfs-before-super-recover.img

5. Восстановить суперблок из исправной копии

sudo btrfs rescue super-recover <устройство_Btrfs>

Не добавлять -y при первом запуске.

6. Проверить результат

sudo btrfs check --readonly <устройство_Btrfs>
sudo mount -o ro,rescue=nologreplay <устройство_Btrfs> /mnt/recovery

Если данные читаются, скопировать их до дальнейшей эксплуатации.

Алгоритм 10. Повреждено дерево чанков

Применять при cannot read chunk root, failed to read chunk tree, chunk tree corrupted, logical address cannot be mapped.

1. Не запускать на исходном отказывающем устройстве

chunk-recover сканирует устройство целиком и может работать очень долго. При ошибках носителя сначала создать посекторную копию.

2. Убедиться, что нет balance или replace

sudo btrfs balance status <точка_монтирования>
sudo btrfs replace status -1 <точка_монтирования>

3. Работать с исправной копией

sudo btrfs rescue chunk-recover <копия_устройства>

Не применять -y без просмотра изменений.

4. Проверить структуру

sudo btrfs check --readonly <копия_устройства>

5. Попытаться извлечь данные

sudo mount -o ro,rescue=nologreplay <копия_устройства> /mnt/recovery

Если mount не работает:

sudo btrfs restore -s -x -m -S -i <копия_устройства> /mnt/restored

Алгоритм 11. Btrfs заполнена и возвращает ENOSPC

Btrfs может вернуть No space left on device, даже если обычный df показывает свободное место.

1. Проверить фактическое использование

sudo btrfs filesystem usage -T <точка_монтирования>
sudo btrfs device usage <точка_монтирования>
df -hT <точка_монтирования>

2. Проверить журнал

journalctl -k -b --no-pager | grep -Ei 'BTRFS|ENOSPC|No space left|read-only'

3. Проверить snapshots и subvolume

sudo btrfs subvolume list <точка_монтирования>
sudo btrfs subvolume list -s <точка_монтирования>

4. Удалить только подтверждённо ненужные данные

Удалить обычные файлы или ненужный snapshot:

sudo btrfs subvolume delete <путь_к_snapshot>
sync

5. Освободить пустые block group

sudo btrfs balance start -dusage=0 -musage=0 <точка_монтирования>

6. Если места всё ещё недостаточно

sudo btrfs balance start -dusage=10 <точка_монтирования>
sudo btrfs balance start -musage=10 <точка_монтирования>

Проверить:

sudo btrfs balance status <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>

Не запускать полный balance.

Если ФС уже стала read-only и не позволяет удалять данные, сначала скопировать данные, затем работать из Rescue-среды или пересоздать ФС.

Алгоритм 12. Собственный многодисковый массив Btrfs исправен, но содержит ошибки

1. Определить участников и профили

sudo btrfs filesystem show <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>
lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Профили данных и метаданных проверяются отдельно.

2. Проверить каждый физический носитель

sudo smartctl -x /dev/sda
sudo smartctl -x /dev/sdb

Для NVMe:

sudo smartctl -x /dev/nvme0

3. Проверить ошибки Btrfs

sudo btrfs device stats <точка_монтирования>
journalctl -k -b --no-pager | grep -i BTRFS

4. Скопировать важные данные

Перед scrub создать внешнюю копию наиболее важных данных.

5. Выполнить scrub всего массива

sudo btrfs scrub start -B <точка_монтирования>
sudo btrfs scrub status <точка_монтирования>

6. Оценить результат

Если corrected_errors > 0, а uncorrectable_errors = 0, найти источник повреждения и заменить подозрительный носитель.

Если uncorrectable_errors > 0, избыточность не смогла восстановить данные. Не выполнять balance до выяснения состояния всех участников.

7. Структурная проверка

После копирования данных и отключения массива:

sudo btrfs check --readonly <один_из_участников_Btrfs>

btrfs check обнаруживает остальные устройства одной Btrfs, если они доступны системе.

Алгоритм 13. Отказал участник собственного массива Btrfs

1. Определить профиль и допустимость деградации

sudo btrfs filesystem show <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>

Проверить отдельно профили Data, Metadata и System.

Если данные имеют профиль single или RAID0, потеря устройства может означать потерю части данных.

2. Если ФС ещё смонтирована

Сразу скопировать важные данные.

sudo btrfs device stats <точка_монтирования>
sudo btrfs scrub status <точка_монтирования>

Не запускать новый scrub на явно умирающем участнике.

3. Подготовить новый носитель

lsblk -d -o NAME,PATH,SIZE,MODEL,SERIAL

Новый носитель должен быть не меньше заменяемого.

4. Заменить доступный участник

sudo btrfs replace start -B <старое_устройство> <новое_устройство> <точка_монтирования>

Если старый диск создаёт много ошибок и зеркала доступны:

sudo btrfs replace start -B -r <старое_устройство> <новое_устройство> <точка_монтирования>

5. Если устройство отсутствует

Определить devid:

sudo btrfs filesystem show <точка_монтирования>

Запустить замену:

sudo btrfs replace start -B <devid> <новое_устройство> <точка_монтирования>

Восстановление возможно только при достаточной избыточности.

6. Проверить статус

sudo btrfs replace status -1 <точка_монтирования>
sudo btrfs filesystem show <точка_монтирования>
sudo btrfs device stats <точка_монтирования>

7. Если ФС не монтируется без участника

sudo mount -o ro,degraded,rescue=nologreplay <доступный_участник> /mnt/recovery

Если удалось, сначала скопировать данные.

Не удалять отсутствующий участник командой btrfs device delete missing, пока данные не сохранены и не подтверждена достаточная избыточность.

8. Ограничение RAID5/RAID6

При native RAID5/6, деградации и нештатном выключении:

• не запускать полный balance;
• не выполнять слепой replace;
• не применять btrfs check --repair;
• сначала создать резервную копию или образы участников;
• при критичных данных передать анализ специалисту по Btrfs.

Алгоритм 14. Btrfs поверх Linux Software RAID

1. Определить структуру

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS
cat /proc/mdstat
sudo mdadm --detail /dev/md0

Правильная цель Btrfs:

/dev/md0

либо LV поверх /dev/md0.

Нельзя запускать Btrfs-инструменты на отдельных участниках mdraid.

2. Определить допустимость лечения

Продолжать разрешено, если массив активен, допустимое число участников присутствует, нет dirty degraded и физических I/O-ошибок.

3. Если RAID деградирован

1. скопировать важные данные;
2. заменить неисправный участник mdraid;
3. дождаться recovery/resync;
4. проверить /proc/mdstat;
5. только после стабилизации работать с Btrfs.

4. Проверить Btrfs

sudo btrfs device stats <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>
sudo btrfs scrub start -B <точка_монтирования>

5. Отключить и проверить структуру

sudo umount <точка_монтирования>
sudo btrfs check --readonly /dev/md0

Если Btrfs находится на LV поверх mdraid, использовать LV.

Алгоритм 15. Btrfs поверх LVM

1. Определить уровни

lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS
sudo pvs
sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent,devices

Правильная цель:

/dev/mapper/<VG>-<LV>

2. Проверить полный состав LVM

Убедиться, что все PV присутствуют, VG/LV не partial, thin pool не заполнен, а нижний уровень стабилен.

Критично:

Data% = 100
Meta% = 100

Переполненный LVM thin pool не лечится средствами Btrfs.

3. Если LVM partial

Не запускать scrub, balance и btrfs check --repair. Сначала восстановить отсутствующий PV или путь.

4. Сохранить конфигурацию LVM

sudo vgcfgbackup -f /mnt/healthy/<VG>-before.conf <VG>

5. Проверить Btrfs на полном LV

sudo btrfs device stats <точка_монтирования>
sudo btrfs scrub start -B <точка_монтирования>
sudo umount <точка_монтирования>
sudo btrfs check --readonly /dev/mapper/<VG>-<LV>

Не создавать LVM snapshot для аварийного лечения без понимания duplicate FSID и свободного места snapshot pool.

Алгоритм 16. Btrfs поверх Multipath или SAN LUN

1. Определить карту Multipath

sudo multipath -ll
lsblk -e 7 -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Правильная цель:

/dev/mapper/mpatha
/dev/mapper/<WWID>

либо LV поверх карты Multipath.

Нельзя использовать отдельные пути /dev/sda, /dev/sdb.

2. Проверить все пути

systemctl is-active multipathd
sudo multipath -ll

Проблемные состояния:

failed
faulty
offline
all paths down
no usable paths

3. Проверить исключительное владение LUN

Btrfs не является кластерной ФС для одновременного обычного rw-монтирования несколькими хостами.

4. Проверить SAN

Если все пути потеряны, Btrfs не ремонтировать.

5. Скопировать данные

Если LUN доступен и Btrfs монтируется, сначала скопировать критичные данные.

6. Проверить Btrfs только через карту

sudo btrfs device stats <точка_монтирования>
sudo btrfs scrub start -B <точка_монтирования>
sudo umount <точка_монтирования>
sudo btrfs check --readonly <карта_или_LV>

7. Контроль

sudo multipath -ll
journalctl -k -b --no-pager | grep -Ei 'multipath|scsi|timeout|offline|I/O error|BTRFS'

Алгоритм 17. Каталог подключён по NFS

NFS-клиент не видит локальное блочное устройство и не может лечить Btrfs сервера.

1. Подтвердить NFS

findmnt --target <каталог>

2. Не запускать локальные Btrfs-инструменты

На клиенте нельзя выполнять btrfs check, scrub или rescue для NFS-каталога.

3. Проверить доступность

ls -la <каталог>
df -hT <каталог>
journalctl -k -b --no-pager | grep -Ei 'nfs|server not responding|stale file handle|I/O error'

4. Если данные читаются

sudo rsync -aHAX --numeric-ids <каталог>/ <локальный_исправный_носитель>/

5. Если NFS возвращает ошибки

6. Восстановление на сервере

Администратор сервера должен остановить запись клиентов, определить нижний уровень, скопировать данные и выполнить подходящий серверный алгоритм Btrfs.

Алгоритм 18. Каталог подключён по SMB или DFS

1. Подтвердить CIFS

findmnt --target <каталог>

2. Не применять Btrfs-инструменты на клиенте

Клиент не знает, какая ФС находится на сервере.

3. Проверить доступность

ls -la <каталог>
df -hT <каталог>
journalctl -k -b --no-pager | grep -Ei 'CIFS|SMB|DFS|reconnect|server|I/O error'

4. Если данные читаются

sudo rsync -aHAX <каталог>/ <локальный_исправный_носитель>/

5. Если DFS или SMB недоступны

Если конечный сервер хранит ресурс на Btrfs, лечение выполняется только на самом сервере после остановки SMB-доступа.

Алгоритм 19. Файловая система не ремонтируется, но данные ещё можно извлечь

Применять, если Btrfs не монтируется, btrfs check --readonly сообщает серьёзные ошибки, rescue mount не работает или данные важнее восстановления ФС.

1. Работать с копией

При физической нестабильности создать образ через ddrescue.

При исправном носителе сохранить метаданные:

sudo btrfs-image <устройство_Btrfs> /mnt/healthy/btrfs-metadata.img

2. Просмотреть доступные корни subvolume

sudo btrfs restore -l <устройство_или_копия>

3. Выполнить пробный проход

sudo btrfs restore -D <устройство_или_копия> /mnt/restored

4. Извлечь данные

sudo btrfs restore -s -x -m -S -i <устройство_или_копия> /mnt/restored

5. Извлечь конкретный subvolume

sudo btrfs restore -l <устройство_или_копия>
sudo btrfs restore -r <rootid> -x -m -S -i <устройство_или_копия> /mnt/restored

6. Проверить результат

Проверить размер и открытие файлов, контрольные суммы, базы данных средствами приложения, ACL и владельцев.

btrfs restore может извлечь старую или неполную версию файла, если актуальные метаданные повреждены.

Алгоритм 20. Крайний случай btrfs check --repair

Применять только если одновременно выполнены условия:

1. физический носитель исправен либо создан полный образ;
2. работа выполняется на копии;
3. важные данные уже извлечены;
4. read-only mount и btrfs restore не дали результата;
5. тип повреждения подтверждён выводом btrfs check;
6. получена рекомендация разработчика Btrfs или опытного специалиста;
7. допустима окончательная потеря структуры ФС.

1. Зафиксировать состояние копии

sudo btrfs check --readonly <копия_Btrfs> > /mnt/healthy/btrfs-check-before.txt 2>&1

2. Убедиться, что копия не смонтирована

findmnt --source <копия_Btrfs>

3. Запустить repair только на копии

sudo btrfs check --repair <копия_Btrfs>

Не использовать без отдельной точной рекомендации:

--init-csum-tree
--init-extent-tree
--force

4. Проверить результат

sudo btrfs check --readonly <копия_Btrfs>
sudo mount -o ro,rescue=nologreplay <копия_Btrfs> /mnt/recovery

Даже если mount заработал, сначала скопировать данные. Не считать аварийно отремонтированную копию надёжной рабочей ФС.

Проверка после восстановления

1. Проверить нижний уровень

HDD/SSD:

sudo smartctl -x <диск>

NVMe:

sudo smartctl -x /dev/nvme0

RAID:

cat /proc/mdstat
sudo mdadm --detail /dev/md0

Multipath:

sudo multipath -ll

LVM:

sudo pvs
sudo vgs
sudo lvs -a -o +devices

2. Проверить Btrfs

sudo btrfs filesystem show <точка_монтирования>
sudo btrfs filesystem usage -T <точка_монтирования>
sudo btrfs device stats <точка_монтирования>

3. Выполнить scrub только на стабильном носителе

sudo btrfs scrub start -B <точка_монтирования>
sudo btrfs scrub status <точка_монтирования>

Ожидается:

uncorrectable_errors = 0

4. Проверить журнал

journalctl -k -b -n 300 --no-pager

Не должно появляться новых:

BTRFS error
I/O error
csum failed
parent transid verify failed
forced readonly
open_ctree failed

5. Проверить данные

Проверить основные каталоги, snapshots, subvolume, права, критичные документы, архивы и базы данных средствами приложений.

Исправная структура Btrfs не гарантирует логическую целостность содержимого файла.

6. Решить судьбу ФС

ФС следует пересоздать и восстановить из копии, если:

• была серьёзная структурная порча;
• применялся btrfs check --repair;
• использовался chunk-recover;
• есть неисправимые checksum errors;
• ошибки возвращаются после scrub;
• нижний носитель проявлял физическую деградацию.

Источники

• Пакет btrfs-progs в ALT Linux p10
• Официальная документация Btrfs
• btrfs-check(8)
• btrfs-scrub(8)
• btrfs-rescue(8)
• btrfs-restore(8)
• btrfs-device(8)
• btrfs-replace(8)
• Опции монтирования Btrfs
• Balance и ENOSPC
• Auto-repair on read
• GNU ddrescue