How to recover data from Synology NAS after a failure during migration from RAID 1 to RAID 5?
-
Author:
Vladimir Artiukh
-
Editor:
Oleg Afonin
Imagine that you add a drive to a Synology NAS and start migrating from RAID 1 to RAID 5 to increase storage capacity. But during the rebuild, power is suddenly lost and the NAS shuts down. After power is restored, it turns out that one of the original drives is no longer detected, and there is no access to the files. What should you do if there is no current backup of the required data? Can files be recovered from the two surviving drives when the migration to the new RAID level was never completed?
- STEP 1. Test environment
- STEP 2. Connecting the drives to a Windows computer
- STEP 3. Results of the RAID 5 analysis
- STEP 4. Manual RAID reconstruction
- STEP 5. Determining the data start offset
- STEP 6. Automatic detection of RAID parameters
- STEP 7. Searching for data in the original RAID 1 configuration
- Conclusion
- Frequently Asked Questions
- Comments
The migration of an array on a Synology NAS from RAID 1 to RAID 5 usually completes without data loss. However, a power failure, drive errors, or interruption of the process can result in storage degradation or complete inaccessibility. In such a situation, the main thing is to avoid hasty actions that may complicate recovery. In this article, we will examine how to properly assess the state of a Synology RAID array after an emergency migration and which methods can help restore access to the data.
Synology NAS Data Recovery After a Failed RAID 1 to RAID 5 Migration
STEP 1. Test environment
For the test, we used a Synology DS409 network storage device running DSM 4.2 and three hard drives, each with a capacity of 320 gigabytes.
Initially, two drives were combined into RAID 1 — a mirrored array in which data was duplicated on both drives. A volume with the Ext4 file system was created on it, and approximately 110 gigabytes of test data were written: documents, photos, videos, and archives. The files were placed in directories with several levels of nesting so that we could later verify the preservation of both their contents and folder structure.
Then the third drive was added to the array, and Storage Manager was used to start the RAID level change from RAID 1 to RAID 5.
This migration allows the available storage capacity to be increased while retaining protection against a single drive failure after the operation completes successfully.
When the rebuild indicator showed 29.55 percent, power to the NAS was intentionally disconnected without a proper shutdown. After that, one of the two original RAID 1 drives was removed, simulating complete inaccessibility.
As a result, two drives remained available for recovery: one drive from the original mirror and the third drive added for the transition to RAID 5. The rebuild was not completed, so part of the data had already been relocated, while the rest was still stored according to the previous scheme. These two drives will be used for the next steps.
STEP 2. Connecting the drives to a Windows computer
We move to a Windows computer with Hetman RAID Recovery installed.
We connect the two surviving drives via a USB dock station:
- one of the original RAID 1 drives;
- the drive added for the transition to RAID 5.
The second member of the original mirror is unavailable in our test.
We launch the program. In the RAID Arrays section, we see the automatically detected array DiskStation:2.
We select it and review the information on the Preview panel on the right. The program has identified the RAID 5 type, Left Synchronous block order, and a block size of 64 kilobytes.
Below, in the RAID Disks list, we can see two connected drives and an Empty disk position corresponding to the missing member. For both available drives, the same data start offset is specified — we will return to this parameter during manual reconstruction.
The list also contains two small RAID 1 arrays of approximately 2.37 and 2 gigabytes. They correspond to Synology system areas.
These arrays should not be confused with the original mirror that contained our test files.
The original RAID 1 with user data is no longer displayed separately.
STEP 3. Results of the RAID 5 analysis
Let us check what is available through the automatically detected RAID 5 configuration. To do this, open the Ext4 volume in this array by double-clicking it. In the analysis wizard, select Fast scan and click Next to start searching for files.
The available portion of the test data: after analyzing RAID 5, the program found 390 folders and 8,239 files. In the results, we can see the My Data folder and nested directories with test files. Part of the original structure was preserved: the program shows folder and file names and their locations.
Thus, even with two available members of the interrupted array, part of its contents could be read. To save the required files, select them, click Recovery, and specify a folder on a separate drive that is not part of the array being recovered to avoid overwriting the source data.
However, not all files written before the test are present in the results. Before the migration, the data was stored on two drives as mirrored copies. During the transition to RAID 5, the system gradually changed the block layout, distributing it across three drives and creating parity.
As a result, areas with different data organization remained on the surviving drives. The RAID 5 layout corresponds to the block placement in the already rebuilt areas, while the previous RAID 1 organization remains in the rest, although the mirror itself is no longer automatically detected.
Therefore, the absence of a file in these results does not yet prove that its contents are completely lost.
STEP 4. Manual RAID reconstruction
In our case, the program automatically identified RAID 5 and its parameters. But what if the configuration must be specified manually or some settings are unknown? For this purpose, Hetman RAID Recovery includes the RAID Constructor. Using the detected RAID 5 as an example, let us examine its capabilities and then use this tool to reconstruct the original RAID 1.
We open the RAID Constructor, select RAID 5, and add the two available drives. The missing member is marked as Empty disk. This gives us three positions corresponding to the array composition during migration.
In the RAID 5 configurations we tested on Synology, the Left Synchronous block order and 64 kilobytes block size were often encountered, so we will use this combination in the constructor. In our case, it also matches the parameters of the automatically detected array.
However, these values are not universal: for another set of drives or storage device, they must be checked separately, taking into account the array configuration and change history.
Separately, it is necessary to specify the data start offset for each drive, so first we will examine where to find it and how to calculate it.
STEP 5. Determining the data start offset
The offset indicates which initial portion of the drive must be skipped before reading the blocks of the user array. On the physical disk diagram, we can see the Synology system partitions and the partition used to store our files. In this test, it starts at sector 9,437,184. This is our reference point. The RAID data itself starts slightly later, because there is space for system information at the beginning of the partition.
We open the physical disk in HEX Editor. To go to the beginning of the required partition, first convert its starting sector to a byte address. On the calculator, multiply 9,437,184 by the sector size — 512 bytes. The result is 4,831,838,208 bytes. Convert the result to hexadecimal and go to this address in the editor.
From the current position, start a forward search. Select hexadecimal search and enter the signature FC 4E 2B A9. This allows us to skip the initial Synology system partitions and search for the EXT superblock in the partition containing our files.
The required match is found at address 120001000. Nearby, in the text part of the editor, we can see the name DiskStation:2. The signature alone is not sufficient, since such a byte sequence can also occur within other data.
Now let us find the data_offset field, which indicates the RAID data start offset within the partition. In this superblock format, it is located 128 bytes from the beginning and occupies eight bytes. In our case, this is the first eight bytes of the line at address 120001080.
The value is stored in little-endian order. In standard notation, this number is 800 in hexadecimal format. Enter it into the calculator and switch to decimal format — the result is 2048 sectors. This is the distance from the beginning of the partition to the beginning of the RAID data. Therefore, we add 2048 to the partition’s starting sector. We get 9,439,232 sectors. Multiply by 512 bytes — the final offset from the beginning of the physical disk is 4,832,886,784 bytes. It matches the value in the properties of the automatically detected RAID 5.
STEP 6. Automatic detection of RAID parameters
We return to the RAID Constructor and specify the determined offset for each available drive. Now we can use automatic detection of the unknown parameters.
If the block size or block order is unknown, you can select Detect automatically in the Block size and Block order fields. To determine the member order, there is a separate Detect the disk order automatically option. For example, we can leave RAID 5, Left Synchronous, and a 64-kilobyte block size, but let the program determine the disk order.
After proceeding to the next step, the program begins searching for configurations that match the specified conditions. The found options are displayed in a list. Select the required configuration and click Add.
After that, the assembled RAID will appear on the program’s main screen, where it can be opened for analysis and file search.
Now let us use the constructor for another task — we will check the surviving drive of the original mirror in a RAID 1 configuration.
STEP 7. Searching for data in the original RAID 1 configuration
We return to the RAID Constructor and select RAID 1. We add the surviving drive of the original mirror, and mark the missing member as Empty disk.
We specify the verified data start offset. This tells the program how to read the data according to the previous scheme. This is a virtual reconstruction for analysis: it does not undo the migration or restore the drives to their pre-incident state.
The assembled RAID 1 will appear on the program’s main screen.
We open it by double-clicking and select Full analysis in the analysis wizard. Specify the Ext4 file system and start the analysis.
After completion, the program found 979 folders and 14,049 files. For comparison, after Fast scan of the RAID 5 configuration, we obtained 390 folders and 8,239 files. These numbers do not indicate the number of unique valid files: the results may contain duplicates and require verification.
We review the found data. The original directory structure was not fully reconstructed, and some of the found objects are located in Lost and Found.
Restoring the folder tree requires preserved file system metadata structures and the relationships between them. After an interrupted migration, data of an individual file may be readable in the selected configuration, while the records that linked it to the original directory may be unavailable. Therefore, the absence of a familiar folder does not necessarily mean that all of its contents are lost.
To find the required files more quickly, use the Find File function. In the search window, enter the full name or part of it and click Find. If necessary, you can enable case-sensitive search or restrict the search to whole-word matches only.
We review several files in different formats, including those found through search. In the Preview window, we check images, document contents, and other files available for preview. This allows us to identify the required data and assess its contents before saving.
Conclusion
In this test, we examined the loss of a drive after an interrupted Synology migration from RAID 1 to RAID 5. Hetman RAID Recovery automatically detected RAID 5 based on the preserved metadata, but only part of the original data was available through this configuration.
We therefore also analyzed the surviving drive of the original mirror as RAID 1. In the results, we found files whose contents can be viewed, although the directory structure was not fully reconstructed.
This case shows why, after an incomplete migration, it is important to consider the previous array configuration: its current metadata does not necessarily describe the location of all data on the drives.
A current backup greatly simplifies recovery after an incident. If one is not available, analysis of the preserved data may help recover at least part of the files — which is exactly the scenario we examined here.
