iSCSI volume corrupted data

[mikemis]

I have a ReadyNAS Ultra 6 with 6 3-TB drives in RAID 5 for a total of 16740 GB of usable space.
I have configured one iSCSI target of size 13000 GB.
I connect to the target with a Windows Server 2008 R2 iSCSI initiator and windows shows a disk of size 12999.87 GB.
I use this iSCSI disk in windows as the root of an IIS FTP site.
I can connect to the site with an FTP client and DL/UL SOME files. (some directories are showing as corrupted)
On the server, Windows Explorer complains that the entire drive is corrupted and unusable.

How do I fix this? I have a year worth of work-related files on the iSCSI disk.

[Jedi Knight]

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.

[Grievous]

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".

[mikemis]

http://t.co/yehXF27p

[Grievous]

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?

[mikemis]

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.

[Grievous]

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?

[mikemis]

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

[mikemis]

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)

[Grievous]

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.

[mikemis]

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.

[TeknoJnky]

hoep your data turns out ok, but it underscores the importance of backups

[Grievous]

Yes, backups are always crucial. Of course you never seen to need the backup until you run into a situation where one wasn't available, and when you have a backup it seems you never need to use it. That's just how it goes I guess.

Yes, applications like these can take a very very long time to run.