EXT4 - how to recover unknown partition table ubuntu

How to use TestDisk to recover lost partition
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Post Reply
Message
Author
mshaffer
Posts: 4
Joined: 11 Mar 2018, 06:14

EXT4 - how to recover unknown partition table ubuntu

#1 Post by mshaffer » 11 Mar 2018, 06:20

Somehow a partition table got lost. I did some Google search and ended up here.

So I loaded TestDisk

Selected Non Partition, Did Quick Scan

It found the EXT4 partition (8TB drive via RAID10)

When I clicked 'p' I could see my folders and files... PHEW!

So how do I recover it, to rebuild the GPT table? What's next?

Sponsored links

User avatar
cgrenier
Site Admin
Posts: 4290
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: EXT4 - how to recover unknown partition table ubuntu

#2 Post by cgrenier » 12 Mar 2018, 07:04

Usually if you want an EFI GPT partition table, it's better to select EFI GPT instead of None when asked about the partition table type.
Please copy and paste the testdisk.log file.

mshaffer
Posts: 4
Joined: 11 Mar 2018, 06:14

Re: EXT4 - how to recover unknown partition table ubuntu

#3 Post by mshaffer » 12 Mar 2018, 16:36

Thanks for the note.

Attached is a screenshot of bootup where EXT4-fs through some errors trying to recover the journal.

Image

Both partitions are part of an external DAS, and when trying to mount, no error would appear, but when trying to access data in the drives, we would get I/O error.

/sdc/ is 16TB /mnt/objects/
/sdd/ is 8TB /mnt/prep/

Image
Image

I ran "unknown" on /sdd which took a little under 24 hours.

Since I know it was GPT-EXT4, I followed your instructions on Sunday, running two instances remotely of testdisk (when I type "Create" is that logging to a new file or the same file? testdisk-pid.log?

Image

Anyway, I have two instances running, and only one log file... Which I am attaching... Since the upload attachement doesn't accept ".log", I am zipping it.



Here is part of that file...

Code: Select all

Sun Mar 11 21:29:32 2018
Command line: TestDisk

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.13.0-32-generic (#57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014) x86_64
Compiler: GCC 4.8
Compilation date: 2013-10-29T01:29:29
ext2fs lib: 1.42.9, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none
Warning: can't get size for Disk /dev/mapper/control - 0 B - 1 sectors, sector size=512
Hard disk list
Disk /dev/sda - 299 GB / 278 GiB - CHS 36404 255 63, sector size=512 - DELL PERC H700, FW:2.10
Disk /dev/sdb - 8000 GB / 7451 GiB - CHS 972666 255 63, sector size=512 - DELL PERC H700, FW:2.10
Disk /dev/sdc - 16 TB / 14 TiB - CHS 1945343 255 63, sector size=512 - DELL MD32xxi, FW:0784
Disk /dev/sdd - 8000 GB / 7451 GiB - CHS 972671 255 63, sector size=512 - DELL MD32xxi, FW:0784

Partition table type (auto): None
Disk /dev/sdd - 8000 GB / 7451 GiB - DELL MD32xxi
Partition table type: EFI GPT

Analyse Disk /dev/sdd - 8000 GB / 7451 GiB - CHS 972671 255 63
Bad GPT partition, invalid signature.
Trying alternate GPT
Bad GPT partition, invalid signature.
Current partition structure:
Bad GPT partition, invalid signature.
Trying alternate GPT
Bad GPT partition, invalid signature.

search_part()
Disk /dev/sdd - 8000 GB / 7451 GiB - CHS 972671 255 63

block_group_nr 1

recover_EXT2: part_offset problem

block_group_nr 1

recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

block_group_nr 3

recover_EXT2: part_offset problem

block_group_nr 3

recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

block_group_nr 5

recover_EXT2: part_offset problem

block_group_nr 5

recover_EXT2: "e2fsck -b 163840 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=5/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

block_group_nr 7

recover_EXT2: part_offset problem

block_group_nr 7

recover_EXT2: "e2fsck -b 229376 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=7/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

block_group_nr 9

recover_EXT2: part_offset problem

block_group_nr 9

recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

block_group_nr 25

recover_EXT2: part_offset problem

block_group_nr 25

recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/59608, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=4096
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1953246208
recover_EXT2: part_size 15625969664
     MS Data                        0 15625969663 15625969664 [prep]
     ext4 blocksize=4096 Large file Sparse superblock Backup superblock, 8000 GB / 7451 GiB
Partition not added.

So what is the game: GPT->Ext4, Deep Scan, [T] change to GPT -> EXT4 and select write?

Also is their a command line syntax to specify a logfile so I can run multiple instances?

After I do a deep scan and log it, can I load the info from a log so I don't have to do a deep scan again (similar to journaling)?
Attachments
testdisk.zip
(44.55 KiB) Downloaded 18 times

mshaffer
Posts: 4
Joined: 11 Mar 2018, 06:14

Re: EXT4 - how to recover unknown partition table ubuntu

#4 Post by mshaffer » 14 Mar 2018, 15:08

A little help?

It takes about 20 hours to do a "Quick Search" on 8TB /dev/sdd/ and I am doing this remotely, so the connection drops if I don't move forward with the next step.

I am running two instances for /dev/sdc/ and /dev/sdd/ in different folders so the testlog is now preserved. Attached is the sdd-testlog.zip

In the image below, TestDisk is identifying MAC HFS, and when I go to change T to EFI->ext4 or Linux Extended->ext4, it is no longer green. At that point, I click P to view files, and it says nothing here to show. Is there a way to skip this first step on a new run, and just get to "Depper Scan" where I force EXT4?

Image

I know my filesystem is not HFS, so why is it reporting it to be HFS? Does this mean someone logged into the DAS with a MACINTOSH and messed up the filesystem? I don't understand.

Should I do a dry run of mke2fs -n /dev/sdd to see how it would rebuild?

I am stuck at this moment as I don't fully understand what TestDisk is trying to do. My partition table is corrupt, but I know what kind it is...

Thoughts?
Attachments
sdd-testdisk.zip
(69.61 KiB) Downloaded 21 times

mshaffer
Posts: 4
Joined: 11 Mar 2018, 06:14

Re: EXT4 - how to recover unknown partition table ubuntu

#5 Post by mshaffer » 15 Mar 2018, 06:12

Based on a similar system in our network, the info should be:

Code: Select all

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
### knowing this, how do I proceed with a recovery?

What I have on the corrupt system is:

Code: Select all

GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests