Can I swap between two RAIDs on one NAS?

Yes, you can swap between two RAID configurations on a single Synology NAS by creating a new volume and migrating data. This process requires backing up your current data to an external source, deleting the existing RAID group, creating the new one, and restoring your files. Direct in-place conversion of RAID levels is not supported, so a full backup and restore cycle is mandatory to ensure data integrity during the transition.

Understanding RAID Groups and Volumes

Before initiating any changes, it is crucial to distinguish between a RAID Group and a Volume in the DiskStation Manager (DSM) interface. A RAID Group defines the physical storage layout and redundancy level (such as SHR, RAID 1, or RAID 5) across your hard drives. A Volume is the logical partition created on top of that RAID Group where your data actually resides. You cannot change the RAID type of an active volume directly; instead, you must create a new RAID Group with the desired configuration and then build a new Volume on it. This distinction explains why many users encounter errors when trying to "convert" a RAID. The system does not support live migration of data from one RAID structure to another while keeping the same volume ID. Therefore, the workflow always involves decommissioning the old setup and establishing a fresh environment. For more context on managing multiple disks, see Changing HDDs in Synology DS418: Adding Another Synology NAS.

Prerequisites and Backup Strategy

The most critical step in swapping RAID configurations is ensuring you have a complete, verified backup of all data. Since the process involves deleting the existing RAID Group, all data on those drives will be erased. Do not rely on the NAS’s internal replication features alone for this specific operation, as they may not capture all metadata or application settings correctly if the underlying storage structure is destroyed. Use Hyper Backup to create a comprehensive backup of your shared folders, applications, and system settings to an external USB drive, another NAS, or a cloud service. Verify the backup by attempting to restore a small subset of files to a different location before proceeding. If you are moving from a failing drive scenario, consult How to Access Data from a Dead Synology NAS (4-Disk RAID, Btrfs) to ensure your source data is intact before wiping the drives.

Step-by-Step Migration Process

Once your backup is secure, follow these steps to switch your RAID configuration. This procedure applies to most Synology models running DSM 6.x and 7.x.

1. Delete the Existing Volume: Open Storage Manager, go to the Volume tab, select your current volume, and click Delete. Confirm the warning that all data will be lost. This action returns the hard drives to a "Unassigned" state within the RAID Group.
2. Delete the Existing RAID Group: After the volume is removed, navigate to the RAID Group tab. Select the current RAID Group associated with the deleted volume and delete it. This frees up all participating drives for reconfiguration.
3. Create the New RAID Group: Click Create and select your desired RAID type (e.g., SHR, RAID 1, RAID 5). Assign the appropriate drives and confirm the creation. Ensure the health status of all drives is good before proceeding.
4. Create the New Volume: With the new RAID Group established, go back to the Volume tab and click Create. Follow the wizard to format the new volume. Choose your preferred file system (ext4 or Btrfs) based on your snapshot and compression needs.
5. Restore Data: Use File Station or Hyper Backup to restore your data from the backup source to the new volume. Reconfigure your shared folder permissions and user access rights as needed.

Common Pitfalls and Best Practices

Users often attempt to resize volumes without recreating the RAID group, which leads to unpredictable behavior or data loss. Always remember that RAID level changes require a structural rebuild. Additionally, ensure that your DSM software is updated to the latest version before starting, as older versions may have bugs related to RAID management. If you encounter issues during the rebuild phase, such as slow speeds or failed verification, check the drive health logs in Storage Manager. Slow performance during restoration is normal, especially with large datasets, but interruptions should be avoided. For insights into common rebuild issues, refer to Encountering RAID Rebuild with New NAS: A Common Issue.

Frequently Asked Questions

Can I convert SHR to RAID 5 without losing data?

No, Synology does not support direct conversion between RAID types like SHR and RAID 5 while preserving data. You must back up your data, delete the existing RAID group, create the new RAID type, and restore your files. Any claim suggesting otherwise risks total data loss.

How long does the data restoration take after switching RAIDs?

The duration depends entirely on the amount of data and your network speed. Restoring over a local Gigabit Ethernet connection might take several hours for terabytes of data. Using a faster 10GbE connection or a dedicated backup server can significantly reduce this time.

Will my installed packages survive the RAID swap?

Installed packages reside on the volume, so they will be deleted when you remove the old volume. However, their configuration files are often backed up by Hyper Backup. After restoring the volume, you can reinstall the packages and restore their settings to return them to their previous state.

Is it safe to use Btrfs for the new volume?

Yes, Btrfs is recommended for modern Synology NAS devices due to its snapshot capabilities and data integrity features. Ensure your DSM version supports Btrfs well and that you have adequate RAM for checksumming. It provides better protection against bit rot compared to the legacy ext4 file system.

What happens if power fails during the RAID deletion?

Deleting a RAID group is a quick administrative action that updates metadata rather than rewriting all data blocks. However, any ongoing write operations will be interrupted. To minimize risk, stop all services and disconnect clients before performing the deletion. Always maintain a separate offline backup regardless of precautions.