Formatted/repartitioned wrong disk, arrgh!

Formatted/repartitioned wrong disk, arrgh!

[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?


Regards
Jesper

Re: Formatted/repartitioned wrong disk, arrgh!

[Alexey Salmin]

Have you only repartitioned your disk or also formatted it?

On Fri, Nov 6, 2009 at 4:19 PM, Jesper Jensen
<linux-ext4_mailinglist@elector.dk> wrote:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Formatted/repartitioned wrong disk, arrgh!

[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

Alexey Salmin wrote:
> Have you only repartitioned your disk or also formatted it?

Re: Formatted/repartitioned wrong disk, arrgh!

[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 :)

On Fri, Nov 6, 2009 at 5:49 PM, Jesper Jensen
<linux-ext4_mailinglist@elector.dk> wrote:
> 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
>
> Alexey Salmin wrote:
>>
>> 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Formatted/repartitioned wrong disk, arrgh!

[Theodore Tso]

On Fri, Nov 06, 2009 at 05:57:14PM +0600, Alexey Salmin wrote:
> 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

Re: Formatted/repartitioned wrong disk, arrgh!

[Eric Sandeen]

Theodore Tso wrote:
> On Fri, Nov 06, 2009 at 05:57:14PM +0600, Alexey Salmin wrote:
>> 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

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

Re: Formatted/repartitioned wrong disk, arrgh!

[Alexey Fisher]

Am Freitag, den 06.11.2009, 09:04 -0500 schrieb Theodore Tso:
> On Fri, Nov 06, 2009 at 05:57:14PM +0600, Alexey Salmin wrote:
> > 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 

Re: Formatted/repartitioned wrong disk, arrgh!

[Greg Freemyer]

On Fri, Nov 6, 2009 at 9:43 AM, Alexey Fisher
<bug-track@fisher-privat.net> wrote:
> Am Freitag, den 06.11.2009, 09:04 -0500 schrieb Theodore Tso:
>> On Fri, Nov 06, 2009 at 05:57:14PM +0600, Alexey Salmin wrote:
>> > 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

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
-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Formatted/repartitioned wrong disk, arrgh!

[Theodore Tso]

On Fri, Nov 06, 2009 at 08:39:33AM -0600, Eric Sandeen wrote:
>
> 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

Re: Formatted/repartitioned wrong disk, arrgh!

[Jesper Jensen]

Greg Freemyer wrote:
> On Fri, Nov 6, 2009 at 9:43 AM, Alexey Fisher
>> 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. :-(

 > 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.

> 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