WD My Cloud Data Recovery
WD My Cloud NAS data recovery for single-bay My Cloud, EX2 Ultra, EX4100, PR2100, and PR4100 units. We recover data from OS 5 firmware bricks, red LED failures, and inaccessible network shares. Single-bay units use a standard EXT4 drive; multi-bay units use Linux mdadm RAID with EXT4. Free evaluation. No diagnostic fees. All work performed in-house at our Austin, TX lab. Single location, no franchises, no outsourcing. No data = no charge.
Looking for WD My Cloud Home recovery? If your files appear as random hexadecimal strings, your device uses a proprietary Android/SQLite architecture, not standard Linux RAID. See our WD My Cloud Home recovery page for the correct process.
WD My Cloud Recovery at a Glance
We recover WD My Cloud drives in-house at our Austin, TX lab: each disk imaged through a hardware write-blocker, then the mdadm array metadata parsed & the EXT4 volume reconstructed offline from the clones. Free evaluation, no diagnostic fee, no data no charge, nationwide mail-in, single location, no outsourcing.
- Single-bay My Cloud
- One disk, no RAID. We image the drive through a write-blocker & mount its EXT4 partition read-only from the clone. That is the short path.
- Multi-bay EX2 Ultra, EX4100, PR2100, PR4100
- We image every member drive, read the mdadm superblocks, reassemble the array read-only, then mount the EXT4 volume. It is the same imaging-first NAS data recovery workflow we run across Linux-based units.
- Commercial terms
- Free evaluation, no diagnostic fee, and no data means no charge. Every drive is imaged before any array is assembled, because a NAS array is availability, not a backup.
- How to start
- Power the unit down, start a case for a free evaluation, then ship the drives to the Austin lab through our nationwide mail-in service.
What Are the WD My Cloud Product Lines?
WD My Cloud splits into two architectures. Single-bay personal cloud units hold one WD Red or Blue drive on a standard EXT4 partition with no RAID. Multi-bay models (EX2 Ultra, EX4100, PR2100, PR4100) run Linux mdadm software RAID over EXT4. Recovery differs accordingly: single-drive imaging versus full array reconstruction.
| Models | Architecture | RAID | Recovery |
|---|---|---|---|
| Single-Bay My Cloud | A standard WD Red or Blue drive inside an enclosure with a network interface (not USB). The drive has a Linux partition layout with EXT4 data volumes. | No RAID. | Remove the drive, connect through a write-blocker, and mount the EXT4 partition. If the drive has mechanical issues, it follows our standard hard drive recovery workflow. |
| Multi-Bay My Cloud: EX2 Ultra, EX4100, PR2100, PR4100, DL2100, DL4100. 2-bay or 4-bay. | Filesystem is EXT4. | Linux mdadm software RAID. RAID 0, 1 (2-bay); RAID 0, 1, 5, 10, JBOD (4-bay). | Image each member drive, reconstruct the mdadm array, and extract the EXT4 volume. Same workflow as other Linux-based NAS recoveries. |
What Are Common WD My Cloud Failure Modes?
WD My Cloud failures cluster into four patterns: the forced OS 3 to OS 5 firmware migration that bricked many units with a solid red LED, failing WD Red drives in 5-to-8-year-old enclosures, mdadm RAID drops on SMR WD40EFAX members, and network shares going dark after WD retired legacy cloud relay services. In every case the data stays on the drive.
| Failure Mode | What Happens | What It Means for the Data |
|---|---|---|
| OS 5 Firmware Brick | WD pushed a forced migration from My Cloud OS 3 to OS 5 that bricked many units. Symptoms include a solid red front LED, the dashboard reporting "Drive not found," or the unit entering a boot loop. | The internal drive is unaffected by the firmware failure; OS 5 runs on a separate system partition. |
| Red LED on Front Panel | A solid or blinking red LED indicates a system error. This can be a firmware issue, drive failure, or thermal shutdown. | Do not factory reset the unit, as this erases the partition table and RAID metadata. |
| Drive Failure in Aging Units | Many My Cloud units ship with WD Red drives that are now 5 to 8+ years old. SMART errors, clicking, and slow response are common. | These drives need professional imaging with retry control before data extraction. |
| Network Inaccessible After Cloud Service Shutdown | WD discontinued My Cloud remote access for older OS 3 units. | If your My Cloud is not accessible on the local network, the data is still on the physical drive. It has not been erased by the service shutdown. |
Do not factory reset. A factory reset on a My Cloud erases the partition layout and RAID configuration. Remove the drive(s) and contact us.
Does WD My Cloud Use Hardware Encryption?
WD My Cloud NAS units store data as standard EXT4 or mdadm RAID without bridge-chip encryption. WD My Book and My Passport USB drives use JMicron JMS561, JMS538S, or Symwave SW6316 bridge chips that enforce AES-256 at the PCB level, active even with no password set.
WD My Book and My Passport USB external drives use JMicron JMS561, JMS538S, or Symwave SW6316 bridge chips that enforce AES-256 encryption at the PCB level. The encryption is active even if the user never set a password.
Removing a My Book drive and connecting it directly via SATA yields ciphertext, not readable data. This is different from WD My Cloud NAS units, which store data as standard EXT4 or mdadm RAID without bridge-chip encryption.
Recovery for My Book bridge failures requires either repairing the original bridge PCB or recovering the original encryption key material to decrypt the imaged drive.
How the Bridge Chip Encrypts Data Transparently
The USB-to-SATA bridge chip sits between the host controller and the physical hard drive. It generates a Data Encryption Key (DEK), typically stored redundantly in both the bridge board EEPROM and hidden sectors on the drive itself.
Every block written to the drive passes through the chip's AES-256 cipher. The user never sees the encryption because the bridge decrypts automatically on read. When the bridge fails, the drive looks unreadable rather than encrypted, which leads users to attempt destructive recovery steps.
- JMicron JMS561
- Dual-SATA bridge used in WD My Book Duo USB external drives. Configured from the factory in RAID 0 with hardware AES-256 permanently active. The wrapped key is held in more than one place, so a destroyed bridge board does not by itself take the decryption path with it. Not present in WD My Cloud NAS units.
- JMicron JMS538S
- Single-drive bridge used in WD My Book and My Passport USB external drives. Applies AES-256 transparently even with no user password. Shucking the drive yields ciphertext on every sector. Not present in WD My Cloud NAS units.
- Symwave SW6316
- Alternative bridge chip found in some WD enclosure generations. Same AES-256 behavior: encryption is on by default and direct SATA attachment produces ciphertext. On these designs the wrapped key is held in the drive's Service Area as well as the bridge EEPROM, which is where we read it from.
Recovery Path for Bridge-Encrypted Drives
For WD My Book and similar USB external drives with bridge-chip encryption, we address decryption at the board level. The first step is imaging the drive through a write-blocker to preserve the current sector state.
If the original bridge PCB is intact but the enclosure logic has failed, we repair the PCB using microsoldering equipment (Hakko FM-2032 on FM-203 or FX-951 base, Atten 862 hot air rework station) to restore the bridge chip's power and data paths.
If the PCB is beyond repair, what decides the outcome is the key material. When no user password was ever set, the key-encryption key derives from a factory default, which is why a same-model donor bridge reads some units outright.
When that path does not produce readable data, we recover the key itself, from the original bridge controller's firmware or EEPROM or from the redundant copy in Service Area modules on the drive, and decrypt the imaged drive with it. Possession of the correct key determines a readable result, not board parity.
3.3 V power-pin warning: White-label WD drives pulled from enclosures often use the SATA 3.3 V power disable (PWDIS) feature on Pin 3. Connecting them to a standard ATX power supply prevents the drive from spinning up entirely.
Users often misdiagnose this as a dead drive. Before attempting any recovery, verify that Pin 3 is not supplying 3.3 V, either by using a molex-to-SATA adapter or by taping the pin.
WD My Cloud Hardware & Firmware Failure Details
WD My Cloud enclosures use logic boards with Marvell Armada ARM or Intel Pentium CPUs that are separate from the internal hard drives. A failed enclosure board can block access to your data, the same way a firmware fault, drive failure, or thermal shutdown does. We bypass enclosure failures by extracting the drives and imaging them directly via PC-3000.
SMR Drive Complications in EX2 & EX4 Arrays
Some WD My Cloud multi-bay units shipped with WD Red WD40EFAX drives. These use Drive-Managed Shingled Magnetic Recording (DM-SMR), where overlapping magnetic tracks require entire zones to be rewritten on any modification.
During an mdadm RAID rebuild, the heavy write load overwhelms the drive's SMR Translation Layer. The drive pauses for 30 to 60 seconds to perform background garbage collection, which exceeds the Linux kernel SCSI command timeout that defaults to 30 seconds.
The controller interprets the stall as a hardware failure and drops the drive from the array. Attempting another rebuild on the remaining SMR hard drive risks a dual-drive failure state. We image SMR drives sequentially with custom timeout parameters on PC-3000 to prevent Translation Layer lockups.
That ejection is what leaves the unit sitting in a degraded NAS storage pool, with a member marked failed even though the drive stalled rather than died.
WD40EFAX Firmware: Module 190 T2 Translator Corruption
When a WD40EFAX drive is overwhelmed during a NAS RAID rebuild or unexpected power loss, the second-level dynamic translator (Module 190 in the Service Area) can become corrupted. A corrupted T2 translator causes the drive to return sectors filled with zeros even though data physically remains on the platters. The drive reports the correct capacity & passes basic SMART checks, but every read returns blank data.
We address this using PC-3000: lock User Area writes to prevent further firmware background updates, back up Module 190 via ABA mode, then run a Shingle Read procedure to rebuild the T2 translator from the physical SMR bands. Once the translator is rebuilt, the drive surfaces its original sector mapping & standard imaging can proceed. This failure is specific to WD SMR translator corruption & doesn't affect CMR drives (WD40EFRX) in the same enclosure.
JBOD to RAID Configuration Overwrites
Changing a multi-bay My Cloud from JBOD to RAID 1 (or vice versa) through the dashboard is immediately destructive. The system overwrites existing mdadm superblocks and formats a new EXT4 filesystem, destroying volume metadata & inode tables from the previous layout.
If a RAID 1 mirror desynchronizes from sudden power loss, mdadm registers mismatched event counts between drives. Blindly rebuilding overwrites healthy data with stale sectors from the dropped drive. We parse the mdadm event logs to identify the most current member, then extract data from that drive only.
OS 3 to OS 5 Migration: Partition Layout
The forced migration from My Cloud OS 3 to OS 5 replaces the root filesystem partition but leaves the EXT4 user data volume (mounted as Volume_1 on single-bay units, or /dev/md0 on multi-bay) intact.
Data loss from OS 5 bricking occurs when users attempt a 40-second pin reset or force a firmware downgrade with unauthorized .bin packages, which overwrite the partition table. We manually parse partition boundaries & mount the surviving EXT4 superblocks in a read-only Linux environment to extract data offline.
The Linux Partition Layout: System, Config & Data Are Separate
WD My Cloud firmware lays each drive out as several small Linux partitions (the embedded operating system, a configuration partition, and swap) plus one large EXT4 partition that holds your files.
The operating system and the configuration that maps your shares live on the small partitions. Your data lives on the big one. They are physically separate regions of the disk.
On multi-bay units (EX2 Ultra, EX4100, PR2100, PR4100) those small system and config partitions are themselves mirrored across every bay with mdadm RAID 1, while the user data sits on a separate mdadm volume (RAID 0, 1, 5, 10, or JBOD depending on your setup) formatted EXT4. The management OS reads from the mirrored system partitions; the files you care about ride on the data volume.
This split is why a failed firmware update or a corrupted config partition desyncs the management OS without touching your files. The unit reports "Drive not found" or shows a solid red LED because the system partition it boots from is damaged, yet the large EXT4 data volume stays whole. The firmware lost track of the data; it did not erase it.
This is the same separation that lets us pull the drives and read the data volume even when the unit will not boot.
Why a Member Drive in a USB Enclosure Won't Mount
Pulling a My Cloud drive and plugging it into a USB-to-SATA dock on a Windows or Mac desktop does not show your files, and there are two distinct reasons depending on the unit.
First, the data partition is EXT4, the native Linux filesystem. Windows and macOS can't read EXT4, so they report the disk as RAW or unallocated and pop up a dialog offering to format it.
Accepting that format is destructive: it overwrites the EXT4 superblock and the partition table, which is the metadata a recovery actually depends on. The data was there until that click.
Second, on a multi-bay unit each drive is an mdadm component, not a plain partition. It carries its own mdadm superblock, and depending on the metadata version the EXT4 filesystem can be offset from the start of the partition rather than beginning at sector zero.
The correct path is to assemble the array with mdadm first, then mount the resulting data volume. On a striped or parity set a single member on its own is a fragment, not a mountable disk.
This is a different failure from the WD My Book bridge-chip case covered above. A My Book drive on SATA returns AES-256 ciphertext because the bridge was encrypting every block on its way to the platters. A My Cloud member returns readable EXT4 once the array is assembled; nothing on the platter is encrypted unless you enabled software volume encryption in the dashboard.
RAW-on-Windows is a filesystem-visibility problem; ciphertext is an encryption problem. Don't treat them the same way.
Imaging First, Then mdadm Reconstruction From the Clones
We never assemble a My Cloud array on the original drives. Every member is imaged first through a hardware write-blocker (PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager, with ddrescue for healthy members), so the source disks are read once and never written to. All reconstruction happens against the clones.
From each clone we read the mdadm superblock to recover the parameters the array needs: the member's role in the set, the chunk size, and the data offset. Read-only, on the clones, never the originals:
# READ-ONLY. Run against sector clones, never the original drives.
# Read each member's superblock: role, chunk size, data offset
mdadm --examine /dev/loop0 /dev/loop1
# Assemble the array read-only from the CLONES
mdadm --assemble --readonly /dev/md0 /dev/loop0 /dev/loop1
# Mount the EXT4 data volume read-only
mount -o ro,noload /dev/md0 /mnt/mycloudThe two mdadm commands are not WD-specific: a multi-bay My Cloud stores its array on the same Linux software RAID a ReadyNAS or a TeraStation does, so mdadm superblock recovery & read-only assembly is the same work at the md layer on all three. The mount step is where they diverge: a TeraStation puts XFS over md, and a ReadyNAS puts either LVM and EXT4 or Btrfs over it, depending on the OS generation.
When superblocks are damaged or the JBOD-to-RAID overwrite destroyed the metadata, we reconstruct the array virtually in Data Extractor Express RAID Edition (the ACE Lab RAID software that runs on the PC-3000 Express), which destripes the member images and recovers the layout when mdadm alone can't assemble it.
Either path mounts the EXT4 volume read-only and copies your files off. The original drives stay untouched the entire time, because a NAS rebuild is availability, not a backup, and the imaging-first rule is what keeps a second mistake off the table.
How Does the My Cloud OS 3 vs OS 5 Firmware Split Change Recovery?
It does not change where your files live. OS 3 is end-of-support per-unit firmware; OS 5 is the unified account platform, and the OS 3 to OS 5 upgrade is irreversible. Both run on small system partitions that are physically separate from the EXT4 data volume, so a firmware-layer failure damages the system partition the unit boots from, not the EXT4 or mdadm data holding your files.
A firmware failure and a disk failure are not the same event. The management OS, the config that maps your shares, and swap all sit on small partitions. Your files sit on the large EXT4 data volume.
A forced OS 5 migration that bricks the unit, or a corrupted config partition that trips a red LED, corrupts the system partition the box boots from and leaves the data volume whole. That separation is what lets us pull the drives and read the data even when the firmware will not load.
How the Layers Map to Your Model and Firmware
- Single-bay My Cloud
- One disk carrying small Linux system, config, and swap partitions plus a single large EXT4 data partition. There is no RAID. We image the disk and mount the EXT4 partition from the clone.
- Multi-bay EX2 Ultra, EX4100, PR2100, PR4100
- The system and config partitions are mirrored across every bay with mdadm RAID 1, while user data lives on a separate mdadm volume formatted EXT4. On a striped or parity data volume (RAID 0, 5, or 10) a single member is a fragment, so the array has to be reconstructed from the imaged clones before the EXT4 volume mounts; a RAID 1 mirror instead leaves a complete EXT4 filesystem on each member.
- My Cloud OS 3
- The older per-unit firmware generation, now end-of-support. Data still sits on the same EXT4 or mdadm layout, so an OS 3 unit that will not boot is recovered the same way as any other My Cloud: image the drives, mount the data volume offline.
- My Cloud OS 5
- The unified account firmware. The upgrade from OS 3 is irreversible, so a unit that bricked mid-migration cannot be rolled back to OS 3 to recover it. The bricked state is a system-partition problem, not a data-volume problem; the EXT4 data is untouched.
If you are here because shucking a WD drive returned unreadable data rather than a boot problem, read our My Cloud hardware encryption breakdown on why a My Book or My Passport member yields AES-256 ciphertext over SATA while a My Cloud member does not.
A firmware-layer failure is not the same as a security exposure. If you landed on this page chasing a published vulnerability rather than a bricked unit, our CVE-2025-30247 advisory covers that flaw separately from the benign mount failure described above.
Where Does a My Cloud Store Its RAID Geometry?
On the member drives. A multi-bay My Cloud records how its array is put together in the mdadm superblock written to each disk, so member ordering, RAID level, chunk size, parity layout, array UUID, data offset, and the event counters that show which member dropped first all survive the enclosure. A dead main board takes away the machine that was reading that description; it does not take away the description.
A My Cloud EX2 Ultra, EX4100, PR2100, or PR4100 runs stock Linux software RAID under WD firmware, and Linux software RAID keeps its array description on the member disks. Reconstruction is a software problem once the members are imaged.
mdadm Superblock Fields That Define the Array
Reading the superblock read-only from each clone with mdadm --examine returns the parameters an assembly needs. Nothing in that list is held by the enclosure.
| Superblock field | What it settles during reconstruction |
|---|---|
| Array UUID | Which disks belong to the same set. Drives from two different My Cloud units mixed in one shipment sort themselves out on this field alone. |
| Device Role | Which slot a member occupied. Bay order written on the chassis label is not what the assembly trusts; the role recorded per member is. |
| RAID level and layout | Whether the volume is a mirror, a stripe, or parity, and for parity sets how the parity rotates across the members. |
| Chunk size | How many kilobytes land on one member before the write moves to the next. Get this wrong and the assembled volume produces files that decode partway and then turn to noise. |
| Data offset | Where the payload starts behind the metadata, which is the boundary the EXT4 filesystem is measured from. |
| Event counter | How current each member is. A member that dropped weeks before the array stopped carries a lower count, and that is the one we exclude from the assembly rather than let it overwrite current data. |
Where that superblock sits depends on the metadata version, which is why locating it is the first step rather than an assumption. Versions 0.90 and 1.0 are stored at the end of the device with the data payload at offset 0. Version 1.1 sits at the absolute start. The modern default, 1.2, sits 4 KiB from the start with the payload at a calculated offset. Treating every superblock as an end-of-disk structure is how a search for the filesystem ends up hundreds of megabytes off target.
Chassis Swap Rewrites the Array Metadata
The advice that circulates on support forums is to buy a working enclosure of the same model and move the drives across. That works when the only thing that failed was the chassis power supply. It goes badly when the original crash was logical, because the next step a NAS dashboard offers for an unfamiliar set of drives is a write.
Any dashboard option that offers to take ownership of an unfamiliar set of drives, up to and including a factory restore, asks the NAS OS to write new array metadata. A freshly written superblock recomputes the data offset, so the boundary the EXT4 filesystem was measured from moves, and the original description of the array is no longer on the disks to read. An enclosure failure that would have been a straight imaging job becomes a hunt for filesystem structures with no map to check them against.
On our side the equivalent destructive Linux operation is mdadm --create, and it never runs against original media here. Assembly happens on clones, read-only, after the superblocks have been read and recorded. If the geometry has to be derived because the metadata is already gone, that derivation runs against images too.
Dead Board Cases and Failing Member Cases Diverge at Intake
Both start the same way, with a write-blocked sector image of every member, and only one of them ends there. A dead main board leaves healthy disks whose only problem is that nothing is assembling them, so imaging is a clean sequential pass on a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager, and the work that matters happens afterward at the md layer.
A failing member is a media problem and gets handled as one. Read timeouts, retry limits, and pass ordering are set per drive before the imaging starts, weak areas are deferred rather than hammered, and array assembly waits until the image is complete enough to trust. Assembling first and imaging later is how a marginal drive turns into a mechanical case mid-job. Where superblock metadata was destroyed before the drives reached us, the geometry gets derived from the member images in Data Extractor Express RAID Edition instead of read from disk.
A third intake case is not a failure at all. Western Digital ended support for the pre-OS 5 My Cloud generations on April 15, 2022, which removed remote access and mobile app connectivity for those units. A My Cloud in that state looks dead from a phone while the hardware runs, the EXT4 volume is untouched, and the shares still answer on the local network. Check the unit by IP address before assuming the disks are the problem.
My Cloud Home Stores Files as Hex Content IDs
My Cloud Home and My Cloud Home Duo are a different architecture from the classic My Cloud NAS described above, and the difference shows up after the image is already in hand. User files are stored under machine-generated hexadecimal content identifiers with the original names, extensions, and folder hierarchy stripped out. The mapping back to real names and paths lives in a separate SQLite index database, index.db, on the drive itself.
An image of a Home drive is therefore readable and semantically useless at the same time: millions of hex-named objects with no extensions and no directory tree. Making it usable means parsing that database and re-mapping the objects back to their names and parent folders. The Home Duo carries the same framework across two drives, defaulting to a mirror and user-configurable to a striped or spanned layout, so how many members the offline rebuild needs depends on which mode the owner picked.
That is a separate workflow from mdadm superblock reading, and it has its own writeup on the My Cloud Home recovery page. Multi-bay classic units stay on the array path shared with the rest of our Linux NAS recovery work.
How We Recover Data from a WD My Cloud
Recovery depends on the unit type. Single-bay My Cloud is a single-drive EXT4 case: we image the drive through a write-blocker and mount the partition read-only. Multi-bay units (EX2 Ultra, PR2100, PR4100) require imaging every member, capturing the mdadm superblocks, reconstructing the RAID array, and extracting the EXT4 volume from the virtual disk.
- Free evaluation: We identify your My Cloud model, determine whether it is single-bay or multi-bay, check for RAID configuration (EX2 Ultra defaults to RAID 1), and document the failure symptoms.
- Drive removal and imaging: We remove the drive(s) from the enclosure and image through a hardware write-blocker using PC-3000 or DeepSpar. Single-bay drives with mechanical issues receive head swaps if needed.
- Array reconstruction (multi-bay only): For EX2 Ultra, PR2100, PR4100, and similar multi-bay units, we capture mdadm superblocks and reconstruct the RAID array from cloned images.
- EXT4 extraction: Mount the EXT4 data partition (single-bay) or the EXT4 volume from the reconstructed array (multi-bay). Extract files and verify.
- Delivery: Recovered data copied to target media and shipped. Working copies purged on request.
How Much Does WD My Cloud Data Recovery Cost?
Single-bay My Cloud recovery is priced as a standard single-drive case. Multi-bay units (EX2 Ultra, PR2100, PR4100) use two-tiered pricing: per-member drive imaging billed by drive condition, plus an array reconstruction fee for mdadm RAID rebuilding. No data = no charge.
Single-Bay / Logical
EXT4 extraction from a healthy or firmware-damaged drive
$250–$900
Multi-Bay Reconstruction
mdadm RAID + EXT4 extraction from EX2/PR series
$400-$800
Per-member drive imaging billed separately based on drive condition.
Mechanical (Head Swap)
Clean-bench donor transplant for clicking or non-spinning drives
$1,200–$1,500
No Data = No Charge. If we cannot recover usable data from your WD My Cloud, you owe nothing.
Donor drives & rush service: Mechanical recoveries (head swap) require a matching donor drive, billed separately at market value. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. Need it faster? A +$100 rush fee to move to the front of the queue.
My Cloud member drives are standard hard drives, so per-member-drive imaging follows the canonical HDD tiers below. On a multi-bay EX2 Ultra, PR2100, or PR4100, the array reconstruction fee is quoted on top of the per-disk imaging for each drive that needs it.
The same quote structure covers any multi-bay NAS we take in, so NAS data recovery cost on a Synology, QNAP, or Buffalo array moves with the number of drives that need imaging, the way an EX2 Ultra job does.
- Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
- Low complexity
File System Recovery
Your drive isn't recognized by your computer, but it's not making unusual sounds
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
From $250
2-4 weeks
- Medium complexity
Firmware Repair
Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
- High complexity
Most Common
Head Swap
Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
- High complexity
Surface / Platter Damage
Your drive was dropped, has visible damage, or a head crash scraped the platters
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
$2,000
4-8 weeks
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
The prices above are for standard hard drives, which covers most jobs. Helium-sealed drives (for example WD or HGST Ultrastar He and Seagate Exos X) must be resealed and refilled with helium in-house after the chamber is opened, so they price higher, in the $200–$5,000+ range. See helium drive pricing.
WD My Cloud Recovery FAQ
Can you recover data from a WD My Cloud?
Can you recover data from a WD My Cloud bricked by the OS 5 update?
What is the difference between single-bay and multi-bay My Cloud recovery?
What RAID configuration does the WD My Cloud EX2 Ultra use?
My Cloud remote access is down but my data was local. Is it still on the drive?
Why did my WD My Cloud EX2 fail during a RAID rebuild?
I switched my WD My Cloud from JBOD to RAID 1 and lost data. Can you recover it?
Does volume encryption on the EX2 Ultra, PR2100, or PR4100 affect data recovery?
Can recovery software help if my WD My Cloud is not accessible on the network?
Can I remove the drive from my WD My Cloud enclosure and read it directly via SATA?
Does my WD My Cloud have hardware encryption even though I never set a password?
What is the difference between WD My Cloud volume encryption and bridge-chip encryption?
My WD My Book bridge board is dead. Can the AES key still be recovered?
Why does my WD My Cloud say 'Drive not found' but the data is supposedly fine?
I put my WD My Cloud drive in a USB dock and Windows wants to format it. Is my data gone?
How do you reconstruct the mdadm array from a WD My Cloud EX2 or PR4100?
What is the difference between My Cloud OS 3 and OS 5 for data recovery?
Does my My Cloud model change how you recover the data?
My WD My Cloud enclosure is dead. Do I need an identical chassis to get the data back?
Why do my My Cloud Home files show up as hexadecimal names with no folders?
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchRelated services
Related Recovery Services
My Cloud Home hex filename reconstruction from SQLite index.db. Android-based REST SDK architecture.
Synology, QNAP, Buffalo, ASUSTOR, TerraMaster, Drobo, and all Linux-based NAS.
All WD drives: Red, Blue, Black, Purple, Gold, Ultrastar.
Full HDD recovery service: head swaps, firmware repair, platter transplants.
RAID 0, 1, 5, 6, 10 array reconstruction from mdadm, ZFS, and hardware controllers.
WD SMR translator corruption diagnosis and PC-3000 firmware repair.
BeyondRAID pooled arrays recovered from write-blocked drive images after Drobo's 2023 shutdown.
WD My Cloud showing a red LED or not booting?
Free evaluation. No data = no charge. Ship your drive from anywhere in the U.S.