Pantz
asked on
lost+found files... this is certainly no help!
Hello.
Last night, while screwing around with my ESX/ESXi environment, my NAS device (basically a Dell PowerEdge 1425SC w/ FreeNAS .71) starting acting funky. All of the files disappeared, or at least, appeared to disappear.
I ran fsck on the unmounted volume and it 'fixed' the problem, but, now all my files are in a directory called lost+found. I have no idea what is what. I can't tell which is a directory, or which is a virtual disk, or a VM config...
I guess I'm less screwed than I was, but, still pretty screwed. I'm not a Unix/Linux guy. I'm a Windows guy for life, and that doesn't help. Every time I try to get in bed with Linux/Unix, something silly like this happens... ahhh... but I digress...
Any assistance is appreciated.
Last night, while screwing around with my ESX/ESXi environment, my NAS device (basically a Dell PowerEdge 1425SC w/ FreeNAS .71) starting acting funky. All of the files disappeared, or at least, appeared to disappear.
I ran fsck on the unmounted volume and it 'fixed' the problem, but, now all my files are in a directory called lost+found. I have no idea what is what. I can't tell which is a directory, or which is a virtual disk, or a VM config...
I guess I'm less screwed than I was, but, still pretty screwed. I'm not a Unix/Linux guy. I'm a Windows guy for life, and that doesn't help. Every time I try to get in bed with Linux/Unix, something silly like this happens... ahhh... but I digress...
Any assistance is appreciated.
ASKER
Thanks, turnbulld, for providing to me absolutely no guidance. I'm really not intersted in your opinion. I'm looking for strategy here.... so.... let's try a different approach.
I can see the files in the /mnt/MOUNT0 directory. The files that I'm concerned with are virtual hard disk files - rather large. Perhaps you could walk me through (step-by-step) the process of ascertaining these files from the other "noise", for example:
"Dear, Pantz. Since the files you are looking for are virtual disks and are more than likely rather large, run the following command to determine the respective size of each file".
That would be a great start.
Then maybe give me a heads up about how to actually verify that the virtual disk is intact.
Do I have to earn your points for you?
I can see the files in the /mnt/MOUNT0 directory. The files that I'm concerned with are virtual hard disk files - rather large. Perhaps you could walk me through (step-by-step) the process of ascertaining these files from the other "noise", for example:
"Dear, Pantz. Since the files you are looking for are virtual disks and are more than likely rather large, run the following command to determine the respective size of each file".
That would be a great start.
Then maybe give me a heads up about how to actually verify that the virtual disk is intact.
Do I have to earn your points for you?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Referred to me as 'mightiness'.
Solution made sense... correctly re-iterated to me that I am simply "f'd".
:(
Solution made sense... correctly re-iterated to me that I am simply "f'd".
:(
It is pretty rare, I think, that this is practical. I've had some success rebuilding things like text files (more common in UNIX than Windows) since I can open them, read them, and maybe know for each fragment how it fits overall. Binary or encrypted files there is little to no chance of manually reintegrating the fragments fsck has left you into the original file.
There may be tools out there to help with this but this situation happens so infrequently to me that I have never been willing to spend money on them. Instead, you will likely have to recover materials from backup or live without if there is no backup.