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

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

Заметка содержит отдельные самодостаточные алгоритмы для XFS на HDD, SSD/NVMe, Linux Software RAID, LVM, Multipath/SAN LUN, NFS и SMB/DFS.

Для ALT Linux 10.4 используется пакет xfsprogs ветки p10. Проверить фактические версии:

xfs_repair -V
uname -r

Оглавление

• [[#Главные особенности восстановления XFS|Главные особенности восстановления XFS]]
• [[#Основные запреты|Основные запреты]]
• [[#Коды завершения xfs_repair|Коды завершения xfs_repair]]
• [[#Когда XFS ремонтировать нельзя|Когда XFS ремонтировать нельзя]]
• [[#Алгоритм 1. XFS на исправном HDD|Алгоритм 1. XFS на исправном HDD]]
• [[#Алгоритм 2. XFS на HDD с физическими ошибками|Алгоритм 2. XFS на HDD с физическими ошибками]]
• [[#Алгоритм 3. XFS на исправном SSD или NVMe|Алгоритм 3. XFS на исправном SSD или NVMe]]
• [[#Алгоритм 4. XFS на отказывающем SSD или NVMe|Алгоритм 4. XFS на отказывающем SSD или NVMe]]
• [[#Алгоритм 5. XFS выполнила filesystem shutdown|Алгоритм 5. XFS выполнила filesystem shutdown]]
• [[#Алгоритм 6. XFS содержит dirty log|Алгоритм 6. XFS содержит dirty log]]
• [[#Алгоритм 7. Журнал невозможно воспроизвести и требуется xfs_repair -L|Алгоритм 7. Журнал невозможно воспроизвести и требуется xfs_repair -L]]
• [[#Алгоритм 8. XFS не монтируется из-за повреждения метаданных|Алгоритм 8. XFS не монтируется из-за повреждения метаданных]]
• [[#Алгоритм 9. Повреждён основной суперблок XFS|Алгоритм 9. Повреждён основной суперблок XFS]]
• [[#Алгоритм 10. XFS заполнена и приложения не могут писать|Алгоритм 10. XFS заполнена и приложения не могут писать]]
• [[#Алгоритм 11. XFS использует внешний журнал или realtime-устройство|Алгоритм 11. XFS использует внешний журнал или realtime-устройство]]
• [[#Алгоритм 12. XFS поверх Linux Software RAID|Алгоритм 12. XFS поверх Linux Software RAID]]
• [[#Алгоритм 13. XFS поверх LVM|Алгоритм 13. XFS поверх LVM]]
• [[#Алгоритм 14. XFS поверх Multipath или SAN LUN|Алгоритм 14. XFS поверх Multipath или SAN LUN]]
• [[#Алгоритм 15. Каталог подключён по NFS|Алгоритм 15. Каталог подключён по NFS]]
• [[#Алгоритм 16. Каталог подключён по SMB или DFS|Алгоритм 16. Каталог подключён по SMB или DFS]]
• [[#Алгоритм 17. xfs_repair не может завершить восстановление|Алгоритм 17. xfs_repair не может завершить восстановление]]
• [[#Алгоритм 18. XFS ремонтировать не стоит, но данные ещё читаются|Алгоритм 18. XFS ремонтировать не стоит, но данные ещё читаются]]
• [[#Проверка после восстановления|Проверка после восстановления]]
• [[#Источники|Источники]]

Главные особенности восстановления XFS

В XFS нет рабочего аналога команды fsck -y.

fsck.xfs обычно ничего не ремонтирует и существует главным образом для совместимости с общим механизмом fsck.

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

Не запускать xfs_repair на смонтированной XFS

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

Отключить:

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

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

Не использовать как штатный полевой метод:

xfs_repair -d

Параметр -d допускает опасный ремонт read-only смонтированной корневой ФС. Нормальный путь: Rescue-среда и отключённое устройство.

Не запускать xfs_repair -L первым

sudo xfs_repair -L <устройство_XFS>

Команда удаляет журнал XFS. Возможны потеря последних изменений метаданных, недавних файлов, каталогов, переименований и перемещений, появление объектов в lost+found и очистка повреждённых inode.

Не ремонтировать XFS поверх нестабильного нижнего уровня

Сначала проверяются HDD/SSD, NVMe, RAID, LVM, Multipath, SAN LUN, внешний журнал XFS и realtime-устройство.

Не запускать xfs_repair на неправильном уровне

Нельзя использовать целый диск вместо раздела, отдельный компонент RAID, PV LVM, отдельный SCSI-путь Multipath, NFS или DFS-каталог.

Правильная цель имеет FSTYPE=xfs:

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

Не считать xfs_repair -n абсолютно точным

Режим -n не изменяет ФС, но может не обнаружить некоторые тонкие ошибки карт свободного места и inode и повторять одни предупреждения, поскольку не исправляет их по ходу проверки.

Коды завершения xfs_repair

После команды:

echo $?

Для xfs_repair -n

Для обычного xfs_repair

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

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

I/O error
Buffer I/O error
critical medium error
SMART FAILED
Current_Pending_Sector > 0
Offline_Uncorrectable > 0
NVMe critical_warning != 0
media_errors > 0
устройство периодически исчезает
повторяются reset или timeout
RAID dirty и degraded
RAID потерял больше устройств, чем допускает уровень
LVM partial
Multipath потерял все пути
неизвестно, используется ли тот же LUN другим хостом
повреждено или недоступно внешнее logdev/rtdev

В этих условиях:

1. прекратить запись;
2. отключить файловую систему;
3. скопировать читаемые файлы либо создать посекторный образ;
4. ремонтировать только копию или исправный клон;
5. заменить физически неисправный носитель.

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

Применять для локальной XFS на HDD без аппаратных ошибок.

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

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

Пример:

Диск: /dev/sda
XFS:  /dev/sda2
Точка: /data

2. Сохранить геометрию XFS

sudo xfs_info /data
sudo xfs_info /data > /mnt/healthy/xfs-info-before.txt

Проверить, нет ли отдельного журнала или realtime-раздела.

3. Проверить ядро и SMART

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

sudo smartctl -x /dev/sda

Продолжать разрешено, если SMART не сообщает FAILED, pending/uncorrectable sectors отсутствуют и диск стабилен.

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

sudo rsync -aHAX --numeric-ids /data/ /mnt/healthy/data-copy/

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

sudo cp -a /data/. /mnt/healthy/data-copy/

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

sudo fuser -vm /data
sudo umount /data
findmnt --source /dev/sda2

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

sudo xfs_metadump /dev/sda2 /mnt/healthy/xfs-sda2-before.metadump

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

7. Проверить без изменений

sudo xfs_repair -n /dev/sda2

При коде 2 использовать алгоритм dirty log. При I/O-ошибках прекратить ремонт и создавать образ.

8. Выполнить восстановление

sudo xfs_repair /dev/sda2

Не использовать -L, если dirty log не подтверждён и обычный replay не исчерпан.

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

sudo xfs_repair -n /dev/sda2
sudo mount -o ro /dev/sda2 /mnt/recovery
ls -la /mnt/recovery
ls -la /mnt/recovery/lost+found
journalctl -k -b -n 200 --no-pager
sudo umount /mnt/recovery

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

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

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

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

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

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

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

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

xfs_repair
xfs_scrub
xfs_copy
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

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

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

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

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

7. Сначала прочитать данные

sudo mount -o ro,norecovery /dev/loop0p2 /mnt/recovery-xfs

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

8. Ремонтировать только копию

sudo xfs_repair -n /dev/loop0p2

При dirty log выполнить replay на копии через mount/unmount. Затем:

sudo xfs_repair /dev/loop0p2

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

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

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

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

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

SATA SSD:

sudo smartctl -x /dev/sda

NVMe:

sudo smartctl -x /dev/nvme0

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

sudo nvme smart-log /dev/nvme0

Продолжать разрешено, если SMART не сообщает FAILED, critical_warning=0, media_errors=0 и контроллер не сбрасывается.

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

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

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

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

5. Дополнительная онлайн-проверка

command -v xfs_scrub
sudo xfs_scrub -n <точка_монтирования>

-n запрещает исправления. Если ядро не поддерживает scrub, перейти к офлайн-проверке.

6. Отключить XFS и сохранить metadump

sudo umount <точка_монтирования>
findmnt --source <устройство_XFS>
sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-before.metadump

7. Проверить и восстановить

sudo xfs_repair -n <устройство_XFS>
sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>

8. Проверить чтение

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

При повторном shutdown или новых I/O-ошибках SSD/NVMe вывести из эксплуатации.

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

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

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

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

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

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

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

xfs_repair
xfs_scrub
xfs_copy
fstrim
nvme device-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:

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

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

5. Работать с образом

sudo losetup -Pf --show <файл_образа>
lsblk -f /dev/loop0
sudo mount -o ro,norecovery /dev/loop0p2 /mnt/recovery-xfs

Сначала копировать данные, затем ремонтировать копию.

Алгоритм 5. XFS выполнила filesystem shutdown

Типовые сообщения:

XFS ... Corruption detected
XFS ... metadata I/O error
XFS ... Log I/O Error
XFS ... Filesystem has been shut down
Please unmount the filesystem and rectify the problem

1. Не возвращать запись перемонтированием

Не выполнять:

mount -o remount,rw <точка_монтирования>

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

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

Проверить HDD/SSD, NVMe, RAID, LVM или Multipath по фактической схеме.

3. Если файлы ещё читаются

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

При зависаниях или I/O-ошибках прекратить массовое чтение и создавать образ.

4. Отключить XFS

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

5. При стабильном носителе

sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-shutdown-before.metadump
sudo xfs_repair -n <устройство_XFS>
sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>

Если shutdown повторяется, переносить данные на новую ФС.

Алгоритм 6. XFS содержит dirty log

Признак: xfs_repair возвращает код 2 и сообщает о ценных изменениях метаданных в журнале.

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

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

Не воспроизводить журнал на нестабильном устройстве.

2. Использовать тот же компьютер или ту же CPU-архитектуру

Dirty log воспроизводится ядром при монтировании.

3. Выполнить replay

sudo mkdir -p /mnt/xfs-replay
sudo mount <устройство_XFS> /mnt/xfs-replay
sudo umount /mnt/xfs-replay

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

4. Проверить и восстановить

sudo xfs_repair -n <устройство_XFS>
sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>

Если mount для replay невозможен, использовать отдельный алгоритм -L, а не перескакивать к нему вслепую.

Алгоритм 7. Журнал невозможно воспроизвести и требуется xfs_repair -L

Применять только если dirty log подтверждён, нижний уровень стабилен или используется копия, обычный mount для replay не работает, данные скопированы насколько возможно и создан metadump/образ.

1. Попытаться прочитать без replay

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

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

2. Сохранить metadump

sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-before-log-zero.metadump

3. Зафиксировать no-modify вывод

sudo xfs_repair -n <устройство_XFS> \
  > /mnt/healthy/xfs-repair-n-before-L.txt 2>&1

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

sudo xfs_repair -L <устройство_XFS>

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

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

После -L проверить базы, виртуальные диски, архивы, файлы приложений и lost+found. ФС не считать единственным надёжным экземпляром данных.

Алгоритм 8. XFS не монтируется из-за повреждения метаданных

Признаки:

Metadata corruption detected
bad magic number
bad inode
bad extent
corrupt btree
Structure needs cleaning
EFSCORRUPTED

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

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

2. Проверить отсутствие монтирования и сохранить metadump

findmnt --source <устройство_XFS>
sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-corruption-before.metadump

3. Выполнить no-modify проверку

sudo xfs_repair -n <устройство_XFS>

Особенно опасные предполагаемые действия:

cleared inode
junking entry
clearing attr fork
moving to lost+found

Они означают возможную потерю inode, имён, ссылок или extended attributes.

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

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

5. Выполнить ремонт и проверить

sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>
sudo mount -o ro <устройство_XFS> /mnt/recovery
ls -la /mnt/recovery/lost+found

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

XFS хранит вторичные суперблоки в allocation group. xfs_repair умеет искать валидные копии и восстанавливать основной суперблок.

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

lsblk -e 7 -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS
journalctl -k -b --no-pager | grep -Ei \
'I/O error|Buffer I/O|critical medium|reset|timeout'

При I/O-ошибках сначала создавать образ.

2. Убедиться, что XFS отключена

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

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

sudo xfs_db -r -c 'sb 0' -c 'p' <устройство_XFS>

Не использовать xfs_db -x.

4. Сохранить metadump и выполнить ремонт

sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-super-before.metadump
sudo xfs_repair -n <устройство_XFS>
sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>

Если валидные суперблоки не находятся, прекратить низкоуровневые эксперименты и передать образ/metadump специалисту по XFS.

Алгоритм 10. XFS заполнена и приложения не могут писать

Признаки:

No space left on device
ENOSPC
Disk quota exceeded
EDQUOT

1. Проверить объём, inode и квоты

df -hT <точка_монтирования>
df -ih <точка_монтирования>
sudo xfs_quota -x -c 'state' <точка_монтирования>
sudo xfs_quota -x -c 'report -h' <точка_монтирования>

2. Найти крупные каталоги и открытые удалённые файлы

sudo du -xhd1 <точка_монтирования> | sort -h
sudo lsof +L1

3. Освободить место

Удалять только подтверждённо ненужные журналы, временные файлы, кэш, старые резервные копии и дампы.

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

sync
df -hT <точка_монтирования>
df -ih <точка_монтирования>

Если XFS выполнила shutdown, после освобождения места использовать алгоритм filesystem shutdown.

Алгоритм 11. XFS использует внешний журнал или realtime-устройство

1. Зафиксировать геометрию

sudo xfs_info <точка_монтирования>
sudo xfs_info <точка_монтирования> > /mnt/healthy/xfs-info-external.txt

Определить:

DATADEV=<устройство_данных>
LOGDEV=<внешний_журнал>
RTDEV=<realtime_устройство>

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

Если внешний журнал или realtime-устройство недоступны, не запускать xfs_repair только с data device.

3. Отключить XFS

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

4. Сохранить metadump

С внешним журналом:

sudo xfs_metadump -l "$LOGDEV" "$DATADEV" /mnt/healthy/xfs-external-before.metadump

С realtime-устройством добавить -r "$RTDEV".

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

sudo xfs_repair -n -l "$LOGDEV" -r "$RTDEV" "$DATADEV"
sudo xfs_repair -l "$LOGDEV" -r "$RTDEV" "$DATADEV"
sudo xfs_repair -n -l "$LOGDEV" -r "$RTDEV" "$DATADEV"

Указывать только реально существующие дополнительные устройства. При потере внешнего журнала не применять -L без полного образа и понимания последствий.

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

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

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

Правильная цель: /dev/md0 либо LV поверх него. Не использовать отдельные члены массива.

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

Ремонт разрешён, если mdraid активен, нет dirty degraded, допустимое число участников доступно и нет I/O-ошибок членов массива.

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

Для RAID1/10: скопировать данные, заменить участник, дождаться recovery и только затем ремонтировать XFS.

Для RAID5/6 в состоянии dirty degraded: не запускать xfs_repair, не собирать с --force, сначала получить стабильное логическое устройство или образ.

4. Отключить XFS и сохранить состояние

sudo umount <точка_монтирования>
cat /proc/mdstat > /mnt/healthy/mdstat-before.txt
sudo mdadm --detail /dev/md0 > /mnt/healthy/md0-before.txt
sudo xfs_metadump <устройство_XFS> /mnt/healthy/xfs-mdraid-before.metadump

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

sudo xfs_repair -n <устройство_XFS>
sudo xfs_repair <устройство_XFS>
sudo xfs_repair -n <устройство_XFS>
cat /proc/mdstat
sudo mdadm --detail /dev/md0

Алгоритм 13. XFS поверх 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. Проверить нижний уровень

Все PV должны присутствовать, VG/LV не должны быть partial, thin pool не должен иметь Data%=100 или Meta%=100.

При LVM partial xfs_repair не запускать.

3. Сохранить конфигурацию и данные

sudo vgcfgbackup -f /mnt/healthy/<VG>-before.conf <VG>
sudo rsync -aHAX --numeric-ids \
  <точка_монтирования>/ \
  <исправный_носитель>/

4. Отключить и восстановить

sudo umount <точка_монтирования>
sudo xfs_metadump /dev/mapper/<VG>-<LV> /mnt/healthy/xfs-lvm-before.metadump
sudo xfs_repair -n /dev/mapper/<VG>-<LV>

При dirty log:

sudo mount /dev/mapper/<VG>-<LV> /mnt/replay
sudo umount /mnt/replay

Затем:

sudo xfs_repair /dev/mapper/<VG>-<LV>
sudo xfs_repair -n /dev/mapper/<VG>-<LV>

Алгоритм 14. XFS поверх 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 поверх карты. Отдельные /dev/sdX могут быть путями одного LUN.

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

systemctl is-active multipathd
sudo multipath -ll

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

3. Проверить владельца LUN

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

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

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

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

6. Сохранить состояние и восстановить

sudo multipath -ll > /mnt/healthy/multipath-before.txt
sudo xfs_metadump <карта_или_LV> /mnt/healthy/xfs-san-before.metadump
sudo xfs_repair -n <карта_или_LV>
sudo xfs_repair <карта_или_LV>
sudo xfs_repair -n <карта_или_LV>
sudo multipath -ll

journalctl -k -b --no-pager | grep -Ei \
'multipath|scsi|timeout|offline|I/O error|XFS'

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

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

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

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

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

Нельзя выполнять xfs_repair, xfs_scrub, xfs_metadump или xfs_db для 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. Если ресурс недоступен

Ремонт выполняется на сервере после остановки клиентов, экспорта и приложений.

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

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

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

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

Клиент не определяет серверную ФС. На сервере может быть XFS, ext4, Btrfs, NTFS, ReFS или кластерная ФС.

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. Если SMB или DFS недоступны

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

Алгоритм 17. xfs_repair не может завершить восстановление

1. Прекратить повторные циклы

Не запускать многократно xfs_repair -L.

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

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

Проверить HDD/SSD, NVMe, RAID, LVM, Multipath, внешний журнал и realtime-устройство.

3. Создать полный образ

sudo ddrescue -n \
  <исходное_устройство> \
  /mnt/recovery/xfs.img \
  /mnt/recovery/xfs.map

4. Создать metadump и сохранить вывод

sudo xfs_metadump <копия_XFS> /mnt/healthy/xfs-failed.metadump
sudo xfs_repair -n <копия_XFS> \
  > /mnt/healthy/xfs-repair-failed.txt 2>&1

5. Восстановить metadump в тестовый файл

sudo xfs_mdrestore \
  /mnt/healthy/xfs-failed.metadump \
  /mnt/healthy/xfs-metadata-test.img

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

6. Передать материалы

Нужны версия xfsprogs, версия ядра, metadump, вывод xfs_repair -n, xfs_info, журнал ядра и схема нижнего уровня.

Алгоритм 18. XFS ремонтировать не стоит, но данные ещё читаются

Применять, если носитель деградирует, xfs_repair -n планирует удалять множество inode, ожидается большой lost+found, либо важнее сохранить текущую структуру файлов.

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

Остановить приложения. При возможности:

sudo mount -o remount,ro <точка_монтирования>

2. Копировать приоритетные данные

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

При ошибках отдельных файлов:

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

3. При нестабильном носителе создать образ

sudo ddrescue -n \
  <исходное_устройство> \
  /mnt/recovery/xfs.img \
  /mnt/recovery/xfs.map

4. Не использовать xfs_copy на умирающем носителе

xfs_copy прекращает работу при ошибке чтения источника. На полностью исправной отключённой XFS можно использовать:

sudo xfs_copy <устройство_XFS> <целевое_устройство_или_файл>

xfs_copy не поддерживает XFS с realtime-разделом или внешним журналом.

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

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

6. Пересоздать файловую систему

После успешного копирования заменить неисправный носитель, создать новую XFS, вернуть данные и проверить приложения.

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

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

HDD/SSD: smartctl
NVMe: smartctl или nvme smart-log
RAID: /proc/mdstat и mdadm --detail
LVM: pvs, vgs, lvs
Multipath: multipath -ll

2. Выполнить no-modify проверку

sudo xfs_repair -n <устройство_XFS>

Ожидается код 0.

3. Подключить только для чтения

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

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

Проверить основные каталоги, lost+found, права, владельцев, ACL, extended attributes, базы, виртуальные диски, архивы и журналы приложений.

xfs_repair восстанавливает согласованность метаданных, но не гарантирует логическую целостность содержимого файлов.

5. Проверить квоты

sudo xfs_quota -x -c 'state' /mnt/recovery

После xfs_repair сведения об использовании квот могут пересчитываться. Лимиты проверить отдельно.

6. Проверить ядро

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

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

XFS ... Corruption detected
metadata I/O error
Log I/O Error
Filesystem has been shut down
I/O error

7. Вернуть в работу

sudo umount /mnt/recovery
sudo mount <штатная_точка>
findmnt --target <штатная_точка>
df -hT <штатная_точка>

После xfs_repair -L, массового удаления inode или повторяющегося shutdown данные необходимо перенести на новую ФС даже при успешном монтировании.

Источники

• Пакет xfsprogs в ALT Linux p10
• Документация ALT Linux 10.4: первая помощь и Rescue-режим
• Документация ядра Linux: XFS
• xfs_repair(8)
• xfs_scrub(8)
• xfs_metadump(8)
• xfs_mdrestore(8)
• xfs_copy(8)
• xfs_db(8)
• xfs_logprint(8)
• GNU ddrescue