Just dropping by - looking for large animals in a VMFS habbitat

[continuum]

Hi guys - I am no vSAN user so I dont have a vSAN question.

I am interested in recovery and VMFS and would like to complete my zoo of large animals that we can expect in a VMFS 6 habbitat.

For regular VMDKs I think I found a neat trick to scan large areas very quickly.

Now I ask for a list of vSAN objects just to check if I  can add them to my scan easily.

If you want to help here is my wish list:

1. first MB dumped with dd

2. last MB dumped with dd

3. - or less useful a hexdump of both pieces

4. answer if you are sure only: does this object gets allocated in LargeFileBlocks only or does it use 1MB blocks

5. if possible also provide vmkfstools -p 0 vSANobject > mapping.txt

6. and finally vmkfstools -D -v10 vSANobject > info.txt

I posted the same in the vSphere forum without results and was ready to give up - then I was told to ask here.

Idea behind this: assume you have a large VMFS volume and metadata is unreadable.

Standard recovery scans against a 60 TB volume take so long that you will not run them. Testdisk, Diskinternals, Scalpel, all those tools need days to scan such an area.

I plan to do that in minutes by not looking everywhere and instead only search those places where  the large animals go. You could say I only search the rivers and waterholes and still find most of them in a fraction of the time.

If you contribute and provide lets say the Lions and the Waterbuffalos ....  I already got the elephants(thick flats) and hope that hippos (sesparse) can be added - not sure yet.

Thanks for your interest

Results may help some desperate user next week ...

Ulli

[continuum]

Technical details:

elephant: when the first KB of a LFB (large file block with 512 MBs) has both "55aa" and "EFI PART"  it is an african elephant - if it has only "55aa" it is in an indian elephant (GPT / MBR disk)

waterhole: start of a LFB block

river: long string of alligned LFBs

Reason why this is fast: I only look at 1 / 524288 of the full area.

Rivers can be interrupted so I start with a full scan for a few Gbs - and do the same in parallel somewhere in the middle area

When I have the first elephant I assume I found the start of the river and follow it up to the end if the disk.

If I  have not found all expected elephants this way I assume the middle area has a new river.

and now guys - show me your Lions

or at least enjoy the post as much as I had.

Ulli

[12rfcx]

Can I recover the deleted files in a vmfs w/o the use of diskinternal recovery software?

[continuum]

To recover any object from a unreadable VMFS volume you need 3 values for a dd comand.

If you have them for every fragment of the object then you can extract it without any 3rd party software at all.

In an ideal case you can recover a 1 TB flat.vmdk with dd if=blockdevice of=flat.vmdk bs=1M count=1Tb.

If the object is fragmented into 50.000 fragments you need a 50.000 line script.

This post is about those objects that are typically thick provisioned - mostly written in LFBs.

For thin provisioned objects searching like this makes no sense. Thin provisioned objects are stored in large piles of areas at the end of the rivers.

If the VMFS information is lost those large piles of 1mb fragments are almost hopeless ....

Even the elephants are still a challenge  if they are fragmented - but  once I realised that all I need is the next waterhole that maybe less hopeless than I assumed.

[continuum]

In case anybody searches for the same input -

vSphere Hands-on Labs

is available and may be used to identify the objects of the vSAN family.