🐧 Как проверить и восстановить файловую систему XFS на RHEL

Команда xfs_repair восстанавливает поврежденные или поврежденные файловые системы XFS.

Она отличается высокой масштабируемостью, производительностью и предназначена для эффективного восстановления даже очень больших файловых систем с большим количеством inodes.

В отличие от других файловых систем Linux, xfs_repair не запускается во время загрузки, даже если файловая система XFS не была чисто размонтирована.

Это 64-битная журналируемая файловая система, которая поддерживает очень большие файлы (8 EB) и файловые системы (16 EB) на одном хосте.

XFS является файловой системой по умолчанию для Red Hat Enterprise Linux 7.

Восстанавливаемая файловая система не должна быть смонтирована перед выполнением xfs_repair, иначе результирующая файловая система может быть непоследовательной или поврежденной.

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

В этом руководстве мы покажем вам, как использовать команду ‘xfs_repair’ в Linux для восстановления поврежденной файловой системы XFS.

⛬ Файловая система XFS устанавливается только для чтения (CentOS / RHEL)

Общий синтаксис:

xfs_repair [option] [device or partition or mount point]

Повреждение файловой системы XFS

Мы намеренно испортим файловую систему XFS, выполнив следующую команду.

Она удалит случайно выбранные блоки метаданных файловой системы.

Примечание: Пожалуйста, не тестируйте это на производственном сервере, так как это может сильно повредить ваши данные.

Эта команда доступна только в отладочных версиях ‘xfs_db’.

Это полезно для тестирования xfs_repair и xfs_check.

sudo umount /data

Повреждение файловой системы xfs с помощью команды xfs_db.

sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/sdb1

blocktrash: 2/3 btino block 14 bits starting 2837:5 flipped
blocktrash: 3/5 btrefcnt block 411 bits starting 3714:0 flipped
blocktrash: 2/2 btcnt block 3 bits starting 2143:4 flipped
blocktrash: 2/2 btcnt block 1024 bits starting 523:4 flipped
blocktrash: 3/3 btino block 467 bits starting 1047:6 flipped
blocktrash: 3/4 btfino block 524 bits starting 1775:2 flipped
blocktrash: 0/5 btrefcnt block 224 bits starting 3086:6 flipped
.
.
blocktrash: 2/2 btcnt block 5 bits starting 3026:4 flipped
blocktrash: 2/5 btrefcnt block 1 bit starting 288:2 flipped
blocktrash: 0/4 btfino block 63 bits starting 1014:5 flipped
blocktrash: 0/17 inode block 24 bits starting 3533:1 flipped
blocktrash: 3/5 btrefcnt block 956 bits starting 2970:2 flipped
blocktrash: 2/3 btino block 482 bits starting 2368:3 flipped

Когда вы попытаетесь загрузить файловую систему, вы увидите следующее сообщение об ошибке, поскольку она была повреждена.

sudo mount -a

mount: /data: mount(2) system call failed: Structure needs cleaning.

1) Восстановление файловой системы XFS

Вы можете восстановить поврежденную файловую систему XFS без рута на работающей системе Linux.

Вам может понадобиться загрузить систему в режиме Rescue Mode или Emergency Mode для восстановления файловой системы, если ее невозможно размонтировать во время работы системы.

Шаг-1: Размонтируйте файловую систему, для которой вы хотите запустить fsck.

sudo umount /data

Шаг-2: Запустите xfs_repair с опцией ‘-n’, чтобы выполнить пробный запуск.

Обратите внимание, что инструмент ‘xfs_check’ был упразднен в пользу ‘xfs_repair -n’.

sudo xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x27fe08/0x1000
btree block 1/1 is suspect, error -74
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
.
.
free inode 190 contains errors, would correct
bad CRC for inode 191, would rewrite
UUID mismatch on inode 191
would have cleared inode 191
        - agno = 1
        - agno = 2
        - agno = 3
would rebuild corrupt refcount btrees.
No modify flag set, skipping phase 5
Inode allocation btrees are too corrupted, skipping phases 6 and 7
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Would format log to cycle 2161922.
No modify flag set, skipping filesystem flush and exiting.

Шаг-3: Запустите xfs_repair для восстановления файловой системы:

sudo xfs_repair /dev/sdb1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x8/0x1000
btree block 0/1 is suspect, error -74
bad magic # 0xb1bdccbd in btbno block 0/1
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
.
.
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Format log to cycle 2161922.
done

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /dev/sdb1

2) Восстановление тома XFS LVM с помощью xfs_repair

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

Для восстановления LVM-раздела следуйте приведенной ниже процедуре:

Шаг-1: Убедитесь, что конкретный том LVM находится в активном состоянии для запуска xfs_repair. Чтобы проверить состояние LVM, выполните:

sudo lvscan

  ACTIVE              '/dev/myvg/vol01' [1.00 GiB] inherit
  inactive            '/dev/myvg/vol02' [1.00 GiB] inherit
  ACTIVE              '/dev/rhel/swap' [2.07 GiB] inherit
  ACTIVE              '/dev/rhel/root' [<26.93 GiB] inherit

Если он “inactive“, активируйте его, выполнив следующую команду:

sudo lvchange -ay /dev/myvg/vol02 -v

  Activating logical volume myvg/vol02.
  activation/volume_list configuration setting not defined: Checking only host tags for myvg/vol02.
  Creating myvg-vol02
  Loading table for myvg-vol02 (253:3).
  Resuming myvg-vol02 (253:3).

Шаг-2: Размонтируйте устройство или файловую систему, для которой вы хотите запустить xfs_repair.

sudo umount /dev/myvg/vol02

Шаг-3: Запустите xfs_repair для восстановления файловой системы.

Для запуска xfs_repair необходимо ввести путь к LVM-тому, а не к реальному физическому разделу.

sudo xfs_repair /dev/myvg/vol02

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x180008/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x5581eed67251, xfs_allocbt block 0x100008/0x1000
btree block 2/1 is suspect, error -74
.
.
junking entry "messages-20211004" in directory inode 128
bad attribute format 1 in inode 140, resetting value
        - agno = 1
        - agno = 2
        - agno = 3
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
disconnected inode 144, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:31).
Format log to cycle 2161922.
done

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /apps1

Заключение

В этом руководстве мы показали вам, как восстановить поврежденную файловую систему XFS в Linux.

Также мы показали, как запустить xfs_repair на томах LVM.

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

см. также:

🐧 Как проверить и восстановить файловую систему EXT4 на Linux

🐧 Как увеличить существующую файловую систему XFS на логический том LVM

🐧 Как вывести список служб, которые запускаются при загрузке на Linux

🐧 Советы по обеспечению безопасности сервера CentOS – часть 1