Thank you for reading this post, don't forget to subscribe!
Команда 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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
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
|
1 2 3 4 |
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
|
1 2 3 4 5 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
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