200 likes | 495 Views
Backup, Restore, and Server Replacement. Josh Rose UCBU Software Engineer. Topics. Changes from UC 2.x DRS Implementation Single Server Backup Configuration Cluster Backup Configuration Running a Restore from Backup Online Cluster Server Replacement
E N D
Backup, Restore, and Server Replacement Josh Rose UCBU Software Engineer
Topics • Changes from UC 2.x DRS Implementation • Single Server Backup Configuration • Cluster Backup Configuration • Running a Restore from Backup • Online Cluster Server Replacement • Method uses live data syncs and does not use DRS • Re-installing one server at a time, avoids service interruption • Offline Cluster Server Replacement • Method requires a DRS backup and restore • Fresh installs, running with backup restored
Changes from UC 2.x Disaster Recovery • Multiple Message Stores • -Each message store has its own DRS component for backup and restore (message store component names: “CONNECTION_MESSAGES_UNITYMBXDB1”, “CONNECTION_MESSAGES_UNITYMBXDB2”, etc) • -Message store backups temporarily unmount the message store and queue up messages in file system in order to ensure backup integrity. • -Message stores can be restored independently of other components. • Changes for CUC 2 node cluster (“Active/Active”) support • DB Backups are now Compressed • -Database backups should now be between 20~50MBs instead of around 100~1000MBs
Configuring Backups • Admin logs into the Disaster Recovery interface using platform administration credentials. • If no backup device is defined one needs to be created (either pointing to an SFTP server directory, or a locally connected tape drive). • -Within the DRS interface you would navigate to Backup -> Backup Device to add a new device, or to edit an existing one. • -(Recommended) The admin navigates to Backup -> ManualBackup, and runs a test backup using the new backup device. • The admin navigates to Backup -> Scheduler -> AddNew, to create a new scheduled backup task.
Cluster Backup Configuration • Backup configuration for CUC cluster servers is the same as single server backup configuration. • Each cluster server is backed up separately. • When SFTP is used it is recommended that each server has its own backup folder on the server; so neither server will age out the other’s backup files. • For restore it is only required that one server in the cluster is backed up; however a customer could choose to backup both servers.
Restoring Single Server from a Backup(same as CUC 2.x restore process) • If a re-install was needed, the administrator re-installs meeting the following requirements: • -The same software version as the backup was taken with must be installed. • -Using the same hostname and IP address as the backup was taken with. • The admin navigates to the Disaster interface and logs in. • The admin adds the device containing the backup if a re-install was performed. • The admin navigates to Restore -> Restore Wizard to initiate the restore. • Admin selects a backup device and clicks Next • Admin selects the backup by date and time and clicks Next • Admin selects components to be restored and clicks Next • Admin clicks Restore to initiate the restore of the selected components. • After restore completes the admin reboots the server
Cluster Restore from Backup To restore a Unity Connection cluster from a backup without re-installing do the following. • Restore one of the servers in the cluster from the desired backup. • Reboot the restored server. • After the restored server reboots and all services have started, log into the CLI on server that was not restored and run the CLI command “utils cuc cluster overwritedb” to overwrite all its data with the data from the restored server.
Online Cluster Server Replacement,Subscriber Server Replacement Note: DRS is not used for this method, but it is recommended that a backup is taken before re-installing a server. To replace a CUC Active/Active pair without an outage you can replace one server at a time. To replace a CUC subscriber server while CUC publisher continues to operate: • Gather information such as hostname, DNS suffix, network configuration, and installed locales then Shutdown the existing subscriber server. • Install the new server using the same software version as running on the publisher server. If the publisher is running an ES version, the ES can be applied as part of the install. • When installing the new subscriber the hostname, network configuration, and security password must be the same as before. • Data will be automatically synced from the existing publisher during installation. • Re-install any previously installed locales and needed licenses.
Online Cluster Server Replacement,Publisher Server Replacement Note: DRS is not used for this method, but it is recommended that a backup is taken before re-installing a server. To replace a CUC publisher server while the CUC subscriber continues to operate: • Gather information such as hostname, DNS suffix, network configuration, and installed locales then shutdown the existing publisher. • Install the new publisher server as a standard first node using the same software version as that running on the subscriber. • When installing the new publisher the hostname, network configuration, and security password must be the same as before replacement. • Once installation has completed log into the CUC System Administration interface, navigate to the Cluster configuration page and add the existing subscriber’s hostname. • Log into the admin CLI on the existing subscriber server and run the CLI command “utils cuc cluster renegotiate” to establish cluster relationship and push current data to the new publisher. • After successful renegotiation the publisher is automatically rebooted. • Re-install any previously installed locales and needed licenses.
Successful Renegotiation Command Output Example admin:utils cuc cluster renegotiate First node: cuc-install-70 Second node: cuc-install-71 WARNING: This operation will negotiate a trust relationship with the publisher node cuc-install-70, and overwrite all data and messages on that node with data from this node. Run this command only if you are replacing a disabled publisher node. This command may take require several hours to complete. The duration depends on the network bandwidth between nodes and on the total size of the data on this subscriber node. Are you sure you want to continue? (y/n) : y 08/07/28 14:05:03 Disabling data replication... 08/07/28 14:05:03 Renegotiating ssh trusts... 08/07/28 14:05:05 Synchronizing platform and LDAP database... 08/07/28 14:07:11 Creating any missing messaging databases on the publisher... 08/07/28 14:10:09 Adding subscriber node to publisher... 08/07/28 14:10:13 Synchronizing Unity Connection databases... 08/07/28 14:14:59 Synchronizing file systems... 08/07/28 14:15:00 Synchronizing message files for mail store UnityMbxDb1... 08/07/28 14:15:02 Synchronizing message files for mail store UnityMbxDb2... 08/07/28 14:15:03 Synchronizing message files for mail store UnityMbxDb3... 08/07/28 14:15:04 Synchronizing message files for mail store UnityMbxDb4... 08/07/28 14:15:05 Synchronizing message files for mail store UnityMbxDb5... 08/07/28 14:15:06 Rebooting publisher node cuc-install-70... 08/07/28 14:15:06 Cluster renegotiation completed. Process completed. admin:
Offline Cluster Server Replacement • If a DRS backup has not been taken, take a DRS backup of all components on the publisher server. • Gather information such as hostname, DNS suffix, network configuration, and installed locales from the publisher and subscriber servers. • Install the new publisher server as a standard first node using the same software version as that running on the subscriber. • When installing the new publisher the hostname, network configuration, and security password must be the same as before replacement. • Once installation has completed log into the Disaster Recovery System interface and perform a restore of all components as described earlier in the “Restoring from a Backup.” • After the new publisher is rebooted log into the CUC System Administration interface and navigate to the “Cluster” configuration page and make sure the subscriber hostname is already defined. • Install the new subscriber server, it will sync with publisher server during installation.