When a Fresh Start Erases What Was Left
The array wouldn’t rebuild, so you recreated it — same drives, same order, same size.
It mounted — success for a moment — until you opened the first folder and found nothing but broken names and unreadable files.
The controller did what it was designed to do: start over.
The problem is, starting over wrote across what was still there.
What You See
- New array appears healthy and mounts normally.
- Files missing, corrupt, or unreadable.
- SMART reports show low write counts despite recent activity.
- Logs show New VD Created with same member set.
- File system reports wrong volume ID or label.
Why It Happens
- Controller overwrote metadata on member disks during recreation.
- Stripe alignment no longer matches original parity map.
- Partial initialization destroyed unused regions of valid data.
- File system headers were re-created with empty allocations.
- Background verify pass wrote zero blocks to previous data areas.
What NOT To Do
- Do not write new data to the array under any circumstance.
- Do not attempt file system repairs or mount for use.
- Do not import old backups into the same set.
- Do not swap controllers to force recognition.
- Do not continue initialization once corruption is observed.
What You CAN Do
- Stop writes immediately and clone all disks.
- Capture controller config before power-down for stripe reference.
- Analyze binary sectors for previous superblock or MFT headers.
- Reconstruct old layout using ADR parity tools to extract pre-rebuild data.
- Engage ADR engineer for metadata rollback or virtual RAID recreation.
Diagnostic Overview
- Array Type: RAID 6 — Recreated Set
- Controller State: Volume Mounted / Files Corrupt or Missing
- Likely Cause: Overwritten Parity Map and Lost Stripe Alignment
- Do NOT: Write to Volume or Run Repairs Before Imaging
- Recommended Action: Clone All Members, Recover Old Metadata, Rebuild Using Binary Parity Analysis