RAID data recovery services Brisbane hub - RAID 0, 1, 5, 6, 50, JBOD, SAS Drive plus many more

Every member drive is imaged to healthy working storage first, including drives the controller marked failed. Unstable drives get firmware, head or PCB work until they image. The array is then reconstructed in software from the images: drive order, stripe size, parity rotation and start offset are determined and validated against file-system structures. Finally the file system, and any virtual disks or databases on it, are recovered from the reconstructed volume.

RAID recovery is priced per drive, not per array, because every member has to be individually assessed and imaged whether the controller considers it healthy or not. That is the most important thing to understand about the cost: an eight-drive array is a substantially bigger job than a three-drive one, so multi-drive arrays do get expensive. What each drive costs depends on whether it images cleanly or needs physical work such as head, firmware or PCB repair, and on how much reconstruction the array itself needs. This is why the diagnostic is free and why you receive one fixed quote covering the whole job, after every drive has been assessed, with no obligation to proceed. Optional priority fees are the only up-front costs: Standard $0, Critical Priority $715 inc. GST ($650 + GST), Emergency 24/7 $1,400, all in AUD.

Yes, everywhere. Every NAS with two or more bays, most business servers, virtualisation hosts and storage arrays use a RAID level, whether hardware, software or a filesystem-integrated variant such as ZFS RAID-Z or Synology SHR. What has changed is that large drives make rebuilds slow, which pushes larger volumes toward RAID 6 and RAID 10 rather than RAID 5.

Often. With failures inside the array's tolerance the survivors are imaged and the array reconstructed. Beyond tolerance (two failed in RAID 5, three in RAID 6) at least one failed member has to be imaged well enough to bring each stripe back within reach of parity. See the RAID 5 and RAID 6 pages for the detail.

Not until the order is documented. Photograph the bays, label every drive with its slot number, then power down. If the drives must travel out of the enclosure, pack them individually with the labels attached and include the enclosure or controller model.

The RAID level if known, the controller or NAS model, the number and capacity of drives, the original drive order, any error messages, which drive failed first and when, and whether a rebuild, re-creation or repair was attempted. Anything you do not know, we recover from the data.

Yes, Australia-wide. Call before shipping a multi-drive system so the drives, order and enclosure can be documented and packed correctly. A free tracked Express post-in label is included, and free collection is available in the Brisbane area.

Usually yes. RAID 5 stops on the second failure because parity can only solve one unknown per stripe, but "failed" is the controller's opinion, not a physical verdict. In most two-drive cases the first drive dropped out days or weeks earlier and is still largely readable, or was ejected over a handful of bad sectors. We image both failed members, recover as much of each as physically possible, and reconstruct using whichever has the more complete and more current data. The critical thing is what happens before it reaches us: every rebuild attempt after the second failure reduces what can be recovered.

A URE is a sector a drive cannot read back no matter how many times it retries. Consumer drives are typically rated around one URE per 10^14 bits read, which is roughly one per 12.5 terabytes. A rebuild reads every sector of every surviving member, so a large array can approach that threshold in a single rebuild pass. On many controllers a URE mid-rebuild drops a second member and fails the array outright. This is why rebuild is the single most dangerous operation an aged array performs, and why we image first and rebuild in software where a bad sector is a gap to work around, not a fatal error.

Not before the data is secured. A rebuild is a full-surface read of every remaining member at exactly the moment the array has no redundancy left. If a second drive has any weakness, a rebuild is what will find it. If the data matters more than the uptime, image the array first and rebuild afterwards. If the array is already degraded and you have no current backup, power it down and call us: a rebuild that fails part-way is materially harder to recover than one that was never started.

Yes, and they are among the most common units we see. A Synology NAS is generally mdadm RAID with LVM and either ext4 or Btrfs on top, and Synology Hybrid RAID (SHR) splits mismatched drives into multiple partitions that each join a separate array. QNAP and Netgear ReadyNAS follow the same pattern with their own conventions. Recovering the RAID is only the first layer: the volume group and file system above it both have to be rebuilt before files are readable. Avoid the built-in repair wizards, which can write to the array to fix its own configuration.

Almost never. A hardware controller stores the array definition in on-card NVRAM and in metadata written to the members themselves. When the card dies the drives are intact and the layout is still on them, it is just no longer being read. We recover the geometry from the member images directly, so the original controller never needs to work again. Do not fit a replacement card and accept a foreign configuration import: that can write new metadata over the existing definition.

Frequently, yes. Creating a new array over an existing one writes fresh metadata and often a new partition table and file-system header, but it does not overwrite the bulk of the user data, because a create is not a full format. The original file-system structures are usually still present further into the volume and can be located and rebuilt. What determines the outcome is how much was written afterwards, so stop using the array immediately: every subsequent write lands on data that is still recoverable right now.

