I'm hoping that someone can help!
I've an old server running esxi 5.5 that I'm retiring so I've been moving files over to another data store. I'd created an iscsi target and mounted it and the move of VM's from one data store to the other has been successful Apart from for the very last file!
It's one of the flat vmdk's for a VM that was my NAS and it'd got to around 80% before failing. No file on the destination and worse, the host must have thought that it'd sent the file and removed the original.
My plan was to move the disks from this old server to the new one so at the moment I've got the old one switched off (there were no vm's running anyhow). The disks were Thick lazy zero'd and the store is VMFS5.
Reading the forum I've extracted a header dump but now I'm at the point of ... ok ... so now what? I'm presuming I need to analyse that to find the block and then dd it off but no idea on how to analyse the header dump to be able to do that.
If anyone is able to offer pointers, you'd be my saviour and I'll say 100 "Copy don't move" prayers for you! 😄
please rephrase your post - I dont see any detail that would help me to understand your issue ???
Hope you're well! I'm hoping to restore access to a file that was deleted from the datastore on a server I'm migrating from.
What I'd done was browse the datastore and selected "Move to..." and selected a datastore I'd mounted via iscsi on a temporary server. The copy proceeded for overnight but I had an error about a failed write to the destination. The server must has decided that it had completed the copy part of that process though and deleted the file from the original datastore. So I'm hoping to be able to get that back by undeleting it in some way or carving the data from the disk via dd.
I've extracted the header dump so I'm hoping it's possible to find the file and extract it. If you're able to help I'd really appreciate it.
The original datastore is VMFS5 and the file is a vmdk flat file that was thick provisioned lazy zero'd.
create a dump fr boh datastores - one dump should still have the relevant metadata
You would want to find a line like
all by itself - then the missing flat still may be recoverable.
An entry like that means that the descriptorfile for TrueNAS_5-flat.vmdk still exists.
You should also have a line:
(without extra quotes or trailing /leading spaces)
If not more intensivive scans are required.
Looks like it'll take a deeper scan. That was the only instance of the file name.
I'll boot the server again and take a larger header dump (I took 1500 blocks - 1Mb block sized) just in case too.
Friday I will be in hospital .... call me via skype on saturday.