I am an idiot - help recovering files from EXT4 hard drive
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Were you doing this in windows? What software were you using to 'initialize' the disk? The link below to the microsoft site indicates that you cannot initialize a drive that has already been formatted. Since windows does not by default recognize a Linux filesystem, this could be a problem. Initializing a disk does erase all data.
Which Linux distribution/version are you using. Is it on a virtual machine or directly on hardware? More info is probably needed to get help but Testdisk is about the best software available that I am aware of to recover data.
The best tools on Linux do one thing well rather than several things not so well. Format and initialize shouldn't have been together, at least, not without a following are you sure confirmation required for something so devastating as initializing a disk that has formatted partitions.
First, make a bit for bit copy of that drive somewhere, if you can. If you start playing around you can make things worse.
Run:
Code:
mkfs.ext4 -n <device>
It will give you a list of backup superblocks that are likely the same as the original file system. If you're lucky, one of those superblocks may be intact. Then use fsck with that backup to see what you can recover. Always work on copies of the data! Each time you run fsck you'll be modifying the filesystem. You want a clean slate each time.
After 6 seconds you definitely lost some data, whether a good superblock can be found or not.
Also as a last resort you can use photorec, which is typically packaged with testdisk. It uses metadata and signatures to recover files. Depending on fragmentation and such, you may still lose data even if it recognizes the header, metadata, whatever. If you use photorec you will definitely lose filenames.
First, make a bit for bit copy of that drive somewhere, if you can. If you start playing around you can make things worse.
Run:
Code:
mkfs.ext4 -n <device>
It will give you a list of backup superblocks that are likely the same as the original file system. If you're lucky, one of those superblocks may be intact. Then use fsck with that backup to see what you can recover. Always work on copies of the data! Each time you run fsck you'll be modifying the filesystem. You want a clean slate each time.
After 6 seconds you definitely lost some data, whether a good superblock can be found or not.
Also as a last resort you can use photorec, which is typically packaged with testdisk. It uses metadata and signatures to recover files. Depending on fragmentation and such, you may still lose data even if it recognizes the header, metadata, whatever. If you use photorec you will definitely lose filenames.
This is certainly a VERY GOOD advice. Do yourself a favor and follow it...
Besides Testdisk (and photorec) there is another (free) option for rescuing data, especially from EXT file systems:
R-Linux: https://www.r-studio.com/free-linux-recovery/
It might be even your best option for file recovery, since your medium is EXT4.
Good luck.
So far I don't see any evidence of what was actually done. What was initialised ? - the disk (partition table) or the filesystem ?. Those tools address different aspects of those questions. I haven't tried R-Linux, but it's self-promo looks polished.
What does "lsblk -f" show for the affected disk ?.
So far I don't see any evidence of what was actually done. What was initialised ? - the disk (partition table) or the filesystem ?. Those tools address different aspects of those questions. I haven't tried R-Linux, but it's self-promo looks polished.
What does "lsblk -f" show for the affected disk ?.
I agree - it isn't quite clear what I have done, exactly.
Having looked at the Openmediavault manual, initialise seems to mean that I was applying a new file system to the disk - i.e. EXT4 to a disk already running EXT4.
I am not quite sure exactly what this involves but I am hopeful that this is less destructive than actively trying to wipe the disk.
Once TestDisk has stopped running, I shall run "lbslk -f" and see what it comes back with.
I gave up with TestDisk as it seems to be struggling.
I tried gdisk and have come out with the following:
Code:
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue May 30 19:25:18 2023 from 192.168.1.100
root@omvtemp:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 5.5T 0 disk
└─sda1 8:1 0 5.5T 0 part /srv/dev-disk-by-uuid-63c34541-0fd4-4ffc-bc49-2
sdb 8:16 0 1.8T 0 disk
└─sdb1 8:17 0 1.8T 0 part /srv/dev-disk-by-uuid-39cd1bac-1f3e-473c-8743-a
sdc 8:32 0 465.8G 0 disk
└─sdc1 8:33 0 465.8G 0 part /srv/dev-disk-by-uuid-dc07c53d-d6a0-4027-a500-5
sdd 8:48 0 59.6G 0 disk
├─sdd1 8:49 0 58.7G 0 part /
├─sdd2 8:50 0 1K 0 part
└─sdd5 8:53 0 975M 0 part [SWAP]
sde 8:64 0 4.5T 0 disk
└─sde1 8:65 0 4.5T 0 part /srv/dev-disk-by-uuid-bcaf61dd-18c0-45c6-ac6d-e
sdf 8:80 0 12.7T 0 disk
└─sdf1 8:81 0 12.7T 0 part
root@omvtemp:~# gdisk /dev/sdf
GPT fdisk (gdisk) version 1.0.6
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help):
Can anything be done from here?
Last edited by elsmandino; 05-30-2023 at 01:41 PM.
gdisk is a command line partitioning tool for GPT based disks and is not a repair tool. fsck is a filesystem repair tool but it will not work in this case nor find lost files. lsblk will output partition information in a nice format.
When a filesystem is formatted basically all the superblock structure, inode table and block data is initialized but typically the data block i.e. where all the files are located is left as is. The inode table is how the filesystem finds the files on disk. I would try running photorec. It ignores the filesystem and searches the "raw" disk for file signatures. To reduce fragmentation ext4 can write files anywhere on disk and with a 12TB filesystem there is a lot of real estate to look at so it will not be a fast process.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
