Introduction

This article describes the steps required to recover a degraded software RAID 1 partition in Linux. It is always advisable to check the status of your RAIDs to monitor all associated partitions. To do this, we can use the mdadm command.

An example would be:

mdadm --detail /dev/md[0-9]

In most cases, output similar to the following will appear:

           Version : 1.2
     Creation Time : Thu Jun  8 19:06:32 2023
        Raid Level : raid1
        Array Size : 1953381440 (1862.89 GiB 2000.26 GB)
     Used Dev Size : 1953381440 (1862.89 GiB 2000.26 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun Oct 11 10:02:40 2026
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : server_example:2  (local to host server_example)
              UUID : abc12345:6789abcd:ef012345:6789abcd
            Events : 500000

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1

However, sometimes you might get results like this:

   Version : 1.2
     Creation Time : Sat Mar  7 21:58:44 2015
        Raid Level : raid1
        Array Size : 974867264 (929.71 GiB 998.26 GB)
     Used Dev Size : 974867264 (929.71 GiB 998.26 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Sun Oct 11 11:20:16 2026
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              Name : servidor_example:1
              UUID : abc12345:6789abcd:ef012345:6789abcd
            Events : 500000

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       1       8       20        1      active sync   /dev/sdb4

In these cases, the RAID is in a degraded state and is not synchronizing data across all partitions as it should. In such cases, here is a clean procedure to resolve it:

Checking the Hard Drive Status

The first operation to perform is verifying the status of the hard drive causing the issue. To do this, we check the hard drive status in the system kernel using the command:

sudo dmesg -T | grep -iE 'ata|sd[a-z]|error|i/o'

Which will produce an output similar to:

md: kicking non-fresh sda4 from array!
[Sat Oct 10 13:39:18 2026] EXT4-fs (md1): mounted filesystem abc12345-6789abcd-ef012345-6789abcd r/w with ordered data mode. Quota mode: none.

After that, we use the smartctl command:

sudo smartctl -H /dev/sda

 === START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

We check the error values that the kernel might detect:

sudo smartctl -A /dev/sda | grep -E 'Reallocated_Sector|Current_Pending|Offline_Uncorrectable|UDMA_CRC'

With the following result:

  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   051   051   000    Old_age   Always       -       8176
198 Offline_Uncorrectable   0x0010   051   051   000    Old_age   Offline      -       8176
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Where:

  • Reallocated_Sector_Ct: Ideally, the raw value should be 0.
  • Current_Pending_Sector: Must be 0 (any non-zero value indicates unreadable sectors).
  • Offline_Uncorrectable: Must be 0.
  • UDMA_CRC_Error_Count: If increasing, it indicates a faulty SATA/SAS cable or backplane connection rather than a defective drive.

Finally, we verify that all sectors of the partition can be read properly:

sudo badblocks -sv /dev/sda4

hecking blocks 0 to 976562175
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Checking the RAID Status

We examine the state of the metadata associated with the RAID for that partition:

sudo mdadm --examine /dev/sda4

/dev/sda4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : abc12345:6789abcd:ef012345:6789abcd
           Name : server_example:2 
  Creation Time : Sat Mar  7 21:58:44 2015
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1949734912 sectors (929.71 GiB 998.26 GB)
     Array Size : 974867264 KiB (929.71 GiB 998.26 GB)
  Used Dev Size : 1949734528 sectors (929.71 GiB 998.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=384 sectors
          State : active
    Device UUID : abc12345:6789abcd:ef012345:6789abcd

    Update Time : Sun Aug  2 00:10:38 2026
       Checksum : def56789
         Events : 500000


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

Rebuilding the RAID

Once everything looks correct, we proceed to rebuild the RAID. To do this, we re-add the partition to the array:

# RAID 1 Re-building
sudo mdadm --manage /dev/md1 --re-add /dev/sda4 or
# RAID 1 Adding a partition
sudo mdadm --manage /dev/md1 --add /dev/sda4

mdadm: hotplug add /dev/sda4 from /sys/devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda4
mdadm: adding component drives to /dev/md1

After re-adding the partition to the RAID, the rebuild will start automatically. We can monitor the process with one of the following commands:

sudo tail -f /proc/mdstat
sudo watch -n 1 cat /proc/mdstat

It will show, among other data, that the RAID is rebuilding.

md1 : active raid1 sda4[3] sdb4[2]
      976430912 blocks super 1.2 [2/1] [_U]
      [=>...................]  recovery =  6.7% (66208448/976430912) finish=93.5min speed=162227K/sec