Case Study
A RAID 0 that wouldn't mount, rebuilt block by block.
A LaCie 2big Thunderbolt 2 with two 3TB Seagate drives in RAID 0, set up for MacOS, stopped mounting entirely. Getting the data back meant working out the array's exact configuration from the raw drives — because none of the recovery software could detect it automatically.
The case
A LaCie 2big Thunderbolt 2, gone silent under MacOS.
This LaCie 2big Thunderbolt 2 arrived in the lab with two 3TB Seagate hard drives installed, configured in RAID 0 and set up for use on Apple MacOS — so we expected to find HFS+, APFS or ExFAT as the file system. In its current state, the enclosure would not mount on MacOS at all.
As with any RAID case, the original drives are never worked on directly. Both drives were mounted in PC3000 as virtual drives with simulated writing, giving safe, on-the-fly access for imaging and analysis without a single write touching the originals.
The diagnosis
Ruling out RAID 1 and JBOD at the hex level.
The 2big Thunderbolt 2 supports RAID 1, RAID 0 or JBOD. With no reliable metadata to read the configuration from, the only way to know for certain was to compare the drives byte for byte.
Both drives were loaded side by side in a hex viewer. The data on them was not mirrored, which ruled out RAID 1 — a mirrored pair would show identical data on both drives. JBOD was ruled out too: the blocks carrying RAID data repeated in the same order and followed the same pattern across the drive, which a simple concatenation of two independent drives would not do.
That left RAID 0 across the two 3TB Seagate drives — the next question was the block size the array had actually been built with.
The rebuild
Finding the one block size that actually worked.
Neither R-Studio, UFS Explorer nor ReClaim Pro could auto-detect the LaCie's RAID configuration from metadata — it had to be built manually, drive by drive, block size by block size.
- 01
Virtual RAID created from both drives
In R-Studio, a virtual block RAID was created and both data sources added — the drive showing a partial file system was set as the first drive, the other as the second, based on what each drive's raw data suggested.
- 02
The default block size failed
Built at the standard 64KB block size, the array came up as raw — no file system detected. A LaCie RAID 0 would typically default to 128KB or 256KB, so neither of those looked promising either.
- 03
The correct size was 4KB
Rebuilding the virtual array at a 4KB block size — well below what the LaCie documentation suggested — brought the file system into view immediately. The MacOS partition and its data became visible and browsable.
- 04
Confirmed and repeated in UFS Explorer
The same drive order and 4KB block size were used to build the array again in UFS Explorer, as a second, independent confirmation. The HFS+ partition mounted cleanly there too, with all user data accessible.
The outcome
Full data access restored, verified before copying.
Before committing to the full transfer, a larger file was opened directly from the rebuilt array to confirm it was intact — in this case a multi-megabyte JPEG, checked in preview to make sure it opened cleanly. With that confirmed, the files and folders were marked and copied off the reconstructed RAID 0.
The lesson from this one: if a LaCie 2big Thunderbolt RAID 0 won't auto-rebuild, don't assume the documented default block size is correct. Build the array manually, with the drive containing a partial file system placed first, and try 4KB alongside the more commonly expected 64KB, 128KB and 256KB options.
Guessing at block sizes on your original drives risks the data permanently. Get it imaged and rebuilt properly by a lab that does this daily.