Call us — 0161 871 0788
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →
Buffalo · NAS & externals

The Buffalo is usually the least of the problem.

Below the interface, a LinkStation or TeraStation is a very small Linux computer. The Linux computer runs conventional RAID software and standard file systems. This means once the disks have been imaged, the appliance itself doesn't matter any more.

LinkStation & TeraStation
EM mode explained
From £500 +VAT
// the short version

Ordinary Linux storage, behind a shut door.

With all the proprietary branding removed, the Buffalo units are standard mdadm arrays using standard XFS or ext. Once the disks have been imaged, everything about the storage is well-documented. The "ugly" aspect of the Buffalo unit is its own proprietary repair tools. It is not the format it writes onto the drives that is the problem.

mdadm
Underlying RAID
XFS/ext
File systems
48 hr
Free diagnostic
£500
From, +VAT
×Do not run a firmware update or a Buffalo “recovery” utility on a unit whose array is degraded. A number of these products reset the array as they restore the appliance. This leaves you with a functional but empty NAS appliance. Take the disk(s) out instead if your data matters.
// the OS lives on the disks

Not in the box.

The most important information to have prior to opening up a failed unit.

Similar to most other types of NAS hardware based upon Linux, Buffalo units store their operating systems in a small area at the beginning of each of the member hard drives; however they mirror them across multiple member hard drives. If you were to lose one of the member hard drives, it would not lose the entire operating system for the device. The enclosure contains a controller board, a power supply and a network connector. The actual software that enables the unit to function as a Network Attached Storage (NAS) device resides on the individual storage devices themselves.

The following two results occur. Do not remove all disks simultaneously: with no disks left to read, the unit has nothing to boot off and therefore cannot "rebuild" back onto replacement disks, which is an easy-to-avoid cause of converting a functioning environment into a recovery operation.

Additionally, when a unit won't boot at all; many times the issue is a storage problem as opposed to a hardware problem — if the system partition(s) on your disks are damaged, even though the unit's hardware is perfectly healthy, the unit will appear non-functional.

// what the symptoms tell you

Ping it, then check the admin page.

These are two tests that determine where the problem lies prior to sending or shipping out equipment.

01

If it answers a ping

This means that the unit has come online, booted its operating system, and has initiated networking — so, the power supply, mainboard, and network hardware are good. The fault exists within the lower layers (storage); however, typically your data will be recoverable.

02

If the admin interface loads too

That's even narrower than before: The array isn't going to form, or the volume won't mount, or the sharing service won't come up with regard to it. Look if it indicates that the array is in a degraded state when you are there.

03

If it does not ping at all

It's not coming online. This can be either the power supply or the motherboard — or the disk partitions where the system lives. That's why this is not always a hardware problem.

04

If it is slow to power on

A lot of times, same fault. A number of units perform a startup check/initialisation of the mounted volumes, and being stalled by an area they can't read can make the unit appear to hang entirely.

// what is underneath

mdadm, LVM, and a standard file system.

That's why these are recoverable.

Buffalo uses normal Linux disk configuration; mdadm for software RAID, commonly LVM over that and either XFS or ext4 depending on the generation and/or model of Buffalo. There's nothing proprietary about it as far as hindering recoverability.

All the disks are therefore imaged read-only. Then they're reassembled into an array from those images using geometry pulled out of the image itself instead of trusting what was provided by the unit that failed to put it together. And then the file system is rebuilt back up from its own backup structures. All traces of the appliance, its firmware and its web interface are completely removed from the equation.

It is also good to take a moment to talk about XFS; it is very reliable and does not keep the same redundant super block copies ext4 has. Therefore when there is damage to one of its main structures, how you go about recovering from that type of damage will be different and the recovery tool sets that were created to work solely with ext file systems will not be able to read your XFS partition.

// what to send

Disks or the unit. Both work.

▤

All the disks, labelled by bay

The order of the bays for reassembly is important. This information can be determined; and having it available can save considerable time. A picture taken prior to removing anything of the front side of the device will provide all the necessary bay numbering information.

Preferred
◉

Or the complete unit

Fine, and sometimes better – because it reduces to zero the chance that the sequence will be lost during shipment, or that a disk was accidentally left in place.

Also fine
⚠

Including any disk it ejected

The "member" of the group marked as failing frequently still has most of its information stored on it; the main difference between partial and total recovery lies here.

Important
✗

Do not reinsert or rebuild first

Reinserting a disk that was ejected could force a resynchronisation in the incorrect direction; rebuilding all remaining members simultaneously would continue for hours with maximum load.

Avoid
// questions

Your questions, answered.

Generally not – and it may not even be a hardware fault. The boxes store the operating system on the member disk(s). Therefore, damage to this will make a healthy box appear dead. In all cases the disks are read outside the appliance.

The unit will fail if you remove all of the members. This is because the operating system resides on a partition of the member disk(s), which are duplicated across the other member disks. Therefore, if all of the member disks are removed, then there is no operational environment for the unit to reboot into. Furthermore, since the unit can't reboot; the unit can't also rebuild itself into new member disks.

The fact that the unit responds to a "ping" means that the unit's operating system has been successfully booted; that the operating system has successfully loaded; and that network access has been activated. Therefore, the problem is located below these levels, in the storage layer. Additionally, the data stored within the unit is typically still present.

In a manner that does not prevent you from recovering your data. The unit uses mdadm for software RAID as well as LVM and XFS or ext4 file systems. Once the drives are cloned, the recovery process is standard. At that point, the unit becomes an irrelevance.

Either. We prefer bay labelled disks, but if you send us a photograph of the front before removing them that is okay too. It doesn't matter whether you send the unit or just the disks; sending the whole unit removes any risk of the disk order being lost.

From £500 plus VAT for multi-disk units after free 48-hour diagnostic. From £300 plus VAT for single-disk models with no array to rebuild.