Label them, but do not panic if you cannot. Knowing the physical bay order saves diagnostic time and cost, so mark each drive with the slot it came from before removing anything. If the order is already lost, it is recoverable: drive order is one of the parameters we determine from the data itself, by testing candidate orders against parity and file-system structures until the reconstruction validates. Never guess an order and write it into a controller to see if it works.

It is driven almost entirely by imaging, because every member has to be read in full and the slowest or most damaged drive sets the pace. A healthy four-drive array images far faster than one with two failing members needing cleanroom work. Larger arrays, drives needing mechanical work in the cleanroom, or nested levels such as RAID 50 and 60 take longer. Critical and emergency options compress this substantially by running around the clock. We give a realistic time estimate with your fixed quote, once we have seen how each member images.

No, and this is the misconception that puts most arrays on our bench. RAID protects against one specific thing: a drive dying. It does nothing about accidental deletion, ransomware, file corruption, a failed controller, fire, theft or a mistaken re-initialisation, because every one of those is faithfully replicated across all members instantly. An array is an availability tool. A backup is a separate copy, and ideally an offline one.

Yes, and it is a large part of what we do. Most business arrays hold a small number of very large files rather than loose documents: VMDKs on a VMFS datastore, VHDX files on a Hyper-V volume, or SQL Server MDF and LDF files. These are the least forgiving of an imperfect reconstruction, because a stripe assembled even slightly wrong yields a virtual disk that mounts and then proves silently corrupt inside. We validate these by mounting or booting the recovered guest and running database consistency checks, not just by confirming the file exists at the right size.

RAID data recovery means extracting files from an array that will no longer present them itself, whether because drives failed, a controller lost its configuration, a rebuild went wrong or the volume was re-initialised. It is a different job from single-drive recovery. Any failed members are repaired and imaged first, then the array’s layout is worked out from the data on those images: drive order, stripe size, parity rotation and start offset. The array is reassembled virtually in software, and the file system, virtual disks or databases are recovered from that reconstruction. The original drives are only ever read, never written to, so the array you send is never altered by the recovery.

The clearest sign is a mismatch between physical drives and drive letters: several disks inside the machine but one large volume in the operating system. On Windows, open Disk Management and look for a single disk far larger than any drive you installed, or use Device Manager, where a hardware array appears as one SCSI or RAID device rather than individual drives. On Linux, cat /proc/mdstat lists software arrays and lsblk shows the members beneath a volume. On a server, reboot into the controller BIOS (usually Ctrl+R for Dell PERC or F8 for HP Smart Array) to see the array definition. A NAS is effectively always a RAID once it holds more than one drive. If in doubt, count the drives: two or more presented as one volume means an array, and it means the drives must never be imaged or recovered individually.

For an array holding data you cannot lose, the honest answer is that no consumer tool is the right first move. Software such as ReclaiMe, UFS Explorer, R-Studio or DiskInternals can rebuild a straightforward array when every member is healthy and readable, and they are reasonable for a lab-imaged copy. The problem is that they run against your original drives. A member that is physically failing will degrade further under the full-surface read these tools perform, and a wrong parameter guess written back is often unrecoverable. Professional recovery is not really a better tool, it is a different order of operations: image every member on hardware imagers behind write blockers, then run the analysis against those images, where a mistake costs nothing and can be repeated. If the data matters, image first, then experiment.

Usually yes. Corruption in an array is rarely random damage across the disks. It is nearly always a structural problem with one specific cause: a stale member re-admitted with out-of-date content, a reconstruction assembled in the wrong drive order or stripe size, a write hole left by power loss mid-write, or damage confined to the file system while the RAID beneath it is intact. Because each has a distinct signature, the fix is to identify which one applies rather than to run a repair tool and hope. We rebuild the array correctly from images and recover the file system from that, which resolves most corruption outright. The important thing is to stop using a volume that is showing corruption: chkdsk, fsck and vendor repair wizards all write to the array, and on a wrongly assembled array they write damage into the very structures needed to recover it.

RAID buys availability, and it charges for it in ways that only become visible when something goes wrong. It is not a backup, so deletion, ransomware, corruption and fire are replicated across every member instantly. Failures are silent: an array runs degraded for weeks while nobody reads the alert email, and the second failure is the one that takes the volume offline. Rebuilds are the most dangerous operation an array performs, because a full-surface read of aged members is exactly when a latent unrecoverable read error appears. Recovery is harder and more expensive than for a single drive, since every member must be imaged and the layout reverse-engineered. There is a hardware dependency too: a controller that dies or is replaced with a different model can leave healthy drives unreadable. Capacity and cost overheads apply on every level except RAID 0, and complexity brings its own failure modes, from stale members to a wrongly re-created array. None of this is an argument against RAID. It is an argument for treating it as an uptime tool with a real backup behind it.