Drives Unreadable After Removal From a Server or NAS
If data could be opened while the drives sat in a server, NAS or enclosure, and nothing usable appears once they are connected somewhere else, start with what changed rather than with what broke. Before removal you were usually reading a share, volume or LUN that the appliance or controller assembled from several members — and sometimes unlocked, or presented through its own sector layout. Now a different computer is reading one physical disk through a different adapter. Those are different objects, so a single member without a recognizable file system is often expected, and it is not by itself evidence of damage or of encryption. Keep every member, the original hardware and its records together; do not initialize, format, import or rebuild anything to see what happens; and stop ordinary experiments as soon as a drive starts clicking, disconnecting or timing out.
Drives unreadable after removal: what should you do next?
Answer one question about warning signs you have seen. The result suggests the safer next step rather than diagnosing the failure; what has already been written to the drives is a separate question, covered right after this guide.
Since removal, have the drives been free of warning signs you have seen — new noises, disconnects, timeouts or read errors? No full-surface test is needed; if you don’t know, choose “not sure”.
Establish what was readable before and what is being read now.
“Apparently stable” only means no warning signs have been seen so far; it is not a health diagnosis, and it does not establish that the contents are unencrypted. Keep every member, the original hardware and its records, write down which object you used to open (share, volume or LUN), which device presented it, and what each member now shows on its own, then use the symptom table below to pick a branch. Choose a controlled acquisition or analysis that fits the access path, any keys involved and the drives’ condition, and plan longer reads on copies rather than repeating them on the originals.
Stop trying adapters, ports and power cycles.
Warning signs, or a condition nobody has observed, call for a health assessment and a controlled acquisition plan, not more permutations. A drive whose state is simply unknown is a reason to plan its assessment, not proof that it or the whole set is failing. A drive with active failure symptoms such as clicking, repeated dropouts or growing errors should be treated as critical-risk and handled only by careful imaging. Keep every member, any replacement or spare, and the original controller or enclosure.
This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.
This applies whichever answer you chose above: a write history is a separate fact from drive health. If a disk was initialized, formatted, imported, cleared, rebuilt or resynced after removal, record what was run, on which disks and when, and do not run anything further that writes. Treat the affected members as possibly holding a newer generation of metadata or data than the rest of the set, so the question becomes which state each member holds, not only where it belongs. That history changes what any later reconstruction has to account for; on its own it is not evidence that a drive is failing.
What exactly changed
The useful comparison is between two access paths, not between “working” and “broken”. Before touching anything else, write down what is already known — and mark what is not known as unknown instead of filling it in from memory:
- The original path: the server, NAS, RAID controller, external enclosure or USB/SATA bridge the drives were in, with model and, if known, firmware.
- What used to be readable: a network share, a mounted volume, a LUN presented to another host, or a single drive’s own partitions. These are different things even when they showed the same files.
- Which drives were removed: serial numbers, the bay or slot each came from if it was recorded, and any disks removed or replaced earlier.
- How they are connected now: which computer, controller, HBA, adapter or dock, and whether every member is attached or only some.
- The symptom and its timing: what each drive shows now, and whether that was true from the first connection or changed after later attempts.
- What has already been tried: other adapters, other machines, recovery tools, and any prompt that was accepted or declined.
Gather these from labels, photos, tickets, configuration exports, logs and what the current computer already displays. Powering the original system back on, or reconnecting drives to it, only to complete this list is a separate decision with its own risks (see below). A fuller version of this record is described in Documenting a Multi-Disk System Before Drives Are Removed.
Match the symptom to a branch, not to a diagnosis
Each symptom below is compatible with more than one cause. The table lists what to separate next and what the symptom does not establish on its own.
Scroll horizontally to see the full table →
| What you see now | Branches to separate | Evidence that helps | What it does not prove |
|---|---|---|---|
| The drive is not detected at all | Power or interface mismatch with the new adapter or port; a path that does not support that drive type; a drive or electronics failure | Whether the drive spins up or is enumerated by any controller, the interface it actually uses, and whether this began at removal or later | That the drive is self-encrypting or locked; that it is dead. See Drive Not Detected or Keeps Disappearing |
| Capacity or sector size differs from what you expected | The new adapter or controller presents the device differently; the old path presented a volume rather than this disk; a device or firmware fault | The model, serial, interface and reported capacity and sector size, recorded as observed, compared with the drive label and the original system’s records | That the geometry needs “fixing” on the strength of one number. See Drive Shows the Wrong Capacity |
| The drive is detected, but reads of some or all ranges are refused | A configured security or locking state; failing media in those areas; an adapter that does not pass the drive’s commands through | Records of whether drive security was enabled in the original system, the drive’s own reported security capability and state, and whether failures follow fixed ranges or spread over time | That encryption is the cause; error messages for a locked range differ between implementations, and failing media can also refuse reads |
| Sectors read normally, but the expected file system is not there | Ciphertext from controller, appliance or volume encryption; one fragment of a striped layout; data that starts at an offset or sits inside a pool or volume manager; real damage | RAID or pool metadata on the member, partition layout, the original system’s encryption settings, and what the same position looks like on the other members | That the data is encrypted, or that it is destroyed |
| Only one RAID member is connected | A normal consequence of striping or parity; a mirror member or a disk with standalone partitions, which can be exceptions | The array level and metadata format, and whether the other members are available and identified | That a single member can never contribute to recovery, or that it can be used on its own |
| New clicks, timeouts, disconnects or slowdowns | A drive whose condition is getting worse under repeated attempts; a marginal cable, port or power supply | When the symptom started relative to the attempts, and on which drives | That a different adapter will fix it; this is the point to stop permutations and plan a controlled acquisition |
Look at the bytes with the same caution. Random-looking data, a block of zeros, a volume shown as RAW or a size of 0 bytes can each come from encryption, a wrong offset, a member of a different array, an unwritten or trimmed area, an unsupported layout or plain damage. None of them identifies the cause by itself; the original system’s configuration and the on-disk metadata do.
A readable member is not the share you used to open
A RAID or NAS volume is assembled from members according to metadata the system keeps. In Linux md, for example, each member records the role it has in the array and an offset, counted from the start of the device, where the array’s data on that member begins (Linux md admin guide). Where the metadata itself sits also depends on the format: md places the version 0.90 superblock near the end of the device, and the version 1 superblock normally near the end as well, with variations at the start (1.1) or four kilobytes from the start (1.2) (md(4), MD metadata). Hardware controllers and NAS platforms use their own formats, so these figures describe md only, but the consequence is general: what a recovery computer finds at the start of a member depends on the layout and format, not only on whether the data survived.
That is why a stripe or parity member usually shows no usable file system on its own, while a mirror member, or a disk carrying its own standalone partitions, sometimes does. Neither outcome should be over-read: a member that shows nothing may be intact, and a member that shows a file system may be stale or incomplete compared with the array the system was last using.
Illustrative example: one member reads cleanly, but no partitions appear
A NAS share was readable over the network. One of its drives, connected to a desktop through a dock, reads without errors, yet the desktop shows no expected partitions and offers to initialize it.
The share was the top of a stack the NAS assembled from all its members. One member may hold only part of each stripe, a data region starting at an offset, or ciphertext, and Windows cannot tell which. The earlier share is not a reference for what one disk should look like.
Decline the prompt, record the drive’s serial and origin, keep the other members together, and establish the NAS’s layout and encryption settings from its records before reconstructing anything from images.
Stable reads say nothing about whether this member is current or whether the volume can be decrypted without the NAS. Those questions need metadata from all members and the original configuration.
The same logic applies to encryption that lived in the original path. On a self-encrypting drive, ranges configured to lock on a power cycle or a covered reset event can return to a locked state, and their user data is not accessible until they are unlocked again (TCG and NVMe joint white paper, “Self-Encrypting Drive Basics”). Having security capability or a credential set does not by itself mean every range is configured to lock, and which ranges are locked depends on the device and its configuration. Physical removal does take power away from the drive, so a drive the original system unlocked at every start may refuse reads of those ranges elsewhere; an ordinary host restart, by contrast, does not necessarily remove drive power, and its effect depends on the device, controller and configuration. Controller-managed keys are another dependency: a 2019 Dell tech note on PERC SED support says the key that unlocks secured drives is stored on the controller under local key management, or on an external server under enterprise key management, and that the passphrase originally used is needed when those drives are imported into another controller (Dell PERC SED Support FAQ). That describes PERC controllers of that period; other controllers and generations behave differently. What these dependencies are, and how to preserve them, is covered in Self-Encrypting Drives and Controller Encryption in RAID and NAS.
What to keep now
- Every drive that may have been part of the system: current members, earlier removed disks, replacements and spares. A disk that looks surplus can hold the only copy of a region or a moment in time.
- The original hardware: the server or NAS, RAID controller, enclosure, bridge board or dock. It may hold configuration, keys or the way sectors were presented.
- Configuration and logs: exports, screenshots, alerts, tickets and any record of the array, pool and encryption settings.
- Slot and serial records: where each drive came from, if known. If bay notes were never made, record that as unknown; do not reconstruct the order by trying arrangements in a live controller. RAID Disks Removed and Their Order Is Unknown covers what can still establish member roles.
- Unlock dependencies: who holds the passphrase, recovery key or key server access. Record where secrets are kept and who owns them, not the secrets themselves; credentials do not belong in a plain report.
What not to use as a test
Several actions offered by operating systems, controllers and appliances are maintenance operations, not diagnostics. Each one writes metadata or changes key state, and none of them tells you safely why the drive is unreadable:
- initializing a disk, formatting it, or creating a new array or volume on the members;
- importing or clearing a foreign configuration (see RAID Metadata, Member State and Foreign Configurations for why a “foreign” disk is not a failed one);
- starting a rebuild, resync or repair;
- security reset, revert or erase functions, some of which destroy the keys and with them the data;
- repeated power cycles and adapter swaps on a drive that is already showing new symptoms.
Putting the drives back into the original server or NAS and starting it is not a default next step either. It can be the right decision, but it is a separate one: the system may auto-assemble the array from whatever it finds, mark members as failed or foreign, start a rebuild or write new metadata, and a weak drive takes the load of another start. If the original slot order was not recorded, a returned set can also be presented in a different arrangement from the one it was removed in. That decision belongs after the record and health questions above, with the system’s documented behaviour for that exact model in view.
Paths forward
There is no single ladder that fits every case. Which of these applies depends on what the original path supplied, which members are available, and their condition:
- Supported access through the original or an equivalent system, when the dependency the drives need (a controller, an appliance, an authorized unlock) is known and its behaviour for this configuration is understood.
- A logical export of the most important data, where a decrypted view is available again and the drives’ health and the consistency of the data allow it. It does not replace member images or metadata. Live Systems, Snapshots and Consistent Recovery Copies covers what such a copy captures.
- Virtual reconstruction from member images, rebuilding the array and pool layers on copies rather than on the originals; see Reconstructing NAS Storage Stacks and What a Disk Image Preserves — and What It Does Not.
- Analysis of the unlock dependency, through the legitimate owner’s credentials, recovery keys or key service, when the members are locked or return ciphertext. Correct RAID geometry does not replace a missing key.
- Professional stabilization and acquisition, when a drive shows warning signs, its condition is unknown, or the symptoms have changed since removal.
Remote NAS Recovery vs. Member-Level Reconstruction explains how these entry points differ, and NAS Device Failure and RAID Array Failure cover the system as a whole.
Don't accept an initialize, format, import, clear, rebuild or security-reset prompt to find out why a removed drive is unreadable. The earlier readable view came from a whole access path; recreate an understanding of that path first, and keep the drives, the original hardware and its records together until you have.
If the removed drive is a single standalone disk that now asks to be initialized, see Drive Asks to Be Initialized; if it reports a capacity that makes no sense, see Drive Shows the Wrong Capacity. If the bay order was lost during removal, see RAID Disks Removed and Their Order Is Unknown · Self-Encrypting Drives and Controller Encryption in RAID and NAS · Documenting a Multi-Disk System Before Drives Are Removed · Remote NAS Recovery vs. Member-Level Reconstruction · RAID Metadata, Member State and Foreign Configurations · Encryption Key Hierarchies and Recovery Metadata · What a Disk Image Preserves — and What It Does Not.
This page describes the general situation, not a guaranteed fix for your specific case. If you'd rather have someone experienced take a look before you try anything, find a recovery provider by region.