RAID Rebuilder from Member Disk Images (RAID 0, 1, 5 and mdadm)

About the RAID Rebuilder from Member Disk Images (RAID 0, 1, 5 and mdadm)

First make a disk image of each disk of the array: one file that holds every sector of the disk, made with a disk-imaging program and kept on another drive (the Data Recovery Assistant shows the steps). Then choose all the images here. A RAID array spreads its data over several disks, so no single disk opens on its own when the box that ran the array dies, a disk drops out or the controller is gone. The page reads each image a few megabytes at a time and rebuilds the array’s volume as one disk image, the way Linux md (mdadm) lays out RAID 0, RAID 1, RAID 4, RAID 5 and linear arrays, which most home NAS boxes use.

Where the disks carry md superblocks (versions 0.90, 1.0, 1.1 and 1.2, on the whole disk or in a partition) or SNIA DDF metadata, the level, disk order, chunk size, parity layout and data offset are read from them, and a member that dropped out earlier is left out where the level allows (a RAID 5 rebuilds its part from parity, a mirror reads another disk). Where there is no metadata, a search finds them from the file system inside: NTFS file records, ext backup superblocks and group descriptors, and btrfs mirrors all state their own place in the volume. A RAID 5 with one disk’s image missing is rebuilt from the XOR of the others.

Without a pass this is a free preview: the search and the rebuild run on your device, and the page shows the parameters found, the volumes inside the array and their first folders. Saving the rebuilt image and the PDF report of the parameters need an Ultimate pass.

Common uses

• Home and small-office NAS boxes whose array no longer starts, after a disk failure, a power cut or a dead enclosure.
• Servers whose hardware RAID controller failed, read from images of their disks.
• Degraded RAID 5 arrays with one disk missing or out of date.
• Checking the parameters of an array before writing anything to its disks.
• Getting one disk image of the whole volume, for the NTFS, ext4 and partition recovery pages.

Where the parameters come from

• md superblocks. Version 0.90 sits in the 64 KiB block that starts 64 to 128 KiB before the end of the device, 1.0 8 to 12 KiB before the end, 1.1 at its start and 1.2 4 KiB in (md(4)). Each is checked by its magic number and its checksum, a version 1 superblock also by the position it records for itself; then superblocks with the same array UUID are put together, each disk in the slot its role gives it. A NAS usually keeps several arrays on each disk (a small system mirror, swap and the data array), each in its own partition: the page lists them all, largest first.
• Out-of-date members. Every superblock counts the array’s updates (its events). A disk whose count is behind the others’ dropped out and missed later writes: where the level allows, it is left out and its slot is rebuilt from the others, as mdadm does when it assembles a degraded array. One update behind is allowed, as mdadm allows it, while the newest superblocks still list the disk in its slot: a power cut can stop the last superblock write before it reaches every disk.
• SNIA DDF. Controllers that use SNIA’s Common RAID Disk Data Format keep its anchor in each disk’s last sector; the page reads the virtual disk records (level, strip size, the disks in order and where each one’s extent starts).
• The search. Without metadata, the members are compared (identical data is a mirror, a zero XOR is parity), the array’s first sector is found, and structures that state their own place in the volume are matched to every level, parity layout and chunk size from 4 KB to 4 MB; the best fits are rebuilt and checked through the file system.

The layouts it rebuilds

• RAID 0: chunks spread over the disks in order; disks of different sizes continue in further zones, in the layout the superblock states (the original or the one since Linux 3.14).
• RAID 1: every disk holds the whole volume; the one with the newest superblock is read.
• RAID 4 and RAID 5: one parity chunk per stripe, in md’s six layouts: left-symmetric (mdadm’s usual one), left-asymmetric, right-symmetric, right-asymmetric, parity on the first disk, parity on the last disk (raid5.c). One missing disk is rebuilt from the XOR of the others.
• Linear (JBOD): the disks’ data areas one after the other.

The stripe map under the result shows where the first chunks and the parity of each stripe lie, disk by disk.

How large an array, and what it needs from your computer

Each image is read a few megabytes at a time, with a few 4 MB pieces of each cached: about 20 MB of memory for each disk image, whatever its size, plus the pieces a compressed container (E01, DMG, QCOW2, sparse VMDK) unpacks. Reading md or DDF metadata takes seconds; the search reads tens of megabytes of each image. Saving streams the rebuilt image into a file of any size in Chrome and Edge on a computer; other browsers download it from memory, up to 1 GB (512 MB on small touch screens), so a larger array needs one of those two.

Limitations

• It works on images of the disks, never on the disks themselves: a web page cannot read a disk sector by sector.
• RAID 6, RAID 10 and nested levels (RAID 50 and 60) are not rebuilt in this version; neither is an array caught in the middle of a reshape (a change of level, disk count or chunk size).
• LVM, btrfs and XFS volumes inside the array are saved in the rebuilt image as they are, not opened here: the page names them, and Linux opens the saved image (losetup, then vgchange or mount).
• Storage Spaces pools, ZFS (RAID-Z) and Windows dynamic disks are not read as arrays.
• The search needs an NTFS, ext2/3/4 or btrfs file system inside the array. A small ext volume whose structures fit more than one chunk size is rebuilt but not called confirmed: the page says so, and its first folders show which set is right.
• Without RAID metadata, a member whose data is out of date cannot be told apart from the others: leave its image out and rebuild a RAID 5 without it.
• A member’s unreadable sectors stay as the member image holds them: the rebuild uses parity only for a disk that is missing or out of date.
• Use these tools only on devices and data you own or may examine; no password cracking and no device unlocking (acceptable use). The page reads the images you hold; it never connects to a NAS, a controller or an account.

Privacy

On this device: nothing is sent

The images are read by your browser on your device, a few megabytes at a time; nothing from them is sent anywhere, and the page works offline once it has loaded.

How to check that nothing is uploaded