RAID & NAS · case notes · CDF-2025-0914
Windows Found the Disk and Nothing Else.
A Seagate Personal Cloud in Sully went quiet on the home network. A neighbour who works in IT tried the sensible things in a sensible order: disk out, disk into a USB dock, Windows given that driver everybody recommends for Linux partitions
. No change. The disk shows up fine. There is simply nothing inside it to open.
Windows then offered to initialise it, and he was right to refuse. The older files had been copied elsewhere. The last eighteen months had not.
Does that match yours? Call us.
0800 6890668
Why that happens.
What he had done ruled out the usual suspect: the filesystem was fine. Two other things were not. Start with the disk's behaviour. Some reads answer straight away; others hang and never return, and no ordinary PC knows what to do about it. It sits waiting, abandons the read, then tells you the disk is empty. Then there is the way the box is put together. A home cloud appliance does not lay ext4 directly onto the platters. It puts down its own partitioning, adds its own volume manager above that, and hides the filesystem inside the pair of them. A desktop driver can be reading perfectly sound sectors and recognise none of it.
What we used on this one.
Every step, in order →| The tools | What it did here | Why it helps |
|---|---|---|
| DeepSpar Disk Imager 4 | Kept copying through the stalls that had stopped everything on his own machine | Maps the heads first, works surface by surface, and keeps resets, timeouts and power in hand |
| UFS Explorer RAID Recovery | Peeled apart the layers sitting between the platters and the family's folders | Not just the RAID: it also unpicks the volume layers a NAS stacks on top |
| R-Studio Technician | Checked the rebuilt shares against the list of what the family expected to find | Reads nearly every file system, and rebuilds arrays you can rely on |
How it went.
The same test again, but on proper hardware
The bench saw exactly what he had seen, only with figures attached. Some reads answered in a handful of milliseconds. Others took the best part of thirty seconds, and the two kinds were mixed across the surface, with no obvious logic to which was which. An operating system hands a disk like that two or three retries before it gives up, and that is what both of his computers did.
Hardware that will not give up on it
Timeouts were deliberately set short, and each stall got a reset instead of a step back. That let the sound part of the surface — most of it — come across at a decent rate. Difficult regions were logged and skipped to begin with, then returned to last of all, when nothing readable remained at risk.
Unpick the layers in the order the box built them
From there on the work happened on the image, following the order the appliance had used: partition table first, then the volume manager, with ext4 at the end. Done in that sequence, the shares dropped back into the layout the family knew, and eighteen months of photographs that existed nowhere else were sitting where they had always been.
Signing it off.
Those eighteen months went home on an ordinary external drive, beside the earlier years. Nothing the neighbour tried did any damage — every step of it was read-only, and it narrowed the problem down for us. The answer was imaging hardware plus a decode worked through one layer after another. No amount of software would have reached it. The phones in that house now back up to two places.
Pages people often read next.
The RAID & NAS jobs.
Is that what yours is doing?
Power it down, get it to us, and hold off on any decision until the diagnosis says what can still be read.