☰

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

tag-icon • tag-icon linux ubuntu partitioning data-recovery partition-recovery
Потерян раздел ext4: testdisk выводит список файлов, но не может исправить таблицу разделов

Краткое содержание:

Testdisk находит потерянный раздел ext4 и может составить список содержащихся в нем файлов, но попытка записать структуру раздела на диск ни к чему не приводит.

Обновлять: После запуска e2fsck -f /dev/sdc1диск был смонтирован и, кажется, работает нормально. Однако он также сообщил о некоторых ошибках (см. 15. ниже).

Что случилось:

Я постараюсь перечислить все, что я сделал в связи с этой проблемой:

  1. Я приобрел новый внешний жесткий диск емкостью 5 ТБ, предварительно отформатированный в FAT32 (названный Intenso).
  2. Я удалил этот раздел и создал новый раздел ext4 с помощью gparted (названный Intenso5TB).
  3. Поскольку раздел принадлежал пользователю root, я изменил владельца и группу на своего пользователя.
  4. Я переместил несколько сотен ГБ данных на этот раздел, а затем благополучно удалил его.
  5. В следующий раз, когда я подключил жесткий диск, он был смонтирован как только для чтения. Мой пользователь все еще был владельцем.
  6. Я добавил «rw» к параметрам монтирования в утилите «Диски» Ubuntu и отмонтировал диск.
  7. Затем утилита Disks отобразила раздел /dev/sdc1 как «тип неизвестен» и не смогла его смонтировать.
  8. Я выбрал «Изменить раздел» и выбрал «Тип linux (0x83)» (тип не был предварительно выбран). Изменений не произошло (Тип по-прежнему неизвестен).

  9. Я провел sudo testdisk /dev/sdcбыстрый анализ, который показал:

    * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

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

  10. После еще одной перезагрузки для обновления таблицы разделов поведение снова стало таким, как описано в пункте 7.

  11. Я переделал 9.; на этот раз я попробовал использовать

    partprobe /dev/sdc

    чтобы избежать повторной перезагрузки, но получил сообщение:

    Error: Partition(s) 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, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

  12. sudo fdisk -luвозвращается

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
Disklabel type: dos
Disk identifier: 0x4400838c

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux

  13. Я запустил sudo parted /dev/sdcthen, rescue 256 1220942591что ничего не дало (никакой задержки, никакого вывода, просто новая командная строка внутри parted), то же самое с rescue 0 1220942591, rescue 1 1220942591или rescue 1 -1.

  14. Я провел глубокий поиск с помощью Testdisk, который выдал несколько идентичных строк:

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

    а также:

    check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
  FAT16 LBA            252822 192 45 254047 161 57   19677685

    во время работы и закрыто с помощью:

    TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63

The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  FAT16 LBA            252822 192 45 254047 161 57   19677685










[ Continue ]
80 GB / 75 GiB

  15. После запуска e2fsck -f /dev/sdc1диск появился в лаунчере. Я отменил e2fsckс, Ctrl+Cчтобы избежать дальнейших изменений, пока не узнаю больше. Затем диск был успешно смонтирован по щелчку. Кажется, я могу читать и писать. Вывод из e2fsck:

    e2fsck -f /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Intenso5TB: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
Inode 59883521 has imagic flag set.  Clear<y>? yes
Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
Inode 59883521 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
Deleted inode 59885573 has zero dtime.  Fix<y>? yes
Deleted inode 59885574 has zero dtime.  Fix<y>? yes
^CIntenso5TB: e2fsck cancelled.

Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****

Мои вопросы:

  1. Есть ли какая-то очевидная ошибка, которую я допустил, и которая могла изначально вызвать эту проблему?

  2. Есть ли надежда восстановить утраченный раздел? Новый вопрос: Являются ли ошибки, о которых сообщается, e2fsckповодом для беспокойства? Могут ли они указывать на физически поврежденный диск?

  3. Что является причиной сообщения об ошибке partprobeв версии 11?

(Данные были перенесены с другого диска, к которому я с тех пор не прикасался, поэтому, хотя сейчас они не видны, их можно восстановить оттуда.)

решение1

Запуск e2fsck -f /dev/sdc1исправил плохой суперблок, и устройство было распознано без проблем. Затем я разрешил e2fsckисправить все обнаруженные проблемы. При последующем запуске e2fsckне сообщалось о дальнейших ошибках.

Расширенный автономный тест, smartctlзавершенный через 9 часов, не выявил ошибок (чтобы предотвратить прерывание теста автоматическим выключением, я применилэтот обходной путь).

Связанный контент