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?
On Fri, Nov 6, 2009 at 4:19 PM, Jesper Jensen
<[email protected]> 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 [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
Alexey Salmin wrote:
> 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 :)
On Fri, Nov 6, 2009 at 5:49 PM, Jesper Jensen
<[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
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
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
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
On Fri, Nov 6, 2009 at 9:43 AM, Alexey Fisher
<[email protected]> 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
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
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