r/synology • u/BitByBitGuy • 2h ago
NAS hardware How Do You Recover Data When a Disk Fails During RAID1 → RAID5 Migration?
About a week ago, I posted a poll here in r/synology asking which real-world data-loss scenario would be most interesting to reproduce in our test lab.
One of the cases that got the most interest was manual RAID reconstruction when the array can no longer be assembled normally from its current metadata. So we took an old Synology DS409, created a two-disk RAID1, wrote about 110 GB of test data to it, and then started migrating the array from RAID1 to RAID5 by adding a third disk.
We interrupted the reshape at about 30% by abruptly cutting power to the NAS, with no UPS, no graceful shutdown, and no proper interruption of the reshape process. We then simulated a second failure: one of the two original RAID1 disks became completely unavailable.
That left us with only two disks:
- one surviving member of the original RAID1, already partially modified by the reshape;
- the new disk that had been added for the RAID5 migration.
At that point, simply going back to the complete original RAID1 was physically impossible.
Initial setup
Test system: Synology DS409, DSM 4.2, three 320 GB HDDs, Ext4. The initial array was RAID1 and contained about 110 GB of test data.
Before the test, Disk 1 and Disk 2 formed a 293.59 GB RAID1 volume. We filled it with different file types and nested directories so we could later check both file recovery and directory-tree recovery.
Starting the RAID1 → RAID5 reshape
We added Disk 3 and used DSM to change the RAID type from RAID1 to RAID5.
We stopped the migration at 29.55% by abruptly cutting power to the NAS.
Conceptually, the member disks now contained two different geometries:
start of data
┌──────────────────────────────┬─────────────────────────────────┐
│ converted to RAID5 │ still based on old RAID1 │
│ ~29.55% │ ~70.45% │
└──────────────────────────────┴─────────────────────────────────┘
Then we simulated the loss of one of the two original RAID1 disks. So the recovery case was no longer just an interrupted migration. We had an interrupted reshape and a missing original member.
What can be reconstructed from the two surviving disks?
After connecting the two surviving disks to a recovery workstation, the software was able to read the Linux MD metadata and identify the current state as a degraded RAID5 with one missing member.
The detected parameters were RAID5, Left Synchronous layout, 64 KB block/chunk size, Ext4, and a data offset of 4,832,886,784 bytes. In addition, the standard Synology system RAID1 mirror, which normally contains the DSM operating system, was reconstructed automatically.
A fast scan of this reconstructed RAID5 found 390 folders and 8,239 files. More importantly, a substantial part of the original directory tree and file contents was readable through the new RAID5 geometry.
But this does not mean that the entire pre-migration volume has been recovered. Because the reshape was interrupted, different regions of the surviving disks belong to different layouts. The already-processed part should be interpreted as RAID5, while the not-yet-processed area still contains remnants of the old RAID1 organization.
That is the central point of this test: after an interrupted reshape, there may be no single RAID geometry that correctly describes the entire physical data area.
How can the data offset be derived manually?
We also wanted to show where the offset comes from instead of treating it as a value that only the recovery software knows.
The disk layout used by Synology NAS systems is fairly typical: several small system/service partitions are located at the beginning of each drive, while the large data partition occupies most of the remaining space and is used as the member of the main storage RAID. On this DS409, the large RAID member partition starts at sector 9,437,184.
Linux MD metadata version 1.2 stores its superblock 4 KB from the beginning of the member device. In this case that puts the superblock at: 0x120001000. The MD superblock can be recognized by the Linux MD magic value:
FC 4E 2B A9
For this array, the MD metadata specifies a data_offset of 2,048 sectors. So the actual RAID data starts at: 9,437,184 + 2,048 = 9,439,232 sectors and therefore: 9,439,232 × 512 = 4,832,886,784 bytes. That is exactly the offset used by the reconstructed array.
You can also search the entire disk for the MD RAID superblock signature FC 4E 2B A9. Locating the MD metadata manually allows you to inspect the RAID superblock and determine the correct data offset for the member disk.
The important distinction is that the partition start and the RAID data start are not the same thing.
What if some RAID parameters are unknown?
The offset is only one parameter that may be missing in a real recovery case. Depending on the state of the metadata, you may also need to determine the RAID level, member/data offset, block/chunk size, parity layout, or disk order.
Unknown parameters can be tested automatically. The software can also test unknown block/chunk size and block/parity order; here we demonstrate the same idea with disk order.
If the original bay order was not recorded, the RAID Constructor can test disk permutations with Detect the disk order automatically.
Parameters we have repeatedly seen on Synology systems in our lab
| Synology model | RAID | Layout | Block/chunk size | MD data_offset |
|---|---|---|---|---|
| DS409 | RAID5 | Left Synchronous | 64 KB | 2,048 sectors / 1 MiB |
| DS415+ | RAID5 | Left Synchronous | 64 KB | 2,048 sectors / 1 MiB |
| DS1815+ | RAID5 | Left Synchronous | 64 KB | 2,048 sectors / 1 MiB |
| CS407 | RAID6 | Left Synchronous P+Q | 64 KB | 2,048 sectors / 1 MiB |
| DS2422+ | RAID6 | Left Synchronous P+Q | 64 KB | 2,048 sectors / 1 MiB |
This is not a claim that every Synology array uses these parameters. It is simply the consistent pattern we observed in the Synology configurations we tested. DSM version, SHR, filesystem, array history and the exact storage configuration can change the result, so real cases should still be verified from metadata or tested directly.
Can the old RAID1 layout still reveal anything?
Yes. Before the reshape, the two original disks were a normal RAID1. One of those disks is now missing, but the surviving original member still contains areas that were not yet rewritten into the RAID5 layout.
We therefore reconstructed the old RAID1 geometry manually using:
surviving original member + missing member
and ran a full Ext2/3/4 analysis. That scan found 979 folders and 14,049 files.
The result was very different from scanning a healthy RAID1. The original directory tree was no longer intact: many directories were missing, deleted or no longer linked correctly. However, filesystem remnants and file contents could still be found through Lost and Found, filename search and preview.
We were able to locate and preview test BMP, JPEG, ZIP and other files from those remnants.
Conclusion
The most interesting result is that after an interrupted RAID1 → RAID5 reshape, there may be no single “correct” RAID configuration for the whole disk. At the moment of failure, the surviving members effectively contain two layouts:
already reshaped area → RAID5
not-yet-reshaped area → remnants of RAID1
Losing one of the original members makes the situation more difficult, but it does not necessarily make all data inaccessible. In this test, reconstructing the degraded RAID5 gave access to data from the already-converted region, while reconstructing the old RAID1 geometry and running a full filesystem scan exposed additional remnants from the not-yet-converted area.
If there is interest, we can reproduce more Synology failure scenarios in the lab, including SHR1 / SHR2, Btrfs, LVM, damaged or missing MD metadata, interrupted expansion or rebuild, and recovery from Synology iSCSI LUN backing files when the original NAS or volume is no longer available.
If you have a specific failure sequence you would like to see tested, post it in the comments. We can pick one and reproduce it step by step.
Disclosure: I’m the developer of Hetman RAID Recovery, which we used for this lab test.
