Database is one of the key elements in the IT infrastructure and the same is to be protected and need to be restored during the occasion of an unprecedented incident like natural calamities, hard disk failure, database corruption…etc
Cisco Unified Communications Application provides a Disaster Recovery System (DRS) to back up and restore the database, be it the configuration or statistics related to the application.
Cisco Unified Communications Manager (CUCM) backs up - call details records (CDR), call management records (CMR), the CDR Analysis and Reporting (CAR) database...etc
Cisco Unity Connection (CUC) backs up - Recorded greetings and voice names, Connection Database, Messages...etc
Cisco Unified Presence Server (CUPS) backs up - Presence database, XMPP Configuration Files (XCP), Cluster Manager and other files
Disaster Recovery System
The Disaster Recovery System allows you to perform regularly scheduled - automatic or user-invoked data backups.
DRS restore its own settings (backup and schedule setting) as part of the platform backup/restore- DRS backup and restore drfDevice.xml and drfSchedule.xml files.
When the server is restored with these files, you do NOT need to reconfigure DRS backup device and schedule.
How to Login to the DRS page in UC Applications ???
In CUCM Administration page, choose Disaster Recovery System from the Navigation menu in the upper, right corner of the Cisco Unified Communications Manager Administration window, and click Go.
In CUC Administration page, in the Navigation list, click Disaster Recovery System , and click Go
In CUPS Administration page, Select Navigation > Disaster Recovery System from the menu in the upper, right corner of Cisco Unified Presence main window, and click Go
DRF Master and DRF Local :
The Disaster Recovery System contains two key functions, Master Agent (MA) and Local Agent (LA).
MA coordinates backup and restore activity with LA.
The system automatically starts the MA service on each node of the cluster, but MA is functional only on the First node. The MA on the subsequent nodes DO NOT perform any function.
LA is the one who perform backup and restore functions.
ALL the servers in the cluster including the server that contains the MA, must have its own LA to perform backup and restore functions for the server.
// TROUBLESHOOTING //
DRS use an SSL-based communication between the MA and the LA for authentication and encryption of data between the publisher and subscriber servers.
DRS make use of the IPSec certificates for its Public/Private Key encryption.
Configuring and Adding Backup Devices::
We must create backup devices on which to back up data and configure the locations where you want the backup files to be stored. We can configure up to 10 backup devices.
Make sure that you have access to an SFTP server to configure a network storage location.
The Disaster Recovery System only supports SFTP servers that are configured with an IPv4 address or hostname/Fully Qualified Domain Name (FQDN).
The account that you use to access the SFTP server must have write permission for the selected path.
Select Backup > Backup Device
// TROUBLESHOOTING //
++ You cannot delete a backup device if you configured it as the backup device in a backup schedule
Creating a Schedule for Backup ::
You have the option to name/add/edit a schedule for backing up your data .Here you associate a backup device added earlier , select components to backup and set the frequency of the backup schedule (daily, weekly, monthly..etc)
Select Backup > Scheduler
++ Manual Backup can be performed from here:: Backup > Manual Backup
++ Current status of the backup can be checked from here :: Backup > Current Status
// TROUBLESHOOTING //
Backup .tar files are encrypted by a randomly generated password. Server uses the cluster security password to encrypt this password and save it along with the backup .tar files.
If you change this security password through the Command Line Interface or a fresh install, the Disaster Recovery System will prompt you for the old security password. Therefore, to use old backups, you need to remember the old security password or perform a fresh backup immediately after you reset or change the password.
Cisco recommends to schedule backups during off-peak hours to avoid processing interruptions and impact to service
Restoring the backup::
Here you can restore the data that had already been backed up and restore your cluster/node.
STEP 1 :: Select the backup device from which to restore the data
STEP 2 :: Select the backup file that you want to restore.
++ The backup filename indicates the date and time that the system created the backup file.
STEP 3 :: Select the features that you want to restore.
++ Only the features that were backed up to the file that you select display.
STEP 4 :: Check Perform file integrity check using SHA1 Message Digest to run a File Integrity Check.
STEP 5 :: When you are prompted to choose the node to restore, choose the appropriate node
Select Restore > Restore Wizard
// TROUBLESHOOTING //
Restoring the first node restores the whole database to the cluster. This may take up to several hours based on number of nodes and size of database that you are restoring.
If you choose the first node to restore the data, the Disaster Recovery System automatically restores database on the subsequent nodes.
If a subsequent node is down or not connected to the cluster during the cluster restore, the database component restore will skip that node and proceed with the next one. You must carry out a fresh install of the instance on these subsequent nodes.
Even if you are restoring only to the first node, you must restart all nodes in the cluster.Cisco recommends that you restart the subsequent nodes before you restart the first node.
If you selected the Perform file integrity check using SHA1 Message Digest check box, the Disaster Recovery System runs the File Integrity Check on each file when you select Restore.
If the system finds discrepancies in any .tar file during the check, it aborts the restore process immediately.
File Integrity Check process consumes a lot of CPU and network bandwidth, which will considerably slow down the restore process
The Disaster Recovery System does not migrate data from Windows to Linux or from Linux to Linux. A restore must run on the same product version as the backup.
Last, But not the least - Traces
Trace files for the Master Agent and each Local Agent will be printed to the following locations:
For the Master Agent, platform/drf/trace/drfMA0* // DRF MASTER AGENT LOGS //
For each Local Agent, platform/drf/trace/drfLA0* // DRF LOCAL AGENT LOGS //
++ You can collect the same traces from RTMT as well specifying the time stamp and a local download location
Hello, I am a final user who´s traying to find out some source of knowledge for some issues I am facing with my new Cisco 8845 3PCC connected to an Issabel PBX/Asterisk. I am coming from a “yeahlink” user experience, so It´s been quite a change in ab...
Hello, I have about 15 remote sites and 2 data centers. The data-centers both have CUBES that connect to the PSTN via provider SIP trunks. Each remote site also has an SRST. I have always assigned MTP via the MRG list for each site ...
Hi Peeps, I'm running a 12.0 cluster, and using solarwinds to monitor it. We constantly get "alerts" for phone registration rejected. I've argued with management to disable this useless alert, but they believe it to be valid. So I'm...
Hi,My question today is for the different version of roomkits, room kit pro, room kit plus and MX700. Each of these have dual monitors. These devices are all registered to webex portal hub. Currently during a webex, the first monitor dis...