Important note: Modifying AccountServer settings may result in data loss and should be attempted with caution. Contact Redstor Support for assistance if unsure how to proceed.
Different scenarios apply for failovers - it may be necessary to fail over the AccountServer and/or StorageServer(s) depending on the platform architecture and what has failed. The sections for promoting and failing are optional depending on the scenario, but the steps should be completed in full for each of these.
Promoting the Slave AccountServer
Preparing to fail back: AccountServer
Preparing to fail back: StorageServer
Optional: Post-failback Integrity Check
Failover
The failover process consists of three phases: promoting the Slave AccountServer to a Master, promoting the MirrorServer to a StorageServer, and then resuming backups as normal.
Promoting the Slave AccountServer
- Stop the AccountServer service on the Slave.
- In the AS_Service folder (default location C:\ProgramData\Attix5 Pro), edit the Settings.xml file by changing the “IsSlave” value to false:
<IsSlave choices="True,False" default="False">False</IsSlave>
- Restart the AccountServer service.
- On the AccountServer, create an empty text file named "Failover.UpdateSettingsOnSS" and place this file in the task queue. This will update the account's HomeServerGUID to sync the account settings to the promoted server.
- Login to the Storage Platform Console.
- For each StorageServer to be failed over, right-click on its name, point to Advanced and click Change StorageServer address.
- Enter the host name or IP address and port number for the appropriate MirrorServer.
- On the AccountServer, create an empty text file named "Failover.UpdateSettingsOnSS" and place this file in the task queue. This will update the account's HomeServerGUID to sync the account settings to the promoted server.
Agents whose mirroring is up to date will back up as normal. For Agents whose mirroring is not up to date, the StorageServer will request that the relevant files be resent, which will occur with the following backup. Agents that were backing up to the primary site when the failure occurred will start a fresh, normal backup.
Failback
There are two reasons to fail back:
- The primary site is back online.
- The primary site is irrecoverable, and a new primary site must be created.
In the latter case, a new Slave AccountServer should be installed and added to the promoted Slave. Additionally, new StorageServers should be installed and added to the Storage Platform as MirrorServers for the promoted MirrorServers, and mirroring should be allowed to complete. A failback to the new primary site can then be initiated.
Preparing to fail back: AccountServer
1. Stop the original AccountServer service if it is running. No Slave AccountServers should be running.
2. In the AS_Service folder (default location C:\ProgramData\Attix5 Pro), open the Settings.xml file and add the following line:
<IsSlave>True</IsSlave>
Note down the ServerGUID, which will look something like this:
<ServerGuid>a40b132e-b8b1-4316-b1f2-c27d301ad2e5</ServerGuid>
Save and close the updated Settings.xml file.
3. Using SQL Management Studio, open the StoragePlatform database. In the BackupServer table, locate the Slave AccountServer.
4. If its ServerGUID matches the ServerGUID for the demoted Master AccountServer, edit the entry: change its IP to that of the demoted Master AccountServer, and set OnLine as True. If the Slave AccountServer’s ServerGUID does not match that of the demoted Master AccountServer, the latter needs to be added to the database anew. In the SP Console, while connected to the promoted Slave, add the Master AccountServer to the Storage Platform as a Slave AccountServer. The first eight characters of the ServerGUID form the one-time password.
5. Close the BackupServer table and restart the AccountServer service. Reconnect the Console to the promoted Slave AccountServer. The demoted Master AccountServer should now be present as a Slave.
Preparing to fail back: StorageServer
1. On the demoted StorageServer, navigate to the SS_Service folder and open the Settings.xml file.
2. Note the first eight characters of the ServerGUID.
3. Restart the StorageServer service.
4. Using the Console that is connected to the promoted Slave, add the demoted StorageServer as a mirror for the appropriate promoted MirrorServer (there will now be two mirrors for the StorageServer).
5. Configure the demoted StorageServer to not mirror to the promoted MirrorServer.
6. Remove the secondary mirror using right-click > Delete.
Note: Read the prompts carefully to avoid the accidental deletion of a backup account. If you click Yes accidentally, please contact Redstor Support for assistance.
7. Configure the promoted MirrorServer to mirror back to the demoted StorageServer and allow mirroring to complete.
8. You should now be running with full redundancy, but with the primary and secondary sites reversed.
1. Using the Console, connect to the promoted Slave AccountServer and trigger a manual database backup.
2. Check the diagnostics to confirm that this has completed successfully.
3. Using the Console again, connect to the demoted Master AccountServer to confirm that it is up to date.
4. Stop the AccountServer service on the promoted Slave.
5. On the demoted Master AccountServer, stop the AccountServer service, navigate to the AS_Service folder and open the Settings.xml file. Set the “IsSlave” value to False:
<IsSlave choices="True,False" default="False">False</IsSlave>
6. Restart the AccountServer service and connect using the Console. The original Slave should be shown, but will be offline as the service has been stopped.
7. If DNS changes have been made to redirect Agents to the Slave AccountServer, these should now be reverted.
8. On the Slave AccountServer, navigate to the AS_Service folder and edit the Settings.xml file. Add the following line:
<IsSlave choices="True,False" default="False">True</IsSlave>
9. With both the Master and Slave AccountServer operational, trigger a database backup from the Master.
10. When complete, restart the Slave AccountServer service. You will still be running at full redundancy, but with the Master AccountServer on the original site, and the StorageServers still running from the MirrorServers at the secondary site.
When failing back, it is useful for StorageServer and MirrorServer data to be synchronised. If they are not, integrity checks may occur, and data may be resent from the Agent. To ensure synchronisation, it’s best to block backups for a short period to allow mirroring to complete. To block backups, open the Console in the Account Management view. Make sure that the Group Is Disabled checkbox in the Expiry tab is ticked for each Group.
1. Wait for mirroring to complete.
2. Navigate to Storage Platform Configuration view in the Console. Select each promoted MirrorServer in turn, and for each, disable mirroring to the demoted StorageServer.
3. Right-click each demoted StorageServer and select Delete.
Note: Read the prompts carefully to avoid the accidental deletion of a backup account. If you click Yes accidentally, please contact Support for assistance.)
4. On the promoted MirrorServer, stop the StorageServer service. Note the first eight characters of the ServerGUID from the Settings.xml file. You will need this as a one-time password when re-adding the MirrorServer.
5. In the SP Console, right-click the name of the demoted MirrorServer. Point to Advanced and click Change StorageServer address. Enter the IP address or host name and port of the original StorageServer. When complete, restart the StorageServer service.
6. On the MirrorServer, start the StorageServer service again.
7. In the Console, right-click the name of the StorageServer and click Add MirrorServer. Enter the host name or IP address and port, and the first eight characters of the ServerGUID into the One Time Password field (this can be found in the MirrorServer’s Settings.xml file.
8. If you are confident that the mirror data is up to date, re-enable mirroring. Mirroring operations will resume as normal, with data that is present on the StorageServer being sent to the MirrorServer. Data from accounts for which mirroring did not complete prior to the initial failover may need to be sent. If the servers are fully synchronised, there should be nothing to send.
9. On the AccountServer, create an empty text file named "Failover.UpdateSettingsOnSS" and place this file in the task queue. This will update the account's HomeServerGUID to sync the account settings to the original server.
10. Finally, in Account Management, re-enable all Groups.
Optional: Post-failback Integrity Check
You may wish to check the integrity of certain backup accounts, particularly those for which mirroring did not complete prior to the initial failover. See Article 1103 for instructions.
Comments
1 comment
The article makes no mention of the need to update the accounts' HomeServerGuid and sync the account settings to the promoted server.
Article is closed for comments.