For reference, we were using QNAP TS-639 Pro with six WD20EADS disks.
After about half a year of use, the web-interface was running slower, so that we needed to wait for several minutes to obtain the list of the disks. Gradually, we noted that the array performance decreased significantly.
It seemed obvious to assume that one of the member disks has been dropped from the array and a RAID5 was working in the degraded mode. However, all the member disks were marked as GOOD in the web-interface.
It was suspicious that LEDs on the disk bays indicating the state and activity of the disks were blinking unevenly. Logically, for RAID5 one should expect almost symmetric load on the disks, but in fact, one of the disk LED was blinking much more frequently.
Once we had run the bad blocks check on this disk through the web-interface, the disk dropped from the array in less than half an hour and its bay LED turned red. At this point, the web-interface began to work properly again. The disk taken from …
Is it possible for a data recovery software to get a correct file and folder structure but bad file content or vice versa? Why does it happen?
The answer depends on the filesystem type being recovered.
On FAT, the location of the parent folder is determined depending on the same formulae which are used for finding data. If the parameters in these formulae are invalid, neither data nor a folder structure can be restored. Hence, typically if you have a folder tree recovered properly or close to that, the files should be good as well.
On NTFS, there are two independent sets of parameters, one set controlling the data location and the other set covering the parent-child relationships in a folder tree. So on NTFS, it is theoretically possible (and sometimes happens) to have one good set of the parameters but the other one wrong. So, if you unformat an NTFS drive, a good folder tree full of damaged files is perfectly possible.
On HFS and HFS+, the parent-child relationship is described by desig…