The RAID5 array disappears after a reboot because the system fails to automatically assemble the mdadm components. This usually happens when the
mdadm.conf configuration file is missing or incorrect, preventing the initramfs from recognizing the disk signatures during boot. You can resolve this by manually assembling the array using
mdadm --assemble, verifying the superblocks, and then updating the configuration file to ensure persistence across reboots.
Diagnosing the Missing Array
When you log into your home server after the reboot, check the status of your storage devices. Run
lsblk or
fdisk -l to see if the individual drives are visible as standard block devices (like
sdb,
sdc) but lack partition tables that look like Linux RAID autodetect (
type fd). If the drives are present but not grouped, run
cat /proc/mdstat. An empty output confirms that no arrays are currently assembled.
Next, inspect the current mdadm configuration with
cat /etc/mdadm/mdadm.conf (or
/etc/mdadm.conf on some distributions). If this file is empty or does not contain a
ARRAY line corresponding to your 3TB volume, the system has no instructions on how to rebuild the RAID set at startup. This is the most common cause for arrays created via Webmin that fail to persist after a power cycle or reboot.
Manually Assembling the Array
Before attempting any fixes, identify the device names of your member disks. Use
mdadm --examine /dev/sdX for each drive to verify they hold valid RAID superblocks. Once confirmed, attempt to force the assembly of the array. Since the array was previously active, you can often use:
sudo mdadm --assemble --scan
If this command fails, you may need to specify the devices explicitly:
sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1
Replace
/dev/md0 with your desired array name and the
/dev/sdX entries with your actual disk identifiers. If the array assembles successfully, mount it immediately to recover your data:
sudo mount /dev/md0 /mnt/raid
Verify the integrity of your files before proceeding. If the array shows as degraded or inactive, do not write new data until you have secured backups. For complex scenarios involving mixed drive sizes or previous migration errors, reviewing guides on
Troubleshooting Mdadm RAID 5 Array Size Issues can provide additional context on potential size mismatches.
Updating Configuration for Persistence
To prevent this issue from recurring, you must update the system's RAID configuration. The primary method is to regenerate the
mdadm.conf file based on the currently running array. First, ensure the array is active and mounted. Then, run:
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
On Debian-based systems, you might also need to update the initramfs image so that the array is available early in the boot process. Execute:
sudo update-initramfs -u
This command rebuilds the initial ramdisk with the new RAID metadata. After this step, reboot the server to test if the array mounts automatically. If you are managing multiple controllers or complex hardware setups, refer to
Configuring mdadm on Intel Z270 Chipset for insights on handling hardware-level detection quirks.
Alternative: Using UUIDs
Hardcoding device names like
/dev/sdb is risky because these can change between boots depending on USB controller enumeration or PCIe slot detection. It is safer to use UUIDs. Find the UUID of your array using
mdadm --detail /dev/md0. Edit
/etc/mdadm/mdadm.conf and ensure the
ARRAY line uses the UUID instead of device paths:
ARRAY /dev/md0 uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
This ensures the correct drives are assembled even if their kernel device names shift.
Checking SMART Health
Disappearing arrays can sometimes indicate failing hardware. Before finalizing your fix, check the health of each drive in the RAID5 set. Use
smartctl -a /dev/sdX to look for reallocated sector counts or pending failures. A single failing drive in a RAID5 configuration can lead to data loss during reconstruction if another drive fails simultaneously. Ensure all drives show a "PASSED" status and have low temperature readings.
Webmin Specific Considerations
Since you used Webmin to create the array, note that Webmin sometimes creates configurations that are not fully compatible with standard
mdadm tools if custom parameters were used. Always backup your
mdadm.conf before overwriting it. If Webmin provides a "Save Config" button in its RAID module, use it to export the current state to the correct system path. However, manual verification via the command line remains the most reliable method for ensuring boot-time assembly.
Frequently Asked Questions
Why did my array disappear only after a reboot?
The array disappears because the automatic assembly service failed to find the necessary configuration details in
mdadm.conf or the initramfs. Without these files updated, the kernel treats the disks as independent raw devices rather than components of a RAID set.
Can I rebuild the array without losing data?
Yes, you can reassemble the existing array without formatting it, provided the superblocks are intact. Use
mdadm --assemble to bring the array back online. Never use
--create unless you have already backed up your data, as that command initializes a new array and destroys existing metadata.
What if mdadm --assemble fails with "no superblock information found"?
This error indicates that the RAID metadata is corrupted or missing from the expected locations. Check if the drives are properly connected and recognized by the OS. You may need to specify the correct device partitions or use
--force if the array was shut down improperly, but this carries a risk of data inconsistency.
How do I know if my RAID5 array is degraded?
Run
cat /proc/mdstat and look for the word [U_U] or similar patterns indicating a missing drive. A healthy array will show [UUU]. If one drive is missing, the array continues to operate but has no redundancy until you replace the failed disk and resync.
Is it safe to move drives between servers?
Moving physical drives is generally safe for mdadm arrays as long as you maintain the same order or use UUIDs for identification. However, always scan the drives with
mdadm --examine before assembling them on a new machine to ensure the superblocks are readable and consistent with the original configuration.