Group-based filesystems and JBODs.

As of now, there is no automatic recovery of JBOD parameters. At least, I'm not aware of any automatic software that really works.

With a filesystem which stores its metadata all in one place and close to the start of the partition, like FAT or NTFS, you only get the data from the first JBOD member. All the files on the second and further members is lost.

However, with a group-based filesystem, like Linux EXT-series, you can get much of the data by just feeding JBOD members to the data recovery software in turn. In group-based filesystems, metadata is spread evenly across the partition, and file contents are put close to their corresponding metadata. So, if you scan separate JBOD members and then combine the results (skipping empty files and correcting for a loss of folder tree), you can get most of the files out. You cannot recover files which have contents and metadata on two different JBOD members, and also parent-child relationships crossing the disk boundary will be lost. Still, this is much better than NTFS or FAT behavior.

NETGEAR ReadyNAS

Q: What is the best feature of NETGEAR ReadyNAS?

A: A carrying handle at the back of the unit.

Ease of setup? There isn't one.

Performance? We got, like, 3MB/sec out of it. The network is Gigabit Ethernet, serverd by D-Link switches. Not a best thing there is, but QNAP manages to pump data at least ten times faster on the same network.

What model? ReadyNAS NV+ v2.

Overall impression? Not quite good.

Fake hard drive

Now there is a fake of the rotational hard drive. OK, we've seen fake flash already, but this one is new

Note the nuts and bolts added so that weight and balance match the original. The only way you can quickly tell there is something fishy about it, is to plug it into USB - it does not actually spin up because there is nothing to spin.

When is the image file of the entire RAID array useful?

Creating an image might be useful if one of these conditions are met

1. The drives are connected via USB and power failures occur often. ReclaiMe + RAID recovery pair operates using "disk paths", and paths for USB drives may change on reboot. So you will need to redo the RAID part every reboot.
2. One of the RAID member disks has a bad sector, or is otherwise damaged. In this case, it is best to create an image of the suspect disk first, even before you start with RAID recovery.
3. The filesystem on the array is damaged, and you want to try some other data recovery tool on it.

Other than that, the image of the whole array is a waste of disk space. With a large array, you have to be careful what you are placing the image file onto. You should be acutely aware of the image file size. While most filesystem specifications say 12TB single file is acceptable, you will find that in practice, there is a limited set of configurations which accept files that big. By the way, this is where ReFS comes in handy even though it is still in beta.

QNAP reboot

Always remember that

as the uptime grows, the chance of not being able to restart susccessfully increases.

That is, unless you take some special precautions.

Had an UPS fail on our QNAP, like a couple of days ago. Before that, the uptime was something like several months. Lo and behold, the QNAP failed to come back online. It just sit there "SYSTEM BOOTING >>>" with all the drive LEDs blinking, no ping, nothing, and looked very much like a power supply failure. However, all the LEDs were blinking, and generally it look very busy doing something for about 30 hours I let it sit. When I finally get around to connect a VGA to it, there was nothing to be seen.

Then, a couple of hard reboots took care of the problem, at least for the time being.
Looks like next time the PSU has to be replaced.