Formatted/repartitioned wrong disk, arrgh!
First of all I know this isn't a development or bug related question, but I'm running out of ideas on how to rescue my files, so I hope you guys can bare with me.
Yesterday I accidentally did a repartition ad and mkfs.ext4 on the wrong data disk, ARRGH! I thought it was an empty disk, but nooo it was one containing a lot of data that I don't really have a backup of anywhere. :-(
I've tried various fsck -f -b <backup superblocks> but it looks like I might have made a royal fuckup and overwritten/erased every single backup superblock. :-(
As far as I recall the first time I ran fsck it said something about the blocks being empty and asked me to accept a bunch of times (eventually ended up using the -p option).
I have also tried tools like magicrescue and foremost to recover my files, but no such luck.
Can you guys recommend a good way to recover the files?
Regards
Jesper
Have you only repartitioned your disk or also formatted it?
Quoted 22 lines · Jesper Jensen
First of all I know this isn't a development or bug related question, but I'm running out of ideas on how to rescue my files, so I hope you guys can bare with me.
Yesterday I accidentally did a repartition ad and mkfs.ext4 on the wrong data disk, ARRGH! I thought it was an empty disk, but nooo it was one containing a lot of data that I don't really have a backup of anywhere. :-(
I've tried various fsck -f -b <backup superblocks> but it looks like I might have made a royal fuckup and overwritten/erased every single backup superblock. :-(
As far as I recall the first time I ran fsck it said something about the blocks being empty and asked me to accept a bunch of times (eventually ended up using the -p option).
I have also tried tools like magicrescue and foremost to recover my files, but no such luck.
Can you guys recommend a good way to recover the files?
Quoted 7 lines
Regards
Jesper
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Well, I did a mkfs, so as far as I haven't erased the entire content of the disk.
Maybe I should mention that the ext4 partition in question is running on inside a ESXi with the physical disk formattet to VMFS and mounted in my virtual machine (Ubuntu).
It was the physical disk that got formatted by ESXi and I then recreated the virtual disk and made a new ext4 filesystem on top of that.
A bit complicated yea, hence why I accidentally used the wrong disk. :-(
Regards
Jesper
Quoted 1 line · Alexey Salmin
Have you only repartitioned your disk or also formatted it?
I think the only thing I can recommend to you is to "grep for your files and hope for the best" (c)
I don't know any automated way to restore files after complete destroying of fs, but there always is grep and hexdump :)
Quoted 16 lines · Jesper Jensen
Well, I did a mkfs, so as far as I haven't erased the entire content of the disk.
Maybe I should mention that the ext4 partition in question is running on inside a ESXi with the physical disk formattet to VMFS and mounted in my virtual machine (Ubuntu).
It was the physical disk that got formatted by ESXi and I then recreated the virtual disk and made a new ext4 filesystem on top of that.
A bit complicated yea, hence why I accidentally used the wrong disk. :-(
Regards
Jesper
Quoted 9 lines
Quoted 2 lines · Alexey Salmin
Have you only repartitioned your disk or also formatted it?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Alexey Salmin
I think the only thing I can recommend to you is to "grep for your files and hope for the best" (c)
I don't know any automated way to restore files after complete destroying of fs, but there always is grep and hexdump :)
Unfortunately, there isn't much else that can be done, since the inode table has been zero'ed out.
Sorry. :-(
- Ted
Quoted 6 lines · Theodore Tso
Quoted 4 lines · Alexey Salmin
I think the only thing I can recommend to you is to "grep for your files and hope for the best" (c)
I don't know any automated way to restore files after complete destroying of fs, but there always is grep and hexdump :)
Quoted 6 lines
Unfortunately, there isn't much else that can be done, since the inode table has been zero'ed out.
Sorry. :-(
- Ted
Well, if you repartitioned / moved the partition, then the new mkfs likely wouldn't have perfectly overwritten the old metadata structures, so if you can re-partition again and put the starting sector -back- at the original location, an e2fsck might have a fighting chance to find -something- ...
-Eric
Quoted 6 lines · Eric Sandeen
Well, if you repartitioned / moved the partition, then the new mkfs likely wouldn't have perfectly overwritten the old metadata structures, so if you can re-partition again and put the starting sector -back- at the original location, an e2fsck might have a fighting chance to find -something- ...
I thought what had been done was that a physical disk had a new ESX layout slapped on top of it, and then a new partition label was created, and *then* mkfs.ext4 was run --- so that the new filesystem pretty much overlaid the original filesystem. In that case, there really isn't much that can be done. If the repartitioning really did move the start of the filesystem sufficiently to avoid smashing all of the metadata fields, then I agree, there might be a chance....
One idea which Andi Kleen and I tossed around at Linux Kongress was to add a 4 byte per-inode CRC that also mixed in the inode number (to detect inode table blocks getting written to the wrong location on disk) as well as a per-filesystem ID. This would allow us to detect inodes from pervious filesystems formats, which would also allow us to avoid needing to zero out the inode table, and it might allow for people to have a slightly better chance of recovering after a mke2fs (as well as making mke2fs faster without needing to zero the inode table, either in mke2fs or via a background kernel thread once the file system is mounted).
- Ted
Am Freitag, den 06.11.2009, 09:04 -0500 schrieb Theodore Tso:
Quoted 8 lines · Alexey Salmin
Quoted 4 lines
I think the only thing I can recommend to you is to "grep for your files and hope for the best" (c)
I don't know any automated way to restore files after complete destroying of fs, but there always is grep and hexdump :)Unfortunately, there isn't much else that can be done, since the inode table has been zero'ed out.
Do _not_ever_ change the disk after crush or what ever you did with it. Make an image of your partition (dd if=/dev/you_partition of=backup_of_partition) and try testdisk (photoreck) and/or sleuthkit.
Alexey
Quoted 7 lines · Alexey Fisher
Am Freitag, den 06.11.2009, 09:04 -0500 schrieb Theodore Tso:
Quoted 6 lines · Alexey Salmin
Quoted 4 lines
I think the only thing I can recommend to you is to "grep for your files and hope for the best" (c)
I don't know any automated way to restore files after complete destroying of fs, but there always is grep and hexdump :)
Quoted 8 lines
Quoted 2 lines
Unfortunately, there isn't much else that can be done, since the inode table has been zero'ed out.
Do _not_ever_ change the disk after crush or what ever you did with it. Make an image of your partition (dd if=/dev/you_partition of=backup_of_partition) and try testdisk (photoreck) and/or sleuthkit.
Alexey
Totally agree with Alexey, but if the virtual drive was using a file and not a partition or full drive, then you can just make a copy of the virtual drive. Then try to recover from the copy. Make more copies as you have problems, etc.
If the inodes are gone (and likely they are), then the only other option you have left is "data carving".
Data carving depends on having your files useing contiguous blocks. With ext4 and files less than 128MB (one extent), there is a reasonble chance I believe that they will be contiguous.
I use a professional ($) tool to data carve, but I'm pretty sure there are some opensource tools out there.
The way the work is to scan all the sectors on the drive (of virtual drive) and look for file header signatures. A lot of complex file types have those. And then they either find the file length somehow from the internal file header, or they just grab x bytes of contiguous data after the header.
Files over 128 MB will use 2 ext4 extents and I don't think there is much chance of the extents being contiguous. Possibly Ted or Eric can comment on that?
Greg
Signature · 14 lines
Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer Preservation and Forensic processing of Exchange Repositories White Paper - <http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html> The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Greg Freemyer
On Fri, Nov 6, 2009 at 9:43 AM, Alexey Fisher
Quoted 3 lines
Do _not_ever_ change the disk after crush or what ever you did with it. Make an image of your partition (dd if=/dev/you_partition of=backup_of_partition) and try testdisk (photoreck) and/or sleuthkit.
Totally agree with Alexey,
Yea, I agree too, now... I kinda did before as well, but I found a promising article about how just to mkfs and fsck -b <backup superblock> and then you were all set. But it turned out it wasn't as easy as that. :-(
Quoted 4 lines
but if the virtual drive was using a file
and not a partition or full drive, then you can just make a copy of the virtual drive. Then try to recover from the copy. Make more copies as you have problems, etc.
It is a full partition/driver, but I'm not 100% sure the virtual drive is exactly the same size, since you can't select the entire disk when adding it to a virtual machine, you have to type in XX MB/GB, and I might have typed a different size this time around.
Quoted 5 lines
The way the work is to scan all the sectors on the drive (of virtual drive) and look for file header signatures. A lot of complex file types have those. And then they either find the file length somehow from the internal file header, or they just grab x bytes of contiguous data after the header.
Yea, that's what I'm trying to do at the moment, but so far without much luck.
Is there a specific signature for the superblocks and backups of those? I suppose I could search for that signature. Maybe the re-partitioning (by ESXi) has shifted the entire partition some blocks.
Regards
Jesper