cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5350
Views
35
Helpful
4
Comments
Vimal K V
Cisco Employee
Cisco Employee

Why Disaster Recovery System ?

 

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.

 

For Example,

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

 

 

 

Comments
Aman Soi
VIP Alumni
VIP Alumni

Excellent DOC[+5]

 

regds,

aman

Mohammed Khan
Cisco Employee
Cisco Employee

 +5

Regards,

Mohammed Noor
 

Vimal K V
Cisco Employee
Cisco Employee

Hi Aman,

 

Thank you...

 

Regards, VKV

Vimal K V
Cisco Employee
Cisco Employee

Hi Noor,

 

Thank you...

 

Regards, VKV

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: