Migrating back from Amazon FSx to on-premises file servers

In a previous article, I showed how AWS DataSync could be used to copy data from an on-premises file server (Either physical or virtual) into an Amazon FSx Windows file server. Amazon FSx is a fully managed, highly reliable, and scalable file storage that is accessible over the industry-standard Service Message Block (SMB) protocol. This is ideal for customers who are looking to migrate workloads to VMware Cloud on AWS and start taking advantage of native cloud services to improve resiliency and cost. When it comes to customers who want to utilise VMware Cloud Disaster Recovery to failover their environment into VMware Cloud on AWS but then failback to on-premises once the on-premises environment has been recovered things start to get a little tricky. AWS DataSync does not support copying data back from AWS (FSx, EFS or S3) to on-premises so this has to be performed manually. This post will showcase the steps required to copy the data back from Amazon FSx to on-premises which can be incorporated into your failback process to ensure that there is no data loss.

We first need to ensure we change the existing AWS DataSync task to either run manually or delete it completely to avoid having old data copied (If available) back into FSx which could potentially cause some inconsistencies. Navigate to the AWS DataSync service and either delete the task:

Or change the task schedule to Not Scheduled which means you have to start it manually:

Typically I would recommend stopping the share to 100% confirm that there are no users accessing it during the data copy but its looks like this is not supported within FSx. An alternative would be to modify the NTFS permissions to ensure that no one has write access to the folder prior to starting the data copy. There should be no issues stopping the share or modifying the NTFS permission on-premises but just ensure the account that you use to start the data copy has write access to the folder.

In my example here I am assuming that I have lost the file servers on-premises prior to invoking DR so I will need to ensure I complete a full data copy back but this would also work if we were just copying back any modified data. Before starting we need to ensure we have access to a VM that has access to both the on-premises share and also the FSx share. I'm going to be using a VM running in VMware Cloud on AWS that can access FSx across the ENI and on-premises across a VPN. 

Start by mapping both shares to the host VM:

We then use RoboCopy to copy the files, including NTFS permissions and timestamps from the source drive (Amazon FSx) to the target drive (On-Premises):

robocopy Y:\ Z:\ /copy:DATSO /secfix /e /MT:8

• Y – Refers to the source share located in the on-premises Active Directory forest mydata.com.
• Z – Refers to the target share \\amznfsxabcdef1.mydata.com\share on Amazon FSx.
• /copy – Specifies the following file properties to be copied:
• D – data
• A – attributes
• T – timestamps
• S – NTFS ACLs
• O – owner information
• /secfix – Fixes file security on all files, even skipped ones
• /e – Copies subdirectories, including empty ones
• /MT:8 – Specifies how many threads to use for performing multithreaded copies

AWS have this documented here but refers to copying data from on-premises to Amazon FSx. The only issues that I can currently see are the /b and /copy U switches do not seem to be supported due to the permissions we have on the Amazon FSx server. I will see if I can speak to someone at AWS around the roadmap for this and any potential issues this will cause.

Once we modify the RoboCopy command to reference the host VM mapped drives we can start the data copy:

Depending on bandwidth and the size of the files it may take some time to replicate the files back to on-premises. Once it finishes you should have an exact copy of the files back on-premises including NTFS permissions and correct timestamps:

We can then re-enable/re-create the AWS DataSync task once we have verified the data has copied successfully so start the replication back into Amazon FSx in the event of having to invoke DR again in the future.