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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
