Microsoft ReFS backup: Ensuring compatibility and testing

When Microsoft first introduced NTFS back in the '90s, many administrators unexpectedly discovered that they were unable to back up computers that used the new file system.

Although this might seem like a lesson in ancient history, history does sometimes repeat itself.

When Microsoft released Windows server 2012, they introduced the Resilient File System (ReFS). ReFS is Microsoft's first new file system in well over a decade (unless you count minor revisions to legacy file systems).

As was the case with NTFS so long ago, blindly implementing ReFS can have consequences. As such, it is critically important to perform lab testing prior to implementing ReFS in a production environment.

There are many different ways that you can test the ReFS file system, but some of your initial testing should be geared toward making sure that ReFS works with your backups.

Before you even begin the testing process, it is a good idea to contact your backup vendor and make sure that its software supports ReFS backups. The vendor may tell you that your backup software needs to be updated with a patch. Some backup vendors have allegedly told customers that ReFS backups work, but are not officially supported.

More often however, vendors have stated that ReFS support will be added in the next release. For example, Symantec's Backup Exec 2012 does not support the ReFS file system. Symantec has stated that ReFS support will be added in Backup Exec 2012 r2. This release will also add support for other Windows Server 2012 features, such as Hyper-V and Windows Server 2012 failover clusters.

Still other vendors take a completely different approach to supporting backups of the ReFS file system. Commvault has stated that change journal and data classification scan methods are not supported on ReFS volumes, due to issues with their agent. They recommend performing a classic scan instead.

Regardless of the backup software you are using, it is important to determine your backup vendor's policy on backing up ReFS volumes.

After checking with the backup vendor, the first and most basic test that you should perform is a simple check to make sure that your backup software is able to make a backup of a ReFS volume. Assuming that your backup software is able to back up a ReFS volume, the next step is obviously to perform a restore test. However, there is more to verifying ReFS compatibility than simple restore and done testing.

When you are initially testing your backup software's compatibility with the ReFS volume, I recommend that you perform the tests using file server data. The reason for this recommendation is that file data commonly contains a very diverse set of permissions. Restoring file server data to a lab server will help you to verify that the permissions remain intact throughout the backup and recovery process.

It is also a good idea to talk to your backup vendor and determine the maximum file size and maximum volume size that your backup software can accommodate.

The reason for this is that ReFS offers greater scalability than NTFS. The theoretical maximum file size on an ReFS volume is 16 exabytes, with a maximum theoretical volume size of 1 yottabyte. Organizations are unlikely to have such large files and volumes today (especially given the hardware limitations), but data may eventually grow larger than what an NTFS volume could accommodate and this might cause the backup software to break, unless you have verified the software's scalability limits ahead of time.