RAID Backup Best Practices

A Linux server running software RAID (mdadm) exposes several block devices at once: the physical member disks (/dev/sda, /dev/sdb), the assembled array (/dev/md0), and, if partitioned, the partitions on the array (/dev/md0p1, /dev/md0p2). Choosing the correct backup source determines whether your backups are consistent, storage-efficient, and usable for Bare Metal Recovery.

This guide explains which device to select, why the Dashboard blocks the wrong ones, and how to plan sizing and restores for each RAID level.

1. Back Up the Assembled Array (/dev/mdX)

Rule: always select the assembled RAID volume (e.g., /dev/md0) as the backup source.

In the StateWarden Dashboard, physical disks that belong to an array are flagged as RAID members and backup actions on them are disabled. The assembled /dev/mdX volume is listed as the valid backup target, and its details view shows the array structure, including the RAID level and the number of member disks (for example, a RAID 5 volume with 3 members).

Backing up the assembled volume gives you:

1. Consistency: the backup reads one logical device, so every block comes from the same point in time.
2. BMR readiness: backing up the whole /dev/md0 device captures the partition table (GPT/MBR) and boot sector along with the data. On restore, the partitions (p1, p2, ...) reappear automatically and the system is ready to boot.
3. CBT efficiency: Changed Block Tracking operates on the single logical device (see Section 4).
4. Simplicity: one backup policy per array instead of one per partition.

The array structure (RAID level, member count, chunk size) is stored as metadata with the backup, so the Recovery environment knows how to reconstruct the container on new hardware.

2. Why Member Disks Are Excluded

Backing up individual member disks (/dev/sda, /dev/sdb) of a live array is blocked because it is both wasteful and unsafe:

• Duplicated data: on RAID 1 and RAID 10, every mirror leg holds an identical copy of the data. Backing up members would store the same data once per mirror without adding any protection. On RAID 5 and RAID 6, member contents include parity fragments that are meaningless outside the array.
• Inconsistent array state: each member would be read at a different moment. Restoring members captured minutes apart assembles a desynchronized array and can corrupt the filesystem beyond repair.
• No standalone value: a single member disk cannot be restored into a usable filesystem on its own. The data only makes sense as the assembled logical volume.

This is why the Dashboard greys out RAID member disks for backup purposes: the assembled volume is the only target that produces a restorable backup.

3. RAID Levels and Backup Sizing

Plan storage quotas and backup windows against the logical volume size, not the sum of the physical disks. The two numbers differ on every level except RAID 0:

(N = number of member disks, S = size of one member.)

Level-specific notes:

• RAID 0: logical size equals the raw member sum, but there is no redundancy. A single member failure destroys the array, so the backup is the only protection. Keep retention strict and test restores regularly.
• RAID 1: the logical volume is the size of one disk. If you sized your backup plan from the physical disks, you would overestimate by a factor of two.
• RAID 5 / RAID 6: one or two members' worth of capacity is parity. The backup covers only the logical volume; parity is never backed up because it is rebuilt automatically when the array is recreated.
• RAID 10: the logical volume is half the raw member sum.

The actual stored footprint is reduced further by deduplication. Size your expectations from the data on the logical volume and let deduplication work in your favor.

What About Backing Up Individual Partitions (/dev/md0p1)?

You can back up a single partition on the array instead of the whole device, but this is an advanced option. A partition backup contains only the data inside that partition - it does not record where the partition starts or ends on the disk. After a disk replacement you must recreate the exact partition layout manually (fdisk/gdisk) before restoring. For full-system protection, back up the whole /dev/md0 device.

4. Smart CBT on RAID Volumes

Smart CBT (Changed Block Tracking) works on assembled md volumes the same way it works on plain disks: you arm it per volume with the CBT toggle in the device's Storage & Backups tab, the first backup after arming runs as a full scan to build the baseline, and subsequent backups process only changed blocks.

Tracking one logical /dev/mdX device is significantly more efficient than tracking several partitions or member disks separately, so an armed array volume gives you short incremental backup windows even on multi-terabyte arrays.

Note that disabling CBT destroys the tracking metadata, and the next backup falls back to a full scan to rebuild the baseline. For enablement steps, fallback behavior, and troubleshooting, see Smart CBT: Incremental Backups.

5. Encrypted Volumes on RAID (LUKS on md)

A common hardening layout places LUKS on top of RAID: the crypto_LUKS partition lives on the assembled /dev/mdX device. The Dashboard marks such volumes with an encryption badge.

StateWarden backs up encrypted volumes as raw encrypted containers at the block level, which has two practical consequences on RAID:

• No deduplication and no effective CBT: encrypted blocks are high-entropy, so every backup of the encrypted volume runs as a Synthetic Full. Plan backup windows and quotas for the full logical size on every run.
• Restores return the volume still encrypted: the LUKS header and data come back exactly as they were at backup time. Unlock the restored volume with the original passphrase.

The full procedure, including hardware-change considerations, is documented in Restore Guide: Encrypted Drives (BitLocker & LUKS).

6. Restoring to RAID Targets

Standard Restore: Assemble the Array First

The target array must exist and be assembled before you start the restore. When you select a RAID volume backup in the Dashboard, a warning reminds you that the restore target must be a pre-assembled RAID array of equal or larger size. In practice:

1. Create and assemble the target array with mdadm so it appears as /dev/mdX.
2. Ensure the assembled volume provides at least the capacity of the original logical volume.
3. Select the assembled volume - never an individual member disk - as the restore target.

Bare Metal Recovery onto RAID

For a full-system restore onto new hardware, boot the machine from the Recovery ISO as described in the Bare Metal Recovery Walkthrough. For RAID backups, the Recovery environment reads the array structure stored with the backup and handles the container for you:

1. You map the original member disks to the new physical disks attached to the machine.
2. The array is recreated on the new disks with the original RAID level, member count, and chunk size.
3. The backup data is streamed into the assembled array, skipping unallocated space.
4. Bootloader and EFI fixups are applied so the restored system boots on the new hardware.

Warnings:

• BMR is destructive: all existing data and partition tables on the selected target disks are irreversibly overwritten.
• Provide at least as many physical disks of sufficient size as the original array had members.
• Do not interrupt the process between array creation and the completion of the data stream; a partially written array cannot be booted.

7. Summary Checklist

If your storage stack also uses LVM - on top of RAID or on plain disks - the same logical-first principle applies. See LVM Backup Best Practices for the LVM-specific rules.

StateWarden: Resilience Engineered.