RAID5 recovery and missing/strange files

[Txema]

Hi there,

I'm having some trouble recovering a damaged RAID5 volume with 3 SCSI disks.

The main problem here is, I've recovered some files (but not all of them) from the RAID volume, but I'm not getting all files that should be there (for example, the windows folder isn't there), but I'm getting some other files that shouldn'nt be there (lots of "\lostfiles00001", "\lostfiles00002", ... folders containing files that either are duplicated (exist in some other well recovered folder) or simply don't exist anywhere else.
Besides, comparing the files in these ghost folders and the place-where-they-should-be folders (i.e.: d:\lostfiles00001\piarch.026 and d:\pidat\piarch.026) reveal they are not identical files.

Furthermore, I've checked the content of the recovered files (in the properly recovered folders) and it isn't ok.


At this point, recovered data is not ok.
As RAID volume was basically unaccesible (read bellow process recovery description) my doubt is: are these \lostfile0001 folders generated by ZAR as part of the recovery process?
If not, this would mean that it has been generated somehow outside ZAR, probably but some "scandisk"-like tool, and maybe it has further corrupted the filesystem, I guess.
Also, could the RAID5 volume got corrupted, and the the cause for this unsuccesful recovered files?


Basically, my problem here is that I don't know if ZAR it's unable to properly recover the damaged files from the RAID5 volume, OR if the data was previously corrupted, and ZAR is properly recovering this corrupted data.
Any way to tell??



FYI, the process I followed to recover the RAID volume is as follows:
- server crashed by electrical problem, couldn't boot again, and it was too old to get spare parts. RAID controller seemed damaged too
- client performed some testing to check RAID controller / RAID volume state (no further info available about this testing). Supposedly, controller was ok as well as RAID volume
- we verified RAID controller status on a new server. Although (supposedly) booting ok and not finding the disks (not connected at this point), any attempt to access the RAID controller BIOS menu froze the computer. Diagnostic: controller ko
- got an extra RAID controller through Internet, connected the disks, got it to work, and connected the whole think to a Windows XP system to perform file recovery
- Windows XP couldn't recognize the filesystem "as is"
- performed a byte-per-byte copy of the RAID volume with "zlon" utility, as a basepoint for recovery. Any further ZAR analysis will be performed over the image, not directly through the physical RAID volume
- at this point, then we used ZAR. Partition table was unknown/damaged, so we proceeded with partition scan through the disk. Armed with some basic previous knowledge about the partition table, we finally proceed to the file recovery


Any input would be appreciated.
Thanks,


--
Josep

[Alexey V. Gubin]

There are two significantly different approaches.

1. You try to reconstruct the RAID yourselves. When done, you use ZAR to recover data from what you assembled. This one is described here
http://www.z-a-recovery.com/unformat-tutorial.htm

2. You give ZAR the just set of separate disks, not associated into the array. ZAR then first figures out the array layout, then performs a data recovery.
Corresponding illustration is at http://www.z-a-recovery.com/raid-recovery-tutorial.htm
(http://www.z-a-recovery.com/raid-recovery-tutorial.htm)
The question "Who is responsible for the array reconstruction?" distinguishes between (1) and (2).

Based on your description,
got an extra RAID controller through Internet, connected the disks, got it to work, and connected the whole think to a Windows XP system to perform file recoveryI cannot tell which of the two methods you used.

In case you assembled an array, chances are you got the array layout wrong. The correct method would be (2), i.e.

Connect disks separately, rather than rebuild a RAID array, and then use ZAR to try and detect array configuration.

If you did exactly that, I'd like to see a part of the log file (C:\Program files\ZAR\logfile.txt) around the string "layout scores". About 20 lines up and down from that point would be sufficient to start with.

[Txema]

Hi Alexey,

thanks for your answer.

Actually, I've reconstructed the RAID by myself. The reason is, when I got the new RAID controller, surprisingly had the same problems than with the old controller (lock-ups when entering RAID controller BIOS menu, ...).

It turns out that the controller is so old, that I doesn't work properly on modern motherboards. I had to get and old Pentium III 800Mhz computer, and then both controllers (the old one and the "new" one) got to work properly. I just said that I got a new controller to simplify my explanation.

Using then the old controller, which kept the RAID volume configuration, meant no RAID5 rebuilding was necessary, so RAID volume corruption should not be the case. Actually, I was expecting that it would simply be a matter of hooking everything up and I would be able to access all the partitions and folders/files on the RAID volume. Unfortunately, that was not the case.

Let me get the logfile which is in other computer, and I'll post here.

Thanks.

[Alexey V. Gubin]

Make a record the current physical configuration of the array. You need to label drives, ports, and cables. This ensures you can reassemble the array exactly as it is now (which is not necessarily a correct configuration, but still worthwhile).
Then make a record of a current controller BIOS state as detailed as possible.
Connect the drives separately (or make a change in a controller config to create several JBODs instead of a single RAID array).
After this, run ZAR and make it try to rebuild the array configuration.
This either makes sure the array is assembled correctly, or discovers the inconsistency in data, should there be any.