iSCSI volume corrupted data

The only software that I can think of it to recover is R-Studio. R-Studio able to view the iSCSI target as a Volume and restore all files and file paths. I am still puzzle by how the corruption started. You might also want to upgrade your ReadyNAS with latest firmware.

mikemis, can you send me a screenshot(in this thread or private message is fine) of the disk management page from Windows computer management on the system that is connected to the iSCSI target? I want to see what it appears as in windows, and as they say "a picture is worth a thousand words".

http://t.co/yehXF27p

I'm seeing at least 3 different windows clients connecting via iSCSI in the logs, are those all connecting to the same LUN at the same time? Do you also have the ACL support enabled for iSCSI with the IQNs of those clients added to the ACL list on that LUN?

There are 3 different clients, but they never accessed it at the same time. I tried with other clients to see if it was windows' fault on the server. I enabled ACL but not CHAP. Only client in the ACL currently is the server in the screenshot.

Well based off of what you've said, and what's in the logs, there isn't really anything wrong with the system itself, just the contents of the LUN. It also doesn't sound like you were doing anything that might have directly caused the problem(like having multiple clients connected to the LUN at once without ACLs). So it really does sound like a filesystem issue(from the perspective of the system connected to the LUN treating it as a hard drive).

You mentioned that you were able to FTP into the LUN(since it's hosted via IIS), but the windows explorer gui won't browse it. Have you tried checking it via the command prompt?

Can't browse at the command line either. Now can't browse via FTP. Cascading crap storm?

I'm letting chkdsk /r loose on the volume from Windows. Is it bad that it is taking a looooong time at:
Correcting error in index $I30 for file 5.
Correcting error in index $I30 for file 5.

(yes it says so twice)

Unfortunately I'm not familiar enough with chkdsk to be able to answer that. I do know that chkdsk like most filesystem applications(such as fsck in linux) can take quite a while to run if there really is a problem. Now that you have it running, let it be. However I generally run them without having it automatically correct the errors first, then if it shows the errors and they're correctable, re-run it. Or check it with R-Studio like Jedi Knight suggested.

Thanks guys,
I can't stand a process with no feedback so I killed the chkdsk and now I've got the R-Studio demo digging through the drive. 12TB should take about 20 days to dig through, apparently, so I'll be patient. At least I can see something "happening" now though.