Raid 1 configuration on MDADM fails to refresh after relocating disks to a different machine.
Raid 1 configuration on MDADM fails to refresh after relocating disks to a different machine.
I'm dealing with a problem where my raid 1 setup, which I configured using mdadm with two 8TB HDDs, stopped rebuilding after relocating them from a NAS to a new server. Initially connected through a USB enclosure in the old NUC, and recalling past conversations about this setup, here are the details of the array at that time:
- Version: 1.2
- Creation Time: Sun Jan 19 13:30:06 2025
- Raid Level: raid1
- Array Size: 7,823,894,464 bytes (about 7.28 TiB / 8.00 TB)
- Used Dev Size: same as above
- Total Devices: 2
- Persistence: Superblock is persistent
- Active Devices: 2 working, 0 failed, 0 spare
- Consistency Policy: bitmap
- Name: nucmediaserver:0 (hosted on the local NUC)
- UUID: 4df06c4d:7ab9aa5c:de5c98d4:a8aa8384
After moving to the new server, I connected them directly via SATA. At that time, Proxmox VE was running version 9.0.3 or newer. I assumed the array would rebuild properly without issues. However, I later found out that Proxmox doesn't mount drives automatically. When I tried to rebuild using `mdadm --assemble --scan`, it reported "no arrays found."
Examining the drives with `mdadm` gave me similar results: both devices had identical MBR and partition data. The disk sizes matched exactly, but no array information was present. This suggests that the data might have been stored in superblocks rather than on the physical drives.
I attempted to copy the old `mdadm.conf` file from the NUC, but it was empty. I also checked the NUC for any remnants of configuration, but there was nothing. Now, without a working mount point and no active rebuild process, the array remains unrebuildable.
If you have any leads or steps to try, I’d appreciate your guidance on recovering the data.
It seems your previous superblock information isn’t being detected on the updated system. Before taking drastic steps, it’s wise to: Execute `mdadm --examine /dev/sdX` on each storage device and verify UUIDs/events. Use `mdadm --assemble --verbose /dev/md0 /dev/sda /dev/sdb` instead of just a simple scan. Ensure Proxmox isn’t automatically mounting or altering the drives. If the superblocks remain valid, `--assemble` should restore them. If not, avoid running `--create` unless you’re prepared to lose data. For safety, create images of both drives first and proceed cautiously. This process carries risks, so consider using clones or backups if data integrity matters.
I've encountered issues with USB to SATA adapters displaying wrong sector sizes for the drives. It seems likely the cause. Consider reinserting the drives into the USB cases and connecting them to the new server.
I connected the USB enclosure to the old server. Everything seemed identical to what it was two days prior, yet it still didn’t function.
Checking the drives with mdadm --examine reveals the status of each storage device on the server.
Also, beware of ChatGPT tricking you here. It’s wise to split the disks into partitions and consider using RAID for redundancy. Transferring disks to another device or reinstalling the OS shouldn’t cause issues either way. When my NAS had a boot SSD failure, RAID automatically restored after a fresh OS install (and mdadm setup). For future array creation tips: https://wiki.archlinux.org/title/RAID TestDisk isn’t required if you’re using ext4—just one disk should suffice for RAID1. You might also try building the mdadm array without superblocks, though that carries risk and needs careful testing.
Exactly the same as your previous update about the new homelab.