All the disks, labelled by bay
Bay order matters for reassembly. It can be derived, and knowing it saves real time. A photograph of the front of the unit before removal is enough.
Preferred
Underneath the interface a LinkStation or TeraStation is a small Linux computer running conventional software RAID and standard file systems — which means once the disks are imaged, the appliance stops mattering entirely.
Underneath the branding these are standard mdadm arrays carrying XFS or ext, which is thoroughly documented territory once the disks are imaged. The awkward part is the appliance’s own repair tooling, not the format it writes.
The single most important thing to know before touching a failed unit.
Buffalo units, like most Linux-based NAS hardware, keep their operating system in a small partition at the start of the member disks, mirrored across them so that losing one drive does not lose the system. The enclosure holds a controller, a power supply and a network port — the software that makes it a NAS is on the storage.
Two consequences follow. Never remove every disk at once: the unit then has nothing left to boot from and cannot rebuild onto replacements, which is a common and entirely avoidable way to turn a working situation into a recovery job.
And a unit that will not boot at all is frequently a storage problem rather than a hardware one — if the system partition on the disks is damaged, a perfectly healthy box appears dead.
Two checks that locate the fault before anything is sent anywhere.
The unit has powered up, loaded its operating system and brought networking up — so the power supply, board and network hardware are all fine. The fault is below that, in the storage layer, and the data is usually intact.
Narrower still: the array will not assemble, the volume will not mount, or the sharing service cannot start against it. Check whether it reports a degraded array while you are there.
It is not booting. That could be the power supply or the board — or the system partition on the disks, which is why this is not automatically a hardware fault.
Often the same fault. Many units check and mount their volume at startup, and stalling on an unreadable region can take so long the unit appears not to be starting at all.
Which is why these recover well.
Buffalo builds on conventional Linux storage: mdadm software RAID, frequently LVM above it, and XFS or ext4 on top depending on model and generation. None of it is proprietary in a way that obstructs recovery.
So the disks are imaged read-only, the array assembled from the images with the geometry derived from the data rather than trusted from the unit that failed to assemble it, and the file system repaired from its own backup structures. The appliance, its firmware and its web interface are removed from the equation entirely.
XFS is worth a note: it is robust and it does not keep the same redundant superblock copies ext4 does, so damage to its primary structures is handled differently — and recovery tools built only for ext file systems will not read it.
Bay order matters for reassembly. It can be derived, and knowing it saves real time. A photograph of the front of the unit before removal is enough.
Perfectly fine, and sometimes better — it removes any risk of the order being lost in transit or a disk being left behind.
A member the unit marked failed frequently still holds most of its data, and it is often the difference between partial and complete.
Reinserting an ejected disk can trigger a resync in the wrong direction, and a rebuild runs every surviving member at full load for hours.
Usually not, and it may not even be a hardware fault. These units keep their operating system on the member disks, so damage there makes a perfectly healthy box appear dead. Either way the disks are read outside the appliance.
Not all at once. The operating system lives in a partition on the members, mirrored across them — remove them all and the unit has nothing to boot from and cannot rebuild onto replacements.
That the box is working and the storage layer is not. Answering a ping requires it to have booted, loaded its OS and brought networking up, so the fault is beneath that — and the data is usually intact.
Not in a way that obstructs recovery. It runs mdadm software RAID with LVM and XFS or ext4 on top, so once the disks are imaged the reconstruction is conventional and the appliance becomes irrelevant.
Either. Disks labelled by bay are preferred and a photograph of the front before removal is enough. Sending the complete unit is equally fine and removes any risk of the order being lost.
From £500 plus VAT for multi-disk units after a free 48-hour diagnostic, or from £300 plus VAT where it is a single-disk model with no array to reconstruct.