Very odd case of TestDisk use and filesystem structure

Using TestDisk to repair the filesystem
Post Reply
Message
Author
derekcairo
Posts: 2
Joined: 03 Oct 2017, 00:29

Very odd case of TestDisk use and filesystem structure

#1 Post by derekcairo » 03 Oct 2017, 00:50

I have a bit of an unusual case that I don't think TestDisk covers currently but may be able to cover in the future possibly.

As I was trying to install a new distribution I accidentally gdisk'd /dev/sda instead of /dev/sdc and deleted all of the partitions off of my data drive. I also wrote to the device a new GPT partition table label with a 2G EFI partition and a Linux Filesystem partition that filled the rest of the disk. I later then deleted the two partitions and made an ext4 partition that filled the rest of the device. At this point forward I have done a complete dd backup of the 1.8TiB drive and am working on the backed up identical drive (also 1.8TiB). I never mkfs'ed the device so the data should all be there.

Using TestDisk, I am shown scrambled partitions like MS Dos or Mac as the Filesystem when I select Intel/PC or EFI GPT. However, when I select "None" TestDisk happily reveals to me my ext4 filesystem but 'p' shows no files due to corruption and I am also unable to write to disk due to the previous "None" option. At first I was confused but later I realized I must have formatted the Data drive with Gnome's Disk Utility and with no partitioning and just an ext4 filesystem. Successful mountings of the device itself on the superblock backups 65536, 131072, etc (but not 32768) confirm to me that this is in fact the case.

However, after mounting, while the first directory of folders exists, when I entered those directories I was given a "Structure needs cleaning" error for the majority of the files and folders. Running e2fsck with the superblock backups failed to fix the problem but left me with 29GiB of the original 1TiB of data (the folders & files without "Structure needs cleaning" errors) of the 1.8TiB drive. Lost+Found did not contain any of the remaining data either.

A friend on IRC tried reproducing my steps on his own setup and also came to the same error of "Structure needs cleaning". So far this is as far as we have got. Does anyone have any ideas on how I could salvage the rest of the data? I'll be posting our further attempts below for anyone that happens to chance upon this post in the future!

Many Thanks!

Sponsored links

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

Re: Very odd case of TestDisk use and filesystem structure

#2 Post by cgrenier » 03 Oct 2017, 06:08

If fsck now find the filesystem in a clean state and your files are still missing (files not listed and not present in lost+found), you can try PhotoRec to recover them but it will not recover the original filenames.

derekcairo
Posts: 2
Joined: 03 Oct 2017, 00:29

Re: Very odd case of TestDisk use and filesystem structure

#3 Post by derekcairo » 03 Oct 2017, 06:30

We have tried PhotoRec and it has restored all files but without their names. It would really be impossible for us to sort out all of the files for our various code and piece them together however we are planned to do that as a last resort.

From my own investigations I realize I have deleted the first 33792 bytes of the EXT4 filesystem with gdisk. The ext4 feature flex_bg was activated previously on the ext4 filesystem but 1024 blocks of GDT were also written so i'm hoping no data bitmaps, inode bitmaps, or inode tables were overwritten. As we have not ever resized the disk.

Is there nothing else that can be done? Also should I be using the Allow partial last cylinder in my case for PhotoRec?

Code: Select all

Mock copy of gnome on 2 TiB HDD

tune2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          57e8dc69-003e-4d43-a912-adcbc09d8110
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378646
Reserved block count:     24418932
Free blocks:              480431423
Free inodes:              122101749
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Oct  2 20:55:33 2017
Last mount time:          Mon Oct  2 20:56:09 2017
Last write time:          Mon Oct  2 20:56:16 2017
Mount count:              2
Maximum mount count:      -1
Last checked:             Mon Oct  2 20:55:33 2017
Check interval:           0 (<none>)
Lifetime writes:          1054 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      cbf62753-15ca-4878-9a9e-6594eeaabc85
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x87d53c7b

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

Re: Very odd case of TestDisk use and filesystem structure

#4 Post by cgrenier » 05 Oct 2017, 08:50

If you can revert the filesystem state to what it was before the fsck, try TestDisk, Advanced, List and check if you can copy the missing files.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests