1154 - How to employ failover and failback measures in migration

Modified on Mon, 21 Jul at 12:52 PM

Migrating the AccountServer

When an AccountServer needs to be migrated to new hardware or a new site, or when it is decommissioned, failover and failback measures can be employed to ensure that no data loss occurs. Simply follow the steps below.

  1. Failover to the Slave AccountServer.
  2. Move the original (Master) AccountServer to its new location as required.
  3. If the Master is to be decommissioned, create a new Slave AccountServer, and fail back to it.
  4. If the Master is to remain in use, fail back to it.

 

Migrating the StorageServer

When a StorageServer needs to be migrated to a new data centre or host, you may prefer to do this by promoting a MirrorServer to a StorageServer. Failover and failback measures can be employed to ensure that no data loss occurs. Simply follow the steps below.

  1. Promote the MirrorServer to a StorageServer and failover to this StorageServer.
  2. Move the original StorageServer to its new location as required and turn it back on. Alternatively, if the original StorageServer is being decommissioned, you can create a new MirrorServer to fail back to.
  3. Run Integrity Checks on the data on both the original StorageServer and on the promoted MirrorServer.
  4. Mirror back to the original StorageServer, and run an Integrity Check again.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article