Converting an ext4 volume to btrfs on Synology
Why mess with a good thing?
I recently undertook an effort to migrate my Synology 920+ from an ext4 to btrfs format. This project was meant to right a wrong when I upgraded to the 920+ from a 213. Prompted with the installation wizard, I did some minimal research on the difference in the formats, and ended up staying with ext4. Two years later, I changed my mind.
What and why
Spending time on the r/synology subreddit, I slowly came to the conclusion that I had made a mistake. There were features built into btrfs that I could leverage, and there were applications that I wanted to use that required it.
- Data self-healing for photography
- Virtual Machine Manager
The issue is that you can’t simply change a volume’s format as a dropdown. A file format is set at the time of volume creation, and is set in stone. The other complicating factor is that the volume, and its ext4 formatting, was spread across 4 hard drives. Migrating data from one format to another, while not losing any of it, was the challenge. Synology’s own documentation states you need to just burn it all down and start all over. I wanted to see if I could make the transition without utilizing a backup.
Backups, backups, and more backups
It cannot be underscored enough: you’re at a significant risk of losing your data by performing this migration. I had three local backups and one cloud backup. Even with four backups I didn’t feel comfortable for the entire time I was going through the process. Backup your data, back it up again, and back it up a third time.
In addition to the data backups, also perform a manual config backup via Control Panel > Update & Restore > Configuration Backup. Save this locally to your machine.
I’m not responsible for any data loss via this process, and would point out that Synology’s recommendation is to backup and delete all storage pools. Backups are key to any process.
My setup
This process worked for my setup, and it is worth checking that it will work on yours.
- 920+
- DSM 7.1.1–42962 Update 1
- 4x 6TB drives
- SHR1
- 16TB usable
- 3.8TB used
The key for the rest of the process here is that all of my data (3.8TB) will fit on a single drive (5.5TB). If the data that you have to migrate is more than a single hard drive, this likely won’t work for you.
Applications are another item that you might use a lot of, but was not a big deal for me. While I use Surveillance Station and Photos, among others, if the system needed to be fully reset and data restored from backup, it wasn’t an issue to reinstall and configure all my applications. If you heavily use applications for production or a significant amount of docker instances, this might not be the right process for you.
Pre-work
There are some steps to take to ensure that your current volume is healthy enough in order to perform this work. There might be more, but these are the ones that I have found in order to ensure that you can feel comfortable degrading your current volume.
Data Scrubbing ensures that the data in storage pools is correct, so that in the event of a drive failure the pool will be able to continue functioning. As the migration steps specifically remove a drive in order to build a new volume, this will be key.
Scrubbing can be enabled by going to Storage Manager > Storage > Storage Pool > Schedule Data Scrubbing. Ensure that you have a successful scrub before proceeding.
S.M.A.R.T tests validate that the drives are healthy enough to continue. Perform extended tests on all drives and follow any prompts or guidance if there are any issues that are found.
Backup Integrity validates that your Synology has access to the Hyper Backup files, so in the event of a disaster they can be used to recover your data. Under each backup task there is a drop down where you can Check backup integrity. Validate each backup has been recently checked.
As an added step to checking backups, utilize the Backup Explorer in order to pull a file from each backup. This is one more check that everything is functioning properly, and if you utilize encrypted backups it will check that the password you have is correct.
Finally, download and store a manual configuration backup to your local machine. Control Panel > Update & Restore > Configuration Backup.
Let’s tear things down
You have your backups done. You have completed all the pre-work to limit chances of significant data loss. It’s time to start tearing down your ext4 volume.
Note: Everything past this line puts your data at risk. Proceed with caution.
The first step is to deactivate a drive. As the current volume is SHR1, there is a single drive of data protection.
At this point your original volume will still be intact, however will not have any data protection until the new btrfs volume is back online and all of the drives have been added to it.
Synology knows the deactivated drive was the drive to complete the degraded pool, and I couldn’t find an easy way to wipe it. I removed the deactivated drive (ensure you know which one it is or you’ll destroy your volume by removing the wrong one) from the chassis and formatted it with my Mac. With a quick format complete, it was time to put the drive back in and create the new volume.
With the drive back in its slot and initialized, create a new SHR1 storage pool, then the new volume, selecting btrfs instead of ext4. Once the drive is formatted, the volume created, it’s time to move the data over.
Synology actually makes this part fairly easy. For each shared folder, edit its settings and change the volume from the ext4 volume to the new btrfs volume. It will copy the data for you and then will be aware of where it moved the data. Do this for all shared folders.
With all the data moved to Volume 2 and the original volume having little data on it, it’s time to deal with the applications. I have read there are a couple of ways that applications can be rebuilt, but I chose to make it cleaner and easier by uninstalling all of my applications. If you try to delete the volume with applications still installed, you’ll get notified like the image below. For things like Surveillance Station and Photos I chose to keep the directory and configurations, but everything was uninstalled.
For all the applications you do use, go back through and install them, selecting Volume 2 as the default instance. For things like Surveillance Station and Photos, I found that they returned to their previous state as they utilize /photos and /surveillance folders for their configurations and data. For anything else, you’ll have to reconfigure them.
With data and applications no longer on Volume 1, it’s time to delete it all together. Once the volume and storage pool are deleted, you’re left with the three additional drives that need to be added to Volume 2. Synology does not have a known pool for them, so you don’t need to remove them and format, simply select them within the new Volume 2 storage pool and choose to expand the volume.
The amount of time it will take to rebuild your SHR1 pool will depend on the size of the drives. For me, it was about 4 days to get everything back to healthy.
At this point, you should have a Volume 2 that is marked as healthy, all your data and applications should be on it, and applications should be configured how you originally had them. Ensure that Data Scrubbing is enabled on the new pool and enable Quick and Extended S.M.A.R.T tests.
Launch Hyper Backup and re-link any of the backups it may have lost during the migration(it did not lose track of any of mine, but I did have to re-link).
The final step can be done on a per-shared folder basis. In order to get the maximum benefit of btrfs, some settings need to be enabled on the shared folder when it is created. As the current shared folders were ext4 when created, they need to be recreated as btrfs with the proper boxes checked.
As an example, I wanted the additional file integrity of btrfs on my Pictures shared folder. I edited the name of the Pictures folder (Pictures_ext), created a new Pictures shared folder, and copied all the data from the old to the new. Once completed, my SMB connections and my Lightroom catalog didn’t notice a difference.
Final Thoughts
I am pretty happy with how it turned out, and am glad I didn’t need to touch any of my backups. I now know more about Data Scrubbing, have better data integrity with self-healing enabled, and feel more confident that my data would survive a disaster. This was a large migration for me, and when dealing with years of data, not one to take lightly. More to come on how I continue to leverage this configuration.
