Как восстановить файловую систему XFS с ошибкой чтения суперблока

У меня есть диск с Buffalo LinkStation, на котором есть раздел XFS, который я не могу смонтировать.

Подключите диск к SATA->USB-устройству на Ubuntu. Я получаю следующее:

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63      594404      297171   83  Linux
/dev/sdb2          594405     1590434      498015   83  Linux
/dev/sdb4         1590435   976768064   487588815    5  Extended
/dev/sdb5         1590498     1863539      136521   82  Linux swap / Solaris
/dev/sdb6         1863603   976494959   487315678+  83  Linux

Проблемный раздел - /dev/sdb6.

$ sudo xfs_check /dev/sdb6
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

Поэтому попытка опции xfs_repair -L приводит меня к ситуации, которую я не могу преодолеть:

$ sudo xfs_repair -L /dev/sdb6
Phase 1 - find and verify superblock...
superblock read failed, offset 382252089344, size 131072, ag 89, rval -1

fatal error -- Input/output error

Используя photorec, я смог вытащить некоторые файлы из этого раздела, поэтому данные там и диск работает физически. Однако существует проблема с суперблоками.

Как мне восстановить этот раздел?

5 ответов

Решение

После ошибки воспроизведения XFS попробуйте снова смонтировать раздел в соответствии с сообщением об ошибке.

Если все становится слишком грязно, я настоятельно рекомендую скачать UFS Explorer, чтобы помочь с глубоким восстановлением файлов из другой системы.

Ответы выше не помогли мне, когда у меня была эта проблема сегодня (около 9,5 часов назад сейчас). Я представлю здесь решение, которое сработало для меня, а также причины, по которым предыдущий ответ не помог.

симптомы

  1. Из ниоткуда, любой файл в /home не может быть сохранен / отредактирован, и т. д. или любой каталог в списке.
  2. dmesg показал где-то xfs_do_force_shutdown called вокруг нескольких других сообщений XFS.
  3. xfs_repair не удалось в фазе 1 с superblock read failed с последующим fatal error -- Input/output error
  4. Остальная часть моего диска работала безупречно (включая /т.е. только /home не работал).
  5. Пытаться mount приведет к superblock cannot be found (или аналог) ошибка, но нет подсказки, что делать дальше.

Решение

Решение основано на этом посте Найджела Смита, основного автора XFS (если я правильно понимаю). Я опубликую шаги здесь в случае, если предыдущая ссылка устареет. Все следующие операции должны выполняться как root (По-видимому).

  1. Запустите долгую самопроверку диска: smartctl -t long /dev/sda, Это может занять некоторое время. Вы также можете запустить короткий тест с smartctl -t short /dev/sda если есть сравнительно недавний длинный тест (как это было в моем случае).
  2. Изучите тест с помощью: smartctl -l selftest /dev/sda или же smartctl -a /dev/sda (последний отображает все, но нужная вам информация почти в самом конце).
  3. Последний столбец протокола испытаний называется LBA_of_first_error, Это позиция первой ошибки на диске. Из последнего теста (который будет пронумерован как "#1" и будет находиться в верхней части списка), возьмите отображаемое число и разделите его на восемь и урежьте до целочисленного значения (см. Исходное сообщение о том, почему).
  4. Затем вы обнуляете этот конкретный блок. Это приведет к повреждению конкретного файла в этой позиции. (Но если вы исчерпали любой другой метод, несколько поврежденных файлов не так уж и важны.) Для этого выполните следующую команду: # dd if=/dev/zero of=/dev/sda conv=sync bs=4096 count=1 seek=*NUMBER_COMPUTED_EARLIER*
  5. Выполните короткий тест и подождите минуту или две, чтобы получить результат. Повторяйте это, пока в коротком тесте не отобразится ошибка. Или вы можете проверить приблизительное количество ошибочных блоков с smartctl -A /dev/hda | egrep 'Reallocated|Pending|Uncorrectable' В моем случае я повторял шаги с 1 по 4, пока у меня не было 24 ошибок.
  6. Бежать xfs_repair /dev/sda (без -L флаг). Это, вероятно, сообщит, что вам следует попытаться смонтировать файловую систему из-за ошибок журнала журнала.
  7. Попытайтесь смонтировать эту систему. В моем случае это не удалось, поэтому мне пришлось бежать xfs_repair -L /dev/sda который удаляет журнал журнала (что может привести к удалению данных).
  8. Смонтируйте свою файловую систему и сделайте последнее резервное копирование!

Почему вышеупомянутые решения больше не работают

  • Начальному посту несколько лет. Тем временем в XFS было достаточно изменений, чтобы команда SuSE считала его достаточно стабильным, чтобы использовать его в качестве основной FS для /home,
  • xfs_check был сделан устаревшим в пользу xfs_repair -n,
  • Решение Debian было ужасной хлопотой и пустой тратой времени. На данный момент Debian не поддерживает загрузку UEFI, и этой информации нет ни на их странице загрузки, ни на их главной странице FAQ (она есть в их Wiki). Таким образом, чтобы загрузиться с этим, вам нужно отключить UEFI Secureboot в вашем BIOS, а затем загрузиться на ключе. После этого вы заметите, что по умолчанию инструменты xfs не установлены. Так ты сделаешь apt-get install xfsprogs только чтобы понять, что, будучи Debian, их "стабильные" пакеты буквально отстали. Короче, xfs_repair /dev/sda просто висел навсегда. Процесс не может быть убит (даже с сигтермой).
  • UFS Explorer - платное программное обеспечение.
  • photorec поддерживает только определенные типы файлов (например, пока ваши ключи GPG) и восстанавливает все файлы с произвольными именами в одной папке. Удачи, пройдя через все это и найдя соответствующую информацию.

У меня есть раздел XFS на "sda6". В Lubuntu он поврежден, не исправит и не смонтирует раздел XFS 13.10. При загрузке Lubuntu говорится, что это должно быть исправлено, и пытается при загрузке исправить файловую систему XFS. Когда я пошел на первую установку Lubuntu, на разделе написано Unknown.

Lubuntu не исправлена. Использование команды xfs_check для меня не решено.

Я наконец решил вернуться к Debian 7 и переустановить. Обнаружены все файловые системы и нормально смонтированный раздел XFS.

Я читал много пользователей для файловых систем XFS, поэтому я думаю, что это проблема изменений в версиях ядра, потому что Debian 7 использует версию 3.2 и нормально монтирует XFS без ошибок, но в Ubuntu с последним ядром 3.11 не решается файловая система XFS.

Я пытался с CentOS 6.5, но CentOS следовал за RedHat и со старым "стабильным" ядром. Он не обнаружит XFS автоматически.

Наконец, на Debian 7 выполняется резервное копирование всех данных на разделе XFS и воссоздание разделов на EXT4.


Из-за того, что RedHat не исправит раздел чтения XFS и некоторые проблемы с XFS (Google, сколько пользователей не решили разделы чтения XFS) Обычно я выбираю Debian для резервного копирования и перехода на новый, совместимый с ядром 3.11, на EXT4/btrfs... файловые системы.

Надеюсь, это кому-то поможет.

Недавно у меня возникла большая проблема с XFS 3To fs. Невозможно смонтировать, нет суперблока. xfs_repair не нашел подходящей части суперблока. Это производственная машина, время безотказной работы 600 дней, и я никогда раньше ею не пользовался.

Пробовал восстановление (нужно 2 дня), ничего лучше.

Наконец, когда я собирался сказать нашему клиенту, что все потеряно, я попробовал fsck. Чистый объем. Бывает, что тип fstab был неправильным, это был ext4. Все остальные файлы находятся в формате xfs, а этот — в ext4.

xfs_repair может определить, когда файловая система выглядит как ext4...

Я исправил свой раздел XFS с помощью нового загруженного Debian 8.7.1 на реальном сервере, просто поместил диск на эту систему, и он восстановился автоматически. Centos 5 и 6 не могут отремонтировать его

Другие вопросы по тегам