Skip to main content

Hi Team,

Our M365 Backup environment is in AWS.

Access Node + Media Agent and index server are built in DMZ account in AWSand our S3 Bucket are in Share services account in AWS.

When backup runs it casues egress charges for moving data from DMZ to shared service account.

To mitigate this egress changes we are thinking to move the Access Node + MA and Index server from DMZ account to Share services account in AWS.

Rquest you to please help me how we should perfom this migration activity from Commvault end.

 

Regards 

Rahul Raina

 

@mikevg @Navneet Singh @Nutan Pawar G @Javier @Scott Reynolds @Jos Meijer 

 

Please team any help on the above query.


Hi @Rahul18081 

In this migration your biggest challenge is possibly the index.
But let's take a step by step look at the high over plan, assuming the MA is completely moved from DMZ to AWS:

  • Prepare a media agent in AWS
  • Prepare an access node in AWS
  • Prepare an index node in AWS

Now you need to introduce a cut over moment, so stop processing the O365 backup and recoveries.

When finished, make sure you have a copy of the folder containing the files for the SOLR Cores which resides on the index server.

  • Adjust the data path sharing for the S3 bucket so the new MA can access it.
  • Change the MA on the Storage Policy copies for the S3 Bucket.
  • Migrate the DDB and Index Cache to the new MA
  • Adjust the O365 configs so the new access node is used, validate the apps you have configured to see if communication is working as expected.
  • Configure the index server with needed for O365.
  • In the O365 plan adjust the index server to represent the new index server.

Now the index server…

You have a few options here:

  • Commvault instruction:
    Restore the SOLR backup to the new index server based on this instruction, please note there are 2 sub pages depending on the drive where you installed the index server: Index Server Cloud Recovery (commvault.com)
  • No Commvault instruction:
    Replay the index from backup, this is a one shot only option, if an error occurs you wont be able to trigger this possibility again due to a database setting which is changed.
    Trigger a backup for each O365 config, the system will see that there is no index available on the new index server and will replay all backup data to rebuild the index, might take a few hours depending on the amount of backup data and resources on the MA and Index Server.
  • No Commvault instruction:
    Perform an manual in-place copy action. Remember the copy you had to make of the folder with the SOLR cores? Here it comes in to play. As the Index Server is already configured with the roles needed for O365, the core configuration should be in place. This can be checked by either looking for O365 folders existing in the folder containing the SOLR Cores or by checking via 
    http://<indexserverhostname>:20000/solr
    If so then you can stop the services for the index server, make a copy of the existing Core folders. Replace the Core folders for O365, so not the whole folder containing all data, only the mailbox, onedrive, sharepoint, teams folders.
    Start the index server again and the server will pickup the data.
    Perform a browse and restore to validate the index can be accessed.

When finished you can resume the O365 backup and recovery.
If all works well, shut down the old MA, Index Server and Access Node.

Hope this helps 😋


@Jos Meijer Thanks for the update.

Can we do the below.

Take the AWS snapshot of the Access Node + MA and Index server.

Move the AWS snapshot from DMZ account to Shared Services Account.

Disable all activities on the Commserver and MA and put MA in MM mode.

Restore Access Node + MA and Index server with same name but different ip.

Enable all activites on Commserve and MA and remove the MA from MM mode.

Perform health checks for M365 components and Media Agent and S3 bucket.

Run test backup and restore.

 


Hi @Rahul18081 

Not sure if this is possible in AWS, but if this snapshot procedure can be done on AWS level then yes 😋
Don't forget to adjust DNS, or Client hostnames if you use an IP based config.


Reply