MajorLinux
6592eb4fea
- Fixed 4 broken markdown links (bad relative paths in See Also sections) - Corrected n8n port binding to 127.0.0.1:5678 (matches actual deployment) - Updated SnapRAID article with actual majorhome paths (/majorRAID, disk1-3) - Converted 67 Obsidian wikilinks to relative markdown links or plain text - Added YAML frontmatter to 35 articles missing it entirely - Completed frontmatter on 8 articles with missing fields Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
115 lines
3.9 KiB
Markdown
115 lines
3.9 KiB
Markdown
---
|
|
title: "mdadm RAID Recovery After USB Hub Disconnect"
|
|
domain: troubleshooting
|
|
category: storage
|
|
tags: [mdadm, raid, usb, storage, recovery]
|
|
status: published
|
|
created: 2026-04-02
|
|
updated: 2026-04-02
|
|
---
|
|
# mdadm RAID Recovery After USB Hub Disconnect
|
|
|
|
A software RAID array managed by mdadm can appear to catastrophically fail when the drives are connected via USB rather than SATA. The array is fine — the hub dropped out. Here's how to diagnose and recover.
|
|
|
|
## Symptoms
|
|
|
|
- rsync or other I/O to the RAID mount returns `Input/output error`
|
|
- `cat /proc/mdstat` shows `broken raid0` or `FAILED`
|
|
- `mdadm --detail /dev/md0` shows `State: broken, FAILED`
|
|
- `lsblk` no longer lists the RAID member drives (e.g. `sdd`, `sde` gone)
|
|
- XFS (or other filesystem) logs in dmesg:
|
|
```
|
|
XFS (md0): log I/O error -5
|
|
XFS (md0): Filesystem has been shut down due to log error (0x2).
|
|
```
|
|
- `smartctl -H /dev/sdd` returns `No such device`
|
|
|
|
## Why It Happens
|
|
|
|
If your RAID drives are in a USB enclosure (e.g. TerraMaster via ASMedia hub), a USB disconnect — triggered by a power fluctuation, plugging in another device, or a hub reset — causes mdadm to see the drives disappear. mdadm cannot distinguish a USB dropout from a physical drive failure, so it declares the array failed.
|
|
|
|
The failure message in dmesg will show `hostbyte=DID_ERROR` rather than a drive-level error:
|
|
|
|
```
|
|
md/raid0md0: Disk failure on sdd1 detected, failing array.
|
|
sd X:0:0:0: [sdd] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
|
|
```
|
|
|
|
`DID_ERROR` means the SCSI host adapter (USB controller) reported the error — the drives themselves are likely fine.
|
|
|
|
## Diagnosis
|
|
|
|
### 1. Check if the USB hub recovered
|
|
|
|
```bash
|
|
lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL
|
|
```
|
|
|
|
After a hub reconnects, drives will reappear — often with **new device names** (e.g. `sdd`/`sde` become `sdg`/`sdh`). Look for drives with `linux_raid_member` filesystem type.
|
|
|
|
```bash
|
|
dmesg | grep -iE 'usb|disconnect|DID_ERROR' | tail -30
|
|
```
|
|
|
|
A hub dropout looks like multiple devices disconnecting at the same time on the same USB port.
|
|
|
|
### 2. Confirm drives have intact superblocks
|
|
|
|
```bash
|
|
mdadm --examine /dev/sdg1
|
|
mdadm --examine /dev/sdh1
|
|
```
|
|
|
|
If the superblocks are present and show matching UUID/array info, the data is intact.
|
|
|
|
## Recovery
|
|
|
|
### 1. Unmount and stop the degraded array
|
|
|
|
```bash
|
|
umount /majorRAID # or wherever md0 is mounted
|
|
mdadm --stop /dev/md0
|
|
```
|
|
|
|
If umount fails due to a busy mount or already-failed filesystem, it may already be unmounted by the kernel. Proceed with `--stop`.
|
|
|
|
### 2. Reassemble with the new device names
|
|
|
|
```bash
|
|
mdadm --assemble /dev/md0 /dev/sdg1 /dev/sdh1
|
|
```
|
|
|
|
mdadm matches drives by their superblock UUID, not device name. As long as both drives are present the assembly will succeed regardless of what they're called.
|
|
|
|
### 3. Mount and verify
|
|
|
|
```bash
|
|
mount /dev/md0 /majorRAID
|
|
df -h /majorRAID
|
|
ls /majorRAID
|
|
```
|
|
|
|
If the filesystem mounts and data is visible, recovery is complete.
|
|
|
|
### 4. Create or update /etc/mdadm.conf
|
|
|
|
If `/etc/mdadm.conf` doesn't exist (or references old device names), update it:
|
|
|
|
```bash
|
|
mdadm --detail --scan > /etc/mdadm.conf
|
|
cat /etc/mdadm.conf
|
|
```
|
|
|
|
The output uses UUID rather than device names — the array will reassemble correctly on reboot even if drive letters change again.
|
|
|
|
## Prevention
|
|
|
|
The root cause is drives on USB rather than SATA. Short of moving the drives to a SATA controller, options are limited. When planning a migration off the RAID array (e.g. to SnapRAID + MergerFS), prioritize getting drives onto SATA connections.
|
|
|
|
> [!warning] RAID 0 has no redundancy. A USB dropout that causes the array to fail mid-write could corrupt data even if the drives themselves are healthy. Keep current backups before any maintenance involving the enclosure.
|
|
|
|
## Related
|
|
|
|
- [SnapRAID & MergerFS Storage Setup](../../01-linux/storage/snapraid-mergerfs-setup.md)
|
|
- [rsync Backup Patterns](../../02-selfhosting/storage-backup/rsync-backup-patterns.md)
|