RAID & NAS · bench record · BHD-2025-8914
The Disk Was There. The Files Were Not.
A Seagate Personal Cloud in Hall Green stopped answering on the home network. One of the neighbours works in IT, and he did the obvious things in order: disk out, into a USB dock, Windows fitted with the driver everyone points you at for Linux partitions
. Nothing changed. Windows can see the disk. There is just nothing on it to open.
It then offered to initialise the thing, and he had the sense to say no. Everything up to a point had been copied elsewhere. The most recent eighteen months had not.
Sounds like yours? Give us a ring.
0800 6890668
What that means.
His testing had ruled out the one thing everybody blames. The filesystem was not the problem. Two other things were. The first is how the disk behaves: some reads answer at once, others hang and never come back, and software on an ordinary PC has no way of dealing with that. It hangs on, then quits, then tells you the disk is empty. The second is how the box is built. A home cloud appliance does not write ext4 straight onto the platters. It lays down a partition scheme of its own, then a volume manager of its own, with the filesystem tucked inside both, so a desktop driver can be reading perfectly good sectors and still find nothing it recognises.
What did the work here.
The order of the work →| Equipment | The job it did | What it adds |
|---|---|---|
| DeepSpar Disk Imager 4 | Pushed the copy on through stalls that had halted every tool on his own PC | Head mapping first, then one surface at a time, with resets, timeouts and power all governed |
| UFS Explorer RAID Recovery | Separated the layers between the platters and the folders the household used | Reads the volume layers a NAS puts over its array, not only the RAID underneath |
| R-Studio Technician | Compared the rebuilt shares with what the household said should be present | Broad file-system support, with RAID rebuilds that can be trusted |
What we did.
Do the same test again with better instruments
The bench found what he had found, only with numbers attached. Some reads came back in a few milliseconds. Others sat there for half a minute, and the two sorts were scattered across the surface in no pattern we could see. An operating system hands a disk behaving like that a few retries and then walks away, which is what had happened on both of the machines he tried.
Imaging hardware that does not walk away
Timeouts were set short on purpose, and every stall was answered with a reset rather than a retreat. That let the healthy part of the surface — most of it — copy across at proper speed. Awkward regions were noted and skipped on the first pass, then gone back to at the end, by which point nothing still readable was at risk.
Work back down through the appliance's own layers
Everything after that happened on the image, in the order the appliance had built it: partition table first, volume manager second, and the ext4 filesystem last of all. Taken that way round, the shares fell back into the layout everyone at home recognised, and eighteen months of photographs that survived nowhere else turned up exactly where they had always sat.
How it closed.
The eighteen months went home beside the earlier years on an ordinary external drive. Nothing the neighbour did caused any harm — every step was read-only, and it narrowed the problem for us. What solved it was imaging hardware and a decode done one layer at a time. No download would have got there. Their phones now back up to two places.
Other pages worth a look here.
The RAID & NAS cases.
Is yours behaving the same way?
Switch the device off, post it in, and decide nothing until the diagnosis comes back to tell you where you stand.