AWS Migration Service not synchronising changes from Source server

0

Hi I've used the AWS Migration Server to move a local (VM) Windows 2016 server to an AWS EC2 instance. The initial migration went well with no errors, and transferred around 800GB storage over three volumes. . I have launched a test instance. I can RDP in to the new AWS server. The AWS console shows "Healthy" status, and "Test in progress" under the Migration Lifecycle.

My understanding was that until I cut over, all changes on the source server would be replicated to the AWS server. I created a simple TXT file on an existing directory called D:\MyFolder on the source server but it hasn't appeared on the AWS server. This was over 18 hours ago and there have been lots of snapshots in the meantime. No errors I can see on the AWS Console. The various AWSReplicationService services appear to be running on the source server. Nothing else has changed so pretty sure firewall/network connectivity is ok as otherwise surely the initial migration wouldn't have worked?

Any clues? Is my understanding of how the ongoing replication should work correct?

1 Answer
1
Accepted Answer

You're right about data continuing to be replicated until you have completed the final cutover. The data is always replicated only to the EBS volumes attached to the replication instances and the snapshots that MGN continuously makes of them. The test instance you launched is a snapshot of the server as it was just moments before the test instance was launched (specifically, the moment when the EBS snapshots were started). MGN won't modify data on the test instance after it's been launched.

To see changes made on the source server after the test instance was launched, you'll have to complete or cancel the current test and launch a new test instance.

It would be practically infeasible to keep a running server replicated with changes from a source server in a meaningful way, simply due to the ways that operating systems are designed to rely on their autonomy in managing their memory, file systems, and the underlying block storage. The upside is that this structure also allows you test your post-cutover activities, such as removing VMware Tools, hardware drivers, old monitoring or backups tools, and so on, in a way that matches the final cutover. You can rehearse the post-migration steps as many times as you need to get it to go just as you want by cancelling/completing the test and starting a new one.

EXPERT
answered 9 months ago
profile pictureAWS
EXPERT
reviewed a month ago
  • Thank you for the reply Leo. Whilst I understood your very clear explanation it took me a while to work out how to do what you suggested. So for anyone else facing the same issue.

    1. With the source server selected in the AWS Migration Service windows, using the Test and Cutover dropdown menu I choose "Terminate launched instances". A selected to remove those test instances.
    2. I waited 10 mins or so until that job reported as completed (green bar at the top)
    3. Then using the same menu I choose "Launch test instances"
    4. I had to re-apply my Elastic IP in order to RDP to the box (I suspect setting up a template could automate this but I only have two servers to do so won't bother)
    5. Once logged into the AWS instance I was able to confirm my test file (i.e. the one I had created on the original source server) was there.

    Thanks again for your prompt and detailed reply.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions