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.
PantzAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

turnbulldCommented:
The files in lost+found are analogous to files chkdsk will produce in c:\ when it does what fsck did.  Both tools try to make sense of data on disk when the structure built around that data to manage it as a filesystem is corrupt.  Bits of what appear to be contiguous data are given a new file handle so the user can interact with that data in the hopes that some of it can be recovered.

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.
0
PantzAuthor Commented:
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?
0
turnbulldCommented:
Well, since you asked so nicely and we're here to serve your mightiness....  

The only way to handle this is pretty simple and it is the same as would have to happen with chkdisk files:

1) Open each file
2) Figure out what's inside
3) try to match it to other files.

There is no certain relationship between the lost+found files and the data's former format; they are there because fsck couldn't identify them.  The tool will have found a fragment of a file and no way to figure out where it belongs and assigned it a new file handle.  Your virtual disks are as subject to file system fragmentation as anything else, particularly if they were configured as thin and allowed to grow as space is required.  I'm assuming  by 'virtual disk' you are referring to VMware or something similar since your post history involves  VMware.  If not, please feel free to post another clarification.

As for verification,  you can't get that from the filesystem, you need  to ask VMWare how they validate virtual disks.  I think it likely there is no way to be certain.  I would start with the file system check tools in the guest  OS if you can get the virtual disk rebuilt and the guest to start.  If not, it's easy; the virtual disk is not good.

So, as  I stated  before, you will be better off recovering a backup.  If you don't have an adequate backup, you'll have to learn to live without it seems.

And, with respect to the points, you can shove 'em.  I am by far not the most active person here but I find having the account useful since most folk here are not pissy brats.  There are, clearly, exceptions.   Good luck with this; you're in for an unpleasant few hours at the least and most of us with any time on systems have been there.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PantzAuthor Commented:
Referred to me as 'mightiness'.

Solution made sense...  correctly re-iterated to me that I am simply "f'd".

:(
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.