Recovering network file shares with AWS Elastic Disaster Recovery and AWS DataSync

Data is one of the most valuable assets that a business owns. Protecting that data from disasters, such as system or infrastructure failures, is an important part of business continuity planning. Companies have diverse IT infrastructures in which data can be presented from multiple sources. This includes on-premises network-attached storage devices via different file-sharing protocols, such as Network File System and Server Messaging Block. These types of diverse IT infrastructures and data from multiple sources make it difficult to implement a disaster recovery solution.

Amazon Web Services provides multiple ways to protect your data. In this blog post, I review an architecture that helps protect Server Messaging Block (SMB) dependent workloads to AWS. This architecture can be used for different disaster recovery scenarios, such as on-premises to AWS or within AWS—both cross-Region and cross-Availability Zone. For the purposes of this post, I recover an on-premises Windows application server and business data presented from a Windows file server, to minimize business disruption during a disaster recovery failover event. I use an Amazon Elastic Compute Cloud (Amazon EC2) instance for the recovered Windows file server and Amazon FSx for Windows File Server as the destination network-attached storage, which will host the SMB data. This method is also applicable for other on-premises workloads with a dependency on shared folders or disks located on other servers or on network-attached storage (NAS) devices, such as a NetApp appliance.

Overview

This post uses AWS Elastic Disaster Recovery (DRS) to protect the compute and block storage. AWS DataSync securely migrates the SMB data to Amazon FSx for Windows File Server.

Elastic Disaster Recovery provides scalable, cost-effective business continuity for physical, virtual, and cloud servers. Elastic Disaster Recovery uses continuous block-level replication to achieve a business recovery point objective (RPO) of seconds and a recovery time objective (RTO) of minutes.

AWS DataSync is a data migration service that simplifies, automates, and accelerates moving data between on-premises storage systems and AWS storage services and between AWS storage services.

Amazon FSx for Windows File Server provides fully managed, highly reliable, and scalable file storage built on Windows Server that is accessible over the open standard SMB protocol.

Prerequisites

This post assumes you have the following prerequisites in place:

• A Windows file server that hosts an SMB share.
• A Windows application server that has a mapping to the SMB share.
• AWS Elastic Disaster Recovery has been initiated in the target Region, and the replication agent is installed onto the Windows application server.
• Amazon FSx for Windows File Server file system deployed in the target Region.
• AWS DataSync agent has been deployed.

For assistance setting up Amazon FSx for Windows File Server, see the Amazon FSx for Windows File Server quick start documentation.

For assistance setting up AWS Elastic Disaster Recovery, reference the AWS Elastic Disaster Recovery quick start documentation.

For assistance setting up the AWS DataSync agent, reference the AWS DataSync quick start guide.

 Architecture

­­

The architecture for this project has an EC2 Windows Server, acting as an on-premises file server. It hosts an SMB share called “share” and an additional EC2 Windows Server acting as an SMB-dependent application server with access to the SMB share.

The file servers SMB share replicates into Amazon FSx for Windows File Server within the target AWS Region using AWS DataSync.

The SMB-dependent application server replicates into the target AWS Region using AWS Elastic Disaster Recovery.

Note: Amazon FSx file system was pre-created and configured in the target Region to connect to the Active Directory domain.

Setting up AWS DataSync replication to Amazon FSx for Windows File Server

The first step is to define the source and target locations for the data replication.

1. Open the DataSync service and click on Create Task. Within Step 1 of the wizard, select Create new location to define the source location.

2. Select Server Message Block (SMB) under Location type. Select the AWS DataSync agent and enter the file server IP address.

3. Enter your SMB share name in Share name and select Next.

4. Within Step 2, select Create new location to define your target location.
5. Select Amazon FSx for Windows File Server under Location type.
6. Select the FSx file system and Share name. Select Next to move to Step 3.

7. Configure your DataSync verification settings and synchronization schedule. For the purposes of this post, defaults are used. A full explanation of the available settings can be found in the AWS DataSync documentation.

Note: AWS DataSync and AWS Elastic Disaster Recovery do not share the same synchronization schedule. It is important to consider any impact this may cause at an application level, should your use case require that both data sources share the same recovery point.

8. Review your Task summary and complete the creation of the task by clicking Create task.

Once the task is created, you can manually initiate it by selecting Start under the Actions menu.

Within the Task History, you can see that the task was successful.

Once the DataSync task is complete, confirm that the data is present within the target Amazon FSx file system.

Then initiate recovery of the application server.

Recovering the application server with AWS Elastic Disaster Recovery 

1. Within the AWS Management Console, navigate to the AWS Elastic Disaster Recovery service. Then go to the Source servers page, select windows-application-server, then select Initiate recovery under Initiate recovery job.
2. Select the most recent recovery point of the server:

3. Once the job completes, access the recovered application server and ensure that the SMB data is accessible.

If your application connects to the SMB share via a DNS alias record, either manually change this or automate this by amending the user data script within the launch settings.

4. Validate that all expected files are present.
   

Failback

Fail back to the source environment can be achieved by performing the following steps:

1. Pause the previous DataSync task.
2. Create a new task using the Amazon FSx file system as the source and your on-premises SMB share as the destination. This replicates back any changes made during the failover to the original source share.
3. Fail back the application server using AWS Elastic Disaster Recovery. Follow the steps for failback within the AWS Elastic Disaster Recovery documentation.

Cleaning up

If you followed the preceding steps, then you may have resources running that would incur further charges. Consider deleting the following resources if you no longer require them.

1. Amazon FSx file system used as the target.
2. DataSync agent and the supporting tasks.
3. EC2 instance (Windows application server) created during the AWS Elastic Disaster Recovery failover.

Conclusion

Protecting data from disasters is an important part of a business continuity strategy. With diverse IT infrastructures and data from multiple sources, it can be difficult to implement a disaster recovery solution. This blog post showed you how to create an on-premises or cross-AWS Region disaster recovery strategy for servers that have Network File Systems as a dependency. This architecture provides block-level protection using AWS Elastic Disaster Recovery and file system protection using AWS DataSync and Amazon FSx for Windows File Server. If you have any comments or questions, you can share them in the comments section.