Remote Data Replicator (RDR) V6.1 User Guide

Remote Data Replicator (RDR)
Version 6.1
User Guide
Remote Data Replicator User Guide
V6.1
Catalog No: X92075
Drawing No: 432006-2442-063-A00
May 2016
1st Edition
ECI's NPT-1200, NPT-1020, and NPT-1010 are CE2.0 certified.
NPT-1600 complies with the MEF9 and MEF14 standards.
The qualification lab is accredited by A2LA for competence in electrical testing according to
the International Standard ISO IEC 17025-2005 General Requirements for the Competence of
Testing and Calibration Laboratories.
Remote Data Replicator's management applications run on VMWare virtualization

hypervisors.
© Copyright, 2002-2016. All rights reserved worldwide.

This is a legal agreement between you, the end user, the seller, and the respective vendors.
BY OPENING THE DOCUMENTATION AND/OR DISK PACKAGE, YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS AGREEMENT. IF YOU DO
NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE UNOPENED DOCUMENTATION AND/OR DISK PACKAGE AND THE
ACCOMPANYING ITEMS (INCLUDING WRITTEN MATERIALS AND BINDERS OR OTHER CONTAINERS) TO THE PLACE FROM WHICH YOU OBTAINED
THEM.
All documentation and/or disk and all information and/or data contained in the documentation and/or disk is proprietary [the Proprietary],
respectively, of the seller and/or of the respective vendor/s and/or other third party [hereunder individually and/or collectively the Seller] and is
subject to all relevant copyright, patent, and other laws and any international treaty provisions, protecting intellectual property, as well as any
specific agreement protecting the Seller's rights in the aforesaid information. Any use of the Proprietary contained therein for any purposes
[included but not limited: published, reproduced, or disclosed to third parties, in whole or in part] other than those for which it was disclosed,
without the express prior written permission of the relevant Seller, is strictly forbidden.
The Proprietary is provided AS IS and may contain flaws, omissions, or typesetting errors. No responsibility and/or liability whatsoever are assumed
by the Seller for you or any other party for the use thereof, nor for the rights of third parties, nor for any loss or damage whatsoever or howsoever
caused, arising directly or indirectly in connection with the Proprietary which may be affected in any way by the use and/or dissemination thereof.
The Seller reserves the right, without prior notice or liability, to make changes in equipment design or specifications.
Any representation(s) in the Proprietary concerning performance of the Seller product(s) are for informational purposes only and are not warranties
of product performance or otherwise, either express or implied. No warranty is granted nor liability assumed in relation thereto, unless specifically
undertaken in the Seller sales contract or order confirmation. The Proprietary is periodically updated, and changes will be incorporated in
subsequent editions. All graphics included in this document are for illustrative purposes only and might not correspond with your specific product
version.
Other Restrictions. You may not rent, lease, sell, or otherwise dispose of the Proprietary, as applicable.
YOU MAY NOT USE, COPY, MODIFY, OR TRANSFER THE PROPRIETARY OR ANY COPY IN WHOLE OR PART, EXCEPT AS EXPRESSLY PROVIDED IN THIS
LICENSE. ALL RIGHTS NOT EXPRESSLY GRANTED ARE, RESPECTIVELY, RESERVED BY THE Seller.
All trademarks mentioned herein are the property of their respective holders.
Notwithstanding the generality of the aforementioned, you expressly waive any claim and/or demand regarding liability for indirect, special,
incidental, or consequential loss or damage which may arise in respect of the Proprietary contained therein, howsoever caused, even if advised of
the possibility of such damages.
The end user hereby undertakes and acknowledges that they read the "Before You Start/Safety Guidelines" instructions (when provided by the
Company) and that such instructions were understood by them. The Seller shall not be liable to you or to any other party for any loss or damage
whatsoever or howsoever caused, arising directly or indirectly in connection with you fulfilling and/or failing to fulfill in whole or in part the "Before
You Start/Safety Guidelines" instructions.
Contents
Useful Information .................................................................................................vi
Related documents ............................................................................................................................... vi
Contact information .............................................................................................................................. vi
1 About RDR................................................................................................... 1-1

1.1 Functional Description ........................................................................................................... 1-1
1.1.1 Components ............................................................................................................................ 1-1
1.1.2 Instances ................................................................................................................................. 1-3
1.1.3 Replicas ................................................................................................................................... 1-4
1.2 Typical RDR Configurations .................................................................................................... 1-5
1.2.1 Backup Deployment ................................................................................................................ 1-5
1.2.2 Primary and Mirror Configurations ......................................................................................... 1-6
1.2.3 EMS Instance Configurations .................................................................................................. 1-9
1.2.4 LightSOFT Instance Configurations.......................................................................................... 1-9
1.3 Activation Overview ............................................................................................................... 1-9
1.3.1 Backup Session ........................................................................................................................ 1-9
1.3.2 Recovery from Backup to Mirror ........................................................................................... 1-10
1.3.3 Reverse Update to the Primary Site ...................................................................................... 1-11
1.3.4 Alarms Notification ............................................................................................................... 1-11
1.3.5 RDR Activity Monitor ............................................................................................................. 1-11
2 Preliminary Requirements and Installation.................................................. 2-1

2.1 Application Requirements ..................................................................................................... 2-1
2.1.1 Preliminary Requirements....................................................................................................... 2-2
2.1.2 Preconfigured Values .............................................................................................................. 2-2
2.1.3 Minimum Backup Server Disk Capacity ................................................................................... 2-2
2.2 Installation ............................................................................................................................. 2-3
3 RDR Menus ................................................................................................. 3-1

3.1 RDR Instances List .................................................................................................................. 3-1
3.2 RDR Common Actions Menu.................................................................................................. 3-2
3.3 RDR Instance Actions Menu ................................................................................................... 3-3
3.4 RDR Instance Configuration Options Menu ........................................................................... 3-4
3.5 Advance RDR Configuration Options Menu........................................................................... 3-5
ECI Telecom Ltd. Proprietary iii

Remote Data Replicator (RDR) User Guide Contents
4 RDR Configuration ....................................................................................... 4-1

4.1 Configuration Workflow ........................................................................................................ 4-1
4.2 Starting the RDR..................................................................................................................... 4-2
4.3 Selecting the Command Center Mode................................................................................... 4-2
4.4 Backup Server Configuration ................................................................................................. 4-3
4.4.1 Instance Discovery .................................................................................................................. 4-3
4.4.2 Instance Configuration ............................................................................................................ 4-6
4.4.3 Removing all Instances Associated with a Primary Component ........................................... 4-17
4.4.4 Resetting Primary Host SSH Keys .......................................................................................... 4-18
4.5 Defining an Alternate Primary Cache Location .................................................................... 4-19
4.6 Mirror Component Configuration ........................................................................................ 4-23
4.6.1 Disabling Application Auto Start ........................................................................................... 4-23
4.6.2 Restoring Large Mirror Component DB with Alternate Cache Location ............................... 4-23
5 Creating and Scheduling Backups ................................................................ 5-1

5.1 Activating an Unscheduled Backup........................................................................................ 5-1
5.2 Activating an Unscheduled Archive Backup .......................................................................... 5-2
5.3 Scheduling Backups................................................................................................................ 5-3
5.3.1 Backup Schedules .................................................................................................................... 5-5
5.4 Viewing Crontab Entries ........................................................................................................ 5-7
5.5 Backup Log Files ..................................................................................................................... 5-8
6 Restoring from a Backup ............................................................................. 6-1

6.1 Restoring to the Mirror or Primary Component .................................................................... 6-1
6.1.1 Recovery to a Mirror Component ........................................................................................... 6-1
6.2 Starting a Mirror or Primary Recovery Session ...................................................................... 6-2
6.3 Setting the Mirror Component .............................................................................................. 6-5
6.4 Performing Direct Recovery ................................................................................................... 6-8
6.5 Recovery Log Files ................................................................................................................ 6-10
7 Restarting the Primary Instance after Recovery ........................................... 7-1

7.1 Performing Reverse Update .................................................................................................. 7-1
7.2 Recognizing the Primary Component .................................................................................... 7-3
ECI Telecom Ltd. Proprietary iv

Remote Data Replicator (RDR) User Guide Contents
8 Suspending or Resuming RDR Operation ..................................................... 8-1
9 RDR Command Center Diag Mode ............................................................... 9-1
10 RDR from SPARC to x86 ............................................................................. 10-1
11 RDR from x86 to SPARC ............................................................................. 11-1
12 RDR Commands ......................................................................................... 12-1

12.1 SyncMaster .......................................................................................................................... 12-1
12.2 ReverseUpdate..................................................................................................................... 12-1
12.3 RestartMirror ....................................................................................................................... 12-2
13 Alarm Notification Lists ............................................................................. 13-1
14 Glossary .................................................................................................... 14-1
ECI Telecom Ltd. Proprietary v

Useful Information
This guide describes the requirements for successful installation, configuration, and activation of the
Remote Data Replicator.
NOTE: ems, enm, nms, obi, and stms are used to identify RDR instances. EMS-MPT, EMS-XDM,
EMS-SYNCOM, LightSOFT, LightINSIGHT, and STMS are used to identify the corresponding
applications. For more information see Instances.
A configuration of an instance on a specific component is referred to as a component instance.
Related documents
 EMS-MPT User Guide
 EMS-XDM User Guide
 EMS-SYNCOM User Guide
 LightSOFT Documentation Suite
 LightINSIGHT Documentation Suite
 STMS User Guide
Contact information
Telephone Email
ECI Documentation Group +972-3-9268145 techdoc.feedback@ecitele.com
ECI Customer Support +972-3-9266000 on.support@ecitele.com
ECI Telecom Ltd. Proprietary vi

1 About RDR
The Remote Data Replicator (RDR) application provides redundancy features for the network management
of ECI's EMS-MPT®, EMS-XDM®, EMS-SYNCOM™, LightSOFT®, LightINSIGHT™, and STMS server station
databases, on the same or different stations.
RDR is flexible and can be configured in a wide variety of topologies. It provides optimal protection
consistent with geographic infrastructure distribution, security needs, and available budget for standby
mirror hardware.
RDR can be used as a solution for:
 Data protection only (regular backup, no redundancy)
 Disk protection (no redundant hosts but spare disks are used)
 Host protection (primary and mirror sites are connected via LAN)
 Site protection (primary and mirror sites are connected via a long distance link)
1.1 Functional Description

RDR performs remote data backup (replication) between primary stations (stations currently managing the
network) and the backup server (the station storing backup data). The backup data can subsequently be
restored (synchronized) on a mirror station (remote redundant station replacing failed or deactivated
primary components).
1.1.1 Components
RDR components provide the infrastructure for RDR backup and synchronization functionality on servers.
There are three types of components:
 Primary: Contains one or more of the management applications that the RDR backs up.
 Backup: Administers the storage of backups (replicas) on backup stations.
 Mirror: Restores application databases from the backup station to a mirror station, enabling the
network to be managed from the mirror station in the event of a primary station failure.
 Shadow: Restores the Backup server
NOTE: The backup and mirror can share the same station.
RDR components are referred to as belonging to sites – primary components to a primary site, mirror
components to a mirror site, and the backup component (when not sharing a mirror component's station)
to a backup site.
ECI Telecom Ltd. Proprietary 1-1

Remote Data Replicator (RDR) User Guide About RDR
1.1.1.1 Primary Components

The primary site can contain a number of primary components, each residing on a station and each
maintaining any combination of instances (see Instances). Each primary component may be in a Single-Zone
(Legacy) or Multi-Zone configuration.
RDR manages an independent backup session for every primary component instance according to its own
preset configuration. Each instance can be replicated on a different backup server.
The number of supported primary components and instances is limited only by the overall backup server
storage capacity - see Minimum Backup Server Disk Capacity.
A primary site contains one or more of the following management applications:
 Single LightSOFT server
 LightSOFT server main component (part of a cluster configuration)
 LightINSIGHT
 EMS (EMS-MPT, EMS-XDM, or EMS-SYNCOM)
 STMS
1.1.1.2 Backup Components

The backup component resides either on a dedicated station or shares a station with one of the mirror
components. The backup server performs the following actions:
 Initiates and manages regular and archive backup sessions
 Stores RDR instances backup data sets (replicas)
 Manages shadow backups
RDR also supports multiple backup components, allowing each instance to be configured to use different
RDR backup servers.
Each regular backup transfers files to a replica on the backup server. The backup server stores a
(configurable) number of last successful replicas. The number of stored replicas per instance is configurable
(see Replicas), and only limited by available disk capacity (see Minimum Backup Server Disk Capacity).
The Backup Server usually invokes backup sessions according to a predefined schedule using the UNIX Cron
utility.

1.1.1.3 Mirror Components

Mirror components are sets of redundant hosts used to restore and run instances in the event of primary
component failure. Mirror components are generally assigned their own servers. (Depending on user
requirements, the backup component may share a server with a mirror component.)
Mirror components are normally in standby mode, meaning instances installed on the component are not
active but ready for a command to launch the recovery process. The operator can start a mirror station
from any backed-up replica.
The system topology may include one or several mirror components, according to the required
redundancy. When primary stations are geographically separated with negligible chance of simultaneous
failure, multiple primary components may be safely and economically serviced by a single mirror
component (N:1 configuration). In more sensitive environments, multiple mirror components can provide
additional assurance. For example, each primary server can be paired with its own mirror component (1:1
configuration). For more information, see Primary and Mirror Configurations.
1.1.2 Instances
An RDR instance is an occurrence of a supported application that is running on the primary component
(such as EMS-SYNCOM, EMS-MPT, LightSOFT, LightINSIGHT, or STMS in any combination).
RDR instances are not the actual applications, but the data relating to the applications that need to be
backed up (for example, the database and configuration).
Each instance is identified by its own unique name. The instance name has the following structure:
tag@hostname[:zone_prefix]
 tag: Identifies the application:
 nms: LightSOFT Server application
 ems: EMS-MPT or EMS-XDM application.
 stms: STMS application
 obi: LightINSIGHT OBIEE application
 enm: EMS-SYNCOM application
 hostname: The host name (primary or mirror components) where the instance is located.
 zone_prefix: The zone identifier for Multi-Zone configurations. It is the first part of the standard
zone name in ECI installations (zn).
In the case of a Single-Zone (Legacy) configuration, the zone_prefix is omitted.
EXAMPLE: The RDR instance name for EMS-MPT on host foo in zone
z3-foo is: ems@foo:z3.
NOTE: Dots (".") cannot be used in zone names.

Dashes ("-") cannot be used in host names.

The RDR modular structure provides separate backup/recovery mechanisms for each supported instance.
Each instance on each component can be configured according to user requirements, for example, to have
different backup schedules or a different number of backups per cycle.
NOTE: When the LightSOFT server involves a cluster configuration (main server and one or
more plain servers), only the main server that contains the database is installed with RDR and
is relevant for backup purposes.
1.1.3 Replicas
RDR replicas are backup data sets of primary component instances (databases). The replicas are stored in a
special folder on the backup server for each primary component instance in a user-configurable path.
Two to five full regular replicas can be configured for each primary component instance (ems, enm, nms,
obi, or stms), with the newest backup overwriting the currently oldest backup on a cyclical basis.
An archive replica, which is not automatically overwritten, can also be created for each primary component
instance. An archive replica is a static backup from a specific time used to freeze the system state on the
backup server.
Recovery can be performed based on either any cyclical replica or the archive replica.
The number of replicas that can be stored is only limited by the available disk capacity (see Minimum
Backup Server Disk Capacit y).
For each primary component instance, backups can be scheduled to be performed automatically at
constant intervals (set time span between backups) or non-constant intervals (specific time on selected
days of the week or month).
Replicas at constant intervals can be set to occur at very short intervals, as frequently as every 10 minutes,
according to user requirements. (The selected interval cannot be shorter than the time it takes to create a
backup.)
To simplify recovery, it is recommended to schedule all primary component instances with the same
backup intervals. Offsets can be used to stagger individual starting times (setting them a number of minutes
apart), to balance the load and avoid network congestion.

1.2 Typical RDR Configurations

The following sections describe a few of the possible RDR configurations. RDR flexibly enables a wide
variety of topologies according to the required protection level, geographic distribution of infrastructure,
and equipment budget.
1.2.1 Backup Deployment

Any number of backup components may be deployed, either on their own dedicated servers or sharing
servers with mirror components.
The backup component can be installed in the following ways:
 On the same server station as a mirror component. The shared station is installed with the operating
system and infrastructure of a regular network management station, as well as the RDR application.
OR
 On a dedicated backup server. The server is configured with only two partitions – one of 2 GB for the
operating system and RDR, and the remaining large partition available for backup data. Management
application databases are not installed on this server.
In a 1:N implementation, the mirror site hardware must be at least as large as the largest primary site.
1.2.1.1 Shadow Backup Server

A shadow backup maintains a copy of the replicas contained in the RDR backup server. Its purpose is to
grant a higher redundancy to the RDR backup system. One shadow backup server can support multiple
backup servers. Alternatively, one backup server can save different instances on different shadow servers.
When the shadow backup is configured for the instance, immediately upon the successful end of the
backup session the backup server performs an additional replication of the instance replica to the assigned
shadow server.
A shadow backup is configured per RDR instance; therefore you can assign a separate shadow server for
each instance.
NOTE: The replica of the instance on the shadow server is automatically located in the same
location as on the backup server. This allows the recovery session to also restore the instance
from the shadow server.

1.2.2 Primary and Mirror Configurations

Primary and mirror components can be matched according to the required protection level and equipment
budget. The mirror site can provide redundancy for any number or combination of primary components.
The notation N:N denotes the number of primary components to mirror components. For example, 1:1
denotes one primary component serviced by one mirror component, and N:1 denotes multiple primary
components serviced by one mirror component.
Regardless of the primary to mirror configuration, any number of backup components may be deployed,
either on their own servers or sharing a server with a mirror component.
In all cases, links must be provided from the backup/mirror components to all other integrated
components.
1.2.2.1 1:1 Configuration

The following figure shows a 1:1 configuration with a dedicated mirror host for each primary host.
Figure 1-1: Simple configuration example – 1:1
In this example, the backup and mirror components share a common host.

1.2.2.2 2:2 Configuration

The following shows a 2:2 configuration where two primary components are serviced by two mirror
components. For example, primary host 1 may run LightSOFT, while primary host 2 may run EMS-MPT or
EMS-XDM as a slave manager.
Figure 1-2: Simple configuration example – 2:2
NOTE: If required, the primary component 2 application can be recovered on the mirror
component 1, thereby "merging" the two applications on mirror component 1.
In this example, the backup component and one mirror component share a common host, while the second
mirror component resides on its own host.

1.2.2.3 N:2 Configuration

The following figure shows an N:2 configuration where N primary components are serviced by two mirror
components, saving on mirror hardware.
The mirror site can provide redundancy for any number or combination of primary components. An
individual mirror component can restore multiple primary component instances, only limited by its power,
memory, and disk capacity.
Figure 1-3: RDR complex configuration – N:2 with independent backup server
In this example, the backup server is deployed on a dedicated host. It should have adequate disk space for
the large number of replicas from all the primary components.

1.2.3 EMS Instance Configurations

The primary and backup/mirror EMS sites will usually each have their own set of gateway NEs (which may
be shared by both sites), although this is not required.
Clients/proxy clients may be connected to both the primary and backup/mirror sites so that users can
switch from one to the other, enabling seamless network management.
1.2.4 LightSOFT Instance Configurations

When a LightSOFT server is installed in one workstation, a simple 1:1 backup configuration is supported for
the main server only.
For larger networks, where the LightSOFT server is distributed amongst several workstations, the following
two schemes are supported:
 1:N at the workstation level – a single additional workstation may be deployed to act as backup for
any server station. This approach is hardware efficient but cannot support full site redundancy.
 1:1 at the LightSOFT server level – full hardware duplication is required. For example, for four server
machines, four additional machines are required.
Some networks may have several LightSOFT installations. In that case, a 1:N LightSOFT backup scheme may
be suitable. The backup site should include as many workstations (LightSOFT server + EMSs) as the largest
LightSOFT site being backed up.
LightSOFT client users may switch from one LightSOFT server site to another, enabling seamless network
management.
1.3 Activation Overview

These sections describe how to activate the RDR server.
1.3.1 Backup Session

The RDR backup session is performed in several steps:
1. The backup server checks connectivity with the primary component.
2. The backup server initiates backup of the primary instance to the local cache on the primary
component.
3. The primary component performs a data integrity check in the local cache.
4. The backup server replicates the data from the local cache to the backup folder on the backup server.
NOTE: A local cache is used to eliminate a communication link bottleneck. The local cache
location is configurable for every instance on the primary component, so that the RDR can use
available disk space in the most efficient way.

The RDR can be set to automatically invoke backup sessions at prescheduled times. These regular replicas
are stored cyclically on the backup component with the oldest replica deleted first. The amount of replicas
saved on the backup component is configured during instance configuration. Archive backups, which are
replicas that are not overwritten, can also be configured for each instance.
The general replication scheme is shown in the following figure.
Figure 1-4: General replication scheme
1.3.2 Recovery from Backup to Mirror

When a primary site fails, its mirror site is manually activated and instructed from which replica on the
backup component to recover. After completing database synchronization, work carries on as usual.
The recovery process involves the following steps:
1. Define the backup server from which to restore.
2. Check backup server connectivity.
3. Set the mirror instance from which to restore.
4. Choose the primary instance to restore.
5. Choose the primary instance replica to restore.
6. Perform the mirror instance restore action from the replica chosen.
7. Set the mirror component with required parameters from the primary component, and set other
servers to recognize and communicate with the mirror component in place of the failed primary
component.
8. Start the application on the mirror component.
For further information, see Starting a Mirror or Primary Recovery Session.

1.3.3 Reverse Update to the Primary Site

Once the primary site is back in working condition, the user can return to the normal working configuration.
(This should be done as soon as possible in order to have the mirror component available to handle any
other potential failure.)
NOTE: During reverse update, the applications on both the primary and mirror components
must be shut down.
This process involves the following main steps:

1. Perform the reverse update procedure to load the primary component with all changes made to the
system during the mirror component activation period while the primary component was down.
2. Set other servers to recognize and communicate with the primary component that has been returned
to duty in place of the mirror component, and allow work to resume as usual.
3. Set the mirror site to standby mode.
1.3.4 Alarms Notification

All backup failures generate an error message that is sent by an xmessage utility to the predefined hosts. By
default, these messages appear on the primary component console and the RDR Backup Server console.
You can also create a list of hosts that also receive these messages. These hosts must run X Server to be
able to display the messages.
There are two types of configurations:
 Private list: A list of hosts to receive the error messages for a specific RDR instance. The list is located
in the file:
/opt/RDR/config/backup/RDR.displays.<instance_name>
 Common list: A list of hosts to receive the messages for all RDR instances. The list is located in the file:
/opt/RDR/config/backup/RDR.displays
For more information about how to configure the host lists, see Alarms Configuration.
1.3.5 RDR Activity Monitor

The RDR Activity Monitor allows you to monitor the RDR backup activity.
An example of an RDR Monitor window is shown in the following figure.
Figure 1-5: RDR Monitor example
The Activity Monitor window displays the following information:

 Instance name
 Instance backup status idle (green) or backup (red)
 Resources consumption (Memory and CPU in %)
NOTE: The Activity Monitor is only displayed on the backup server.
To access the Activity Monitor window:

 From the root menu, select RDR > RDR (global) > Monitor RDR Backup.
The Activity Monitor window appears.

2 Preliminary Requirements and
Installation
This section describes the preconditions for successful installation. It also provides an overview of the
workflow for component configuration detailed in subsequent sections.
The RDR package is installed on your system components by ECI personnel. RDR must be installed on every
station of the system – primary, backup, and mirror. When backup and mirror components are combined
on one station, a single RDR installation is required for that station.
NOTE: The RDR package must be installed in the global zone of the Oracle server along with
the EMS, OBI, and STMS.
2.1 Application Requirements

The following products, versions, and configurations are supported:
 LightSOFT V8.1, V9
 LightINSIGHT 2.x
 EMS-MPT V1.2, V2.1
 EMS-XDM V7.2.2, V8.1, V8.12, V8.2, V8.3
 STMS V11.3, V11.4, V12.2, V12.3, V12.4, V4.1
 EMS-SYNCOM V2
Products without SSH (Secure Shell) protocol are not supported.
These products are supported by SPARC or Intel x86 server types, with the following exceptions:
 EMS-XDM:
 Applies to version 8.12 and up only.
 After performing a mirror recovery from SPARC to x86, you must run the EndianDBMigration
script before starting the application on the mirror. This script converts the DB structure from
SPARC to x86. (The same is applicable when performing a reverse update from x86 to SPARC.)
 STMS: if the primary is on a SPARC or x86 CPU, the mirror site should be on a server of the same
architecture.
NOTE: RDR can also be used in networks based on other EMSs such as BroadGate and ATS. In
these cases, the EMSs are not backed up by RDR but rather deployed in parallel in both the
primary and backup sites.

Remote Data Replicator (RDR) User Guide Preliminary Requirements and Installation
NOTE: When upgrading NMS from v7 to v8.1, or v9 do the following:

1. Perform RDR nms instance 'Unconfigure', including removal of old backups (which are
not applicable in v8.1 or higher).
2. Configure the NMS instance.
2.1.1 Preliminary Requirements

RDR has the following requirements:
 Backup Server:
 OS Solaris 10, Solaris 11
 Min. RAM 512 MB
 Min. disk capacity 73 GB (min. required disk size derived from the backup as calculated in the
formula in Minimum Backup Server Disk Capacity).
 Communications and Bandwidth:
 Appropriate network communication configurations on all components (primary, backup server,
and mirror) enabling valid network routing between sites. It is important to calculate the time it
will take to transfer a large database over the provided network bandwidth and/or storage
device IO rate. Be sure to take into consideration possible simultaneous overlapping backups of
a few instances at the same time. In extreme cases 10 Mb is not sufficient.
 10 Mbps minimum link bandwidth between components (assuming replicas are scheduled on a
staggered basis to avoid overlap). Min. network link bandwidth 10 Mbps.
 Mirror Server:
 Hardware configuration to match the requested applications and network.
 Management application versions to be the same as on the primary station.
 All required application license keys to be present on the station before the mirror component
is first activated (preferably before RDR is installed on the station).
2.1.2 Preconfigured Values

 Max. number of replicas per instance is five (can be changed according to customer requirements).
 Number of retries on transfer failure is three (can be changed according to customer requirements).
 Min. synchronization interval is 10 min.
2.1.3 Minimum Backup Server Disk Capacity

The number of replicas that are stored is configurable (see Replicas) and only limited by available disk
capacity.
The following rule-of-thumb formula can assist in estimating the minimum required backup server free disk
size (BDB).
BDB = EPDB1 * (ENR1 +1) + EPDB2 * (ENR2 +1) + . . . + EPDBn * (ENRn +1)

Where:
 BDB - required minimum backup-server disk capacity for backup
 EPDB - actual DB size of each primary EMS instance (NMS/XDM/STMS/SYNCOM).
 ENR - number of replicas of each primary EMS instance (add 1 for the archive)
For EPDB, use the actual instance database sizes or estimate the required capacity as follows:
 For each XDM NE, min. capacity per replica:
 Estimate 50 MB for a backup initiated from EMS-MPT or EMS-XDM.
 Estimate 60 MB for a backup initiated from LightSOFT.
 For each SYNCOM NE, min. capacity per replica:
 Estimate 5 MB for a backup initiated from EMS-SYNCOM or LightSOFT.
Be sure to include sufficient additional capacity for network growth.
NOTE: Due to partition considerations, effective Legacy installation of Solaris 10 /sdh_home

partition size is:
60 GB of 73 GB, 122 GB of 160 GB, and 212 GB of 250 GB.
2.2 Installation
The RDR application must be installed in every server in the global zone.
The RDR application should be installed according to the standard ECI package installation
recommendations.
NOTE: Do not attempt to mix installing a SPARC package on an x86 server or vice versa.
NOTE: SunOS, the OS Version and architecture are optional and appear when necessary.
<architecture> is SPARC or i386.

To install using the install.rdr package:

1. Become "root" and install the necessary packages and optionally necessary fix disks.
2. Start RDR installation using the install.rdr script. Enter:
/cdrom/cdrom0/install.rdr
3. Access the Main Installation Menu [global zone].
4. Enter 1, Install & Upgrade S/W Packages.
5. Enter auto. The selected package is displayed.
6. To proceed, enter y. A message is displayed at the end of the installation.
7. Verify successful packages installation.
NOTE: For an STMS backup, the following items are not maintained in the DB and must be
stored and backed up separately on a Network File System (NFS) server that is mounted under
the root directory of the STMS server:
Historical counters
Software builds
If the NFS server is mounted at the same point in the file system, the standby STMS is able to
access these items.

3 RDR Menus
This section describes some principal menus used by the configuration and activation procedures in this
manual.
3.1 RDR Instances List

You start many RDR tasks from the RDR Instances list. The list displays all the instances, configured and
unconfigured, in the system.
To view a list of instances in the system:

 Do one of the following:
 Start the RDR application.
 From any menu, continue entering q to exit all the menus until the instances are displayed.

Remote Data Replicator (RDR) User Guide RDR Menus
3.2 RDR Common Actions Menu

You perform basic RDR tasks, such as scheduling backup sessions, from the Common Actions menu.
To view the Common Actions Menu:

 From the RDR Instances list (see RDR Instances List), enter r.
The RDR Common Actions Menu appears.
Table 3-1: Common Actions Menu options
Option Explanation Relevant section in this

manual
Discover RDR Instances of Discover instances manually or automatically. Instance Discovery
Primary Components
Special RDR Backup Server Display the RDR Backup Server Special Removing all Instances
Configuration Actions Configuration Options menu which enables Associated with a Primary
you to remove all instances associated with a and Resetting Primary Host
primary or reset primary host SSH keys. SSH Keys
Set Global Alarm Notification Configure alarms for all instances. Alarms Configuration
Options
Schedule RDR Backup Schedule a backup session. Scheduling Backups
Sessions
Select Command Center To change the mode of the action menus, to Selecting the Command
Mode backup, primary, or mirror. Center Mode
Suspend/Resume All Backups Suspend/Resume all scheduled backups. Suspending or Resuming
RDR Operation
Turn On RDR Command Activate diag mode which creates a log file RDR Command Center Diag
Center Diag Mode with the following information for problem Mode
diagnostics:
System information, such as HostInfo,
menuconf and networking.
All configuration activities.

3.3 RDR Instance Actions Menu

You perform RDR tasks for a selected instance, such as viewing its status or starting an immediate backup,
from the RDR Instance Actions menu.
To view the RDR Instance Actions Menu:

 From the RDR Instances list (see RDR Instances List), select an instance with a configured status.
The RDR Instance Actions Menu appears.
Figure 3-1: RDR Instance Actions Menu
Table 3-2: RDR Instance Actions Menu options
Option Explanation Relevant section in this manual

Show Instance Status Display status details, including instance Viewing Instance Details
identity, current available backup replicas,
backup scheduling, and alarms notification
settings.
Instance Configuration Display configuration options, including RDR Instance Configuration
Menu reconfiguration and advanced settings. Options
Start Regular Backup Start a backup session. Scheduling Backups
Session
Start Archive Backup Start a static archive backup. An archive will Scheduling Backups
Session not be overwritten by the scheduled backups.
Suspend Instance Suspend automatic RDR functionality of this Suspending or Resuming RDR
Backups instance. Operation

3.4 RDR Instance Configuration Options Menu

You can further configure the instances from the RDR Instance Configuration Options menu.
To view the RDR Instance Configuration Options menu:

1. From the RDR Instances list (see RDR Instances List), select an instance with a configured status.
2. Select 2 Instance Configuration Menu.
The RDR Instance Configuration Options menu appears.
Figure 3-2: RDR Instance Configuration Options
Table 3-3: RDR Instance Configuration Options Menu options
Menu option Description Relevant section in this manual

Re-configure Instance Modify the instance configuration. Modifying Instance Configuration
Advanced Configuration Display the advanced configuration Advance RDR Configuration Options
Options options including assigning a shadow Menu
backup server.
Schedule Instance Backups Configure rules for automatic Creating and Scheduling Backups
scheduled backups.
Setup Alarms Notification Configure alarms. Alarms Configuration
Unconfigure Instance Remove all configuration of an Removing the Configuration of an
instance. Instance
Show Current Instance Status Display status details, including Viewing Instance Details
instance identity, current available
backup replicas, backup scheduling,
and alarms notification settings.

3.5 Advance RDR Configuration Options Menu

The advance configuration tasks differ depending on the instance type.
The following table sets out the various options.
Table 3-4: Advance RDR Configuration Options Menu details
Menu option Description Relevant section in this manual

Additional Configuration for Displayed for enm/ems instances. Configuring Directories for ems or
enm/ems Instance type It enables you to define the pattern file enm Instance
configuration.
Assign/Remove Shadow Assign or remove a shadow backup
Backup Server server.

4 RDR Configuration
This section provides an overview of the workflow for configuration components detailed in this and
subsequent sections.
It then describes the configuration process to enable replication of instances (ems, enm, nms, obi, or stms)
of a primary component to a backup component. Each primary component will be in a Multi-Zone
configuration. In addition, this section presents the procedures to configure messages appearing on
specified displays of the system infrastructure.
It is assumed that the system has already been prepared and installed in the relevant stations.
4.1 Configuration Workflow

After installing RDR on all relevant hosts, you need to perform the necessary configuration tasks as
explained in the following sections.
Configuration steps include:
 Ensure that the preliminary requirements for installation are fulfilled. RDR is installed on all relevant
stations by ECI's support staff.
Actions performed in Backup Server station
1. Perform Instance Discovery; see Instance Discovery.
2. Configure Instances; see Instance Configuration.
3. Configure the hosts to receive the alarms; see Alarms Configuration.
4. Configure a shadow backup component if required; see Assigning and Removing a Shadow Backup
Server.
Actions performed in Primary station
 Configure the Primary components if required; see Primary Component Configuration.
Actions performed in Mirror station
 Configure a mirror component; see Mirror Component Configuration. The mirror component
configuration may be postponed until mirror functionality is required.
Testing and kick-start for backups
It is recommended that you perform backups to test the replication process directly after completing the
initial configuration. You do this by performing a manual backup, and scheduling automatic backup sessions
at set intervals. For details, see Activating an Unscheduled Backup and Scheduling Backups.
The Instance Configuration (Step 3 above) processing includes an option to schedule automatic backups for
the instance. If you selected to postpone that action, you should now schedule the backups; see Scheduling
Backups.
NOTE: EMS-MPT/EMS-XDM/STMS/NMS/OBIEE must be configured on Primary and Mirror

components before backup (SyncMaster) and restore (RestartMirror / ReverseUpdate) can
take place.

Remote Data Replicator (RDR) User Guide RDR Configuration
4.2 Starting the RDR

After logging in as root user, you need to start the RDR tool in order to perform the backup related
functionalities available.
To start the RDR:

 Log in as a root user and start the primary RDR component configuration session by entering RDR. The
RDR welcome screen appears.
Figure 4-1: RDR welcome window
4.3 Selecting the Command Center Mode

Different modes in the RDR present different action menus, as follows.
 Backup
 Primary
 Mirror

To change the command center mode:

1. From the RDR Instances list (see RDR Instances List), enter r.
2. From the RDR Common Actions Menu, select 5 Select Command Center Mode.
The Possible RDR Modes of Activity menu appears.
3. Select one of the following options:
 1 RDR Backup Server Actions
 2 Primary Component Actions
 3 Mirror Component Actions
The Actions Menu of the selected option appears.
4.4 Backup Server Configuration

4.4.1 Instance Discovery
Instance discovery is the process of the RDR tool "finding" the instances (ems, enm, nms, obi, or stms)
installed on the primary components.
There are two types of discovery:
 Automatic: RDR presents the instances found in the etc/hosts file.
 Manual: You manually enter the instances.
You should run instance discovery in the following cases:
 During initial RDR configuration.
 After adding a new instance to a primary component.

4.4.1.1 Performing Instance Discovery

This procedure enables the RDR to discover the instances on the primary components.
To perform instance discovery:

1. Log in as a root user.
2. From the CDE root menu, select RDR > RDR (global) > RDR Command Center.
The RDR tool lists the previously discovered instances.
Figure 4-2: RDR Instances
If this is the first time that you are running the RDR, the tool informs you that there are no instances
that have been previously discovered on the Backup Server Component (BSComp).
"No discovered Primary Components data found on BSComp."
The Possible RDR modes of Activity menu is displayed.
Figure 4-3: Possible RDR modes of Activity
3. Do one of the following:

 If there are no discovered instances, enter 1.
 If there are instances but you want to run the discovery again, enter r and then select 1 from
the RDR Common Actions menu.
The RDR Discovery Menu appears with the following options:

 Manual RDR instances discovery: Manually enter the host names to be configured as primary
components.
 Discover RDR instances by hosts DB: The RDR application automatically discovers the primary
components using the /etc/hosts file.
4. To automatically discover the instances from the /etc/hosts file, select 2 Discover RDR instances by
hosts DB. The discovery process begins. When finished, a list of the hosts and the number of found
instances appears.
NOTE: Before continuing with configuration, you must quit and re-enter the RDR application
in order for the updates to take effect.
To manually enter each primary component, do the following:

a. Select 1 Manual RDR instances discovery.
NOTE: Enter the host name, not the IP. The hosts entered must be listed in the etc/hosts file.
If you enter a host that is not listed, you receive an error.
Continue entering host names of other primary components until completed.

After completing all of the host names, enter q. The RDR lists the host names to be discovered.
b. Press ENTER, to begin the discovery process.
The RDR starts the discovery process for the listed hosts, locating all installed instances on each.
When finished, a list of the hosts and the number of found instances appears.

NOTE: Before continuing with configuration, you must quit and re-enter the RDR application
in order for the updates to take effect.
4.4.2 Instance Configuration

After instance discovery, you must configure the instances. Basic configuration consists of the following:
 Defining the backup directory.
 Defining the number of replicas.
Additional configuration includes scheduling the time of the backups and alarms.
4.4.2.1 Configuring Instances
NOTE: Non-standard configuration, such as alternate cache location, should be done on the
primary component.
To configure the instances:

1. From the RDR Instances list (see RDR Instances List), select an instance with an unconfigured status.
A prompt confirming configuration of the instance appears.

2. Enter y.
A prompt requesting the backup directory path appears.
3. Press ENTER to accept the default or enter a new path and press ENTER.
A prompt for the number of regular replicas appears.
4. Enter the number of replicas according to the desired reliability level and existing disk capacity.
For more details, see Replicas.
The defined instance parameters are listed.
5. Select y to accept the parameters.

The instance is configured.

Configuring Directories for ems or enm Instances

In addition to the directory selected to back up in Configuring Instances, additional directories can be
added for an EMS or ENM instance. These directories must be located in the home directory of the
application user. For example /sdh_home/ems for user ems.
NOTE: Only directories can be added to the list, not individual files.
To define additional directories for backing up an ems or ENM instance:

1. From the RDR Instances list (see RDR Instances List), select a configured instance and then select 2
Instance Configuration Menu.
2. Select 2 Advanced Configuration Options. The Advanced RDR Configuration Options menu appears.
3. Select 1 Additional Configuration for enm/ems Instance type.
The Pattern File Configuration menu appears:
4. To view the current pattern file, select 1-Show Current Pattern File. A list appears of the directories
to be backed up.
5. To return to the default pattern file, select 3 Reset Pattern File to Default and enter y to confirm. The
pattern file is reset to default.

6. To add additional directories, do the following:

a. Select 2 - (Re)Create Custom Pattern File. The list of additional directories available for the current
instance appears.
b. Select the directories, one by one, to add to the backup and enter q when finished.
4.4.2.2 Alarms Configuration

In the event of a failure, an alarm is generated and a message is sent. By default, the messages appear on
the primary component console and the RDR backup server console. You can create a list of additional
hosts to receive the alarms as well. These hosts must run X Server to be able to display the messages.
As explained in Alarms Notification (Alarms Notification), there are two ways to configure the hosts that
display the messages:
 Private list: A list of hosts to receive the messages from a specific RDR instance. The list is located in
the file:
opt/RDR/config/backup/RDR.displays.<instance_name>
 Common list: A list of hosts to receive the messages from all RDR instances. The list is located in the
file:
/opt/RDR/config/backup/RDR.displays
To define the hosts to receive alarms from all instances:

1. From the RDR Instances list, enter r.
The RDR Common Actions menu appears.
2. Select 3 Set Global Alarm Notification Options.
The RDR Alarm Notification Editor menu appears.
3. Further actions are the same as defining a host to receive alarms from a specific instance. Continue
with Step 3 in the following procedure.

To define the hosts to receive alarms from a specific instance:

1. Select a configured instance and then select 2 Instance Configuration Menu.
2. Select 4 Setup Alarms Notification.
The RDR Alarm Notification Editor menu appears.
3. To view the list of hosts receiving alarms, Select 3 Show Current Notification List.
The hosts receiving alarms for the selected instance are displayed.
4. To add a host to receive alarms, Select 1 Add a Display to Notification List and enter the host name to
be added.
The host is added and will receive any alarm notifications from the selected instance.

5. To stop a host from receiving alarms, do the following,

a. Select 2 Remove a Display from Notification List.
The hosts currently receiving alarms are listed.
b. Enter the number of the host name to be removed.
c. Enter y to confirm.
The host is removed and will not receive any further alarm notifications from this instance.
6. To remove all configured hosts, allowing only the default hosts to receive the alarms, select 4 Remove
All Configured Entries.
4.4.2.3 Assigning and Removing a Shadow Backup Server

A shadow server stores copies of the replicas from the RDR backup server in order to provide higher
redundancy to the RDR backup system. When using a shadow server, the RDR tool must also be installed on
the shadow server.
When a shadow backup is configured for an instance immediately after a successful backup session, the
backup server performs an additional replication of the instance backup folder (replica) to the assigned
shadow server.
A shadow backup is configured per RDR instance. Therefore, you can assign a separate shadow server for
each instance.
NOTE: The replica instance directory may be assigned to different paths in the Shadow and
Backup servers.

NOTE:
Configure the shadow backup server only after performing an initial manual backup of each
instance to test the replication process. This provides the backup data necessary to form a
shadow replica.
It is recommended to postpone shadow backup configuration until all basic components
(excluding mirror components) have been configured.
To assign or remove a shadow server:

1. From the RDR Instances list (see RDR Instances List), select a configured instance.
The RDR Instance Configuration Options menu is displayed.
2. To assign a shadow backup server:

a. From the RDR Instance Configuration Options menu, select 2 Advanced Configurations Options.
The Advanced Configuration Options menu is displayed.

b. Select 2 Assign Shadow Backup Server. Prompts are displayed for:

 Name or IP address of the Shadow server.
 Path of the replica folder on the shadow server.
c. Enter the shadow server name or IP, and replica path, then y to confirm.
The server is assigned as a shadow server for the current instance.
3. To remove the shadow server,
a. From the RDR Instance Configuration Options menu (see Step 1), select 2 Advanced
Configurations Options.
The Advanced Configuration Options menu is displayed.
(When a shadow server is already assigned to the instance, option 2 in this menu becomes
Remove Shadow Backup Server.)
b. To remove the shadow server, select 2 Remove Shadow Backup Server and enter y at the
confirmation.

4.4.2.4 Modifying Instance Configuration

You can change the details of an instance’s configuration, such as modifying the number of replicas stored
or changing the backup directory.
To modify instance configuration:

2. Select 1 Re-configure Instance.

You are prompted to define the configuration options as explained in Configuring Instances.

4.4.2.5 Removing the Configuration of an Instance

You can unconfigure an instance, thereby stopping its scheduled backups and alarm notifications, and
deleting its backup folder.
To remove the configuration details of an instance:

2. Select 5 Unconfigure Instance and enter y to the confirmations.

All configurations are removed including the Crontab entries.

4.4.2.6 Viewing Instance Details

You can easily view an instance’s information, such as current available backup replicas, backup scheduling,
and alarms notification settings.
To view an instance’s details:

 From the RDR Instances list (see RDR Instances List), select a configured instance and then select
1-Show Instance Status.
Details of the instance are displayed.

4.4.3 Removing all Instances Associated with a Primary

Component
You can remove all discovery and configuration information associated with a primary component,
including the data backups.
CAUTION: This action cannot be reversed. All data backups will be lost.
To remove all instances associated with a primary component:

2. Select 2 Special RDR Backup Server Configuration Actions.

The RDR Backup Server Special Configuration Options menu appears.
3. Select 1 Remove all Instances associated with a Primary.

A list of the primary hosts appears.
4. Select the primary host to remove instances. A warning appears reminding you that this action cannot
be undone.
CAUTION: All information associated with the primary component will be lost.

5. To remove the instances, enter y. To cancel, enter n.
4.4.4 Resetting Primary Host SSH Keys

If a primary host has been changed or a new one is added, it is necessary to reset the SSH keys.
CAUTION: This should only be performed in very specific cases.
To reset primary host SSH keys:

2. Select 2 Special RDR Backup Server Configuration Actions.

The RDR Backup Server Special Configuration Options menu appears.

3. Select 2 Reset Primary Hosts SSH keys.

A warning appears.
4. To continue, enter y. To cancel, enter n.
4.5 Defining an Alternate Primary Cache Location

Relocation of the alternate primary component cache directory is required when the /var partition is too
small.
To configure an alternate primary cache location, the following two steps are required:
 Create and define a new cache directory.
 Share the new directory with the zone(s).
NOTE: In case of Primary cache relocation, you should not only share the EMS / STMS /NMS
zone with the new cache folder (in global zone), but also the Oracle zone.

To create and define a new cache directory:

1. As root, activate the RDR at the Global zone of the Primary component.
2. Select 2 Primary Component Actions > 1 Configure Special Primary Component Options > 1 Relocate
Cache Folder.
The RDR lists the instances. For example:
3. Select an instance.
The old cache directory is displayed and you are prompted for the new cache directory location.
4. Enter the new cache directory. Be sure that there is enough space to hold the database backup. If the
directory does not exit, it is created.
5. Enter y to confirm.
NOTE: The new location can be on a different disk too.

To share the alternate cache directory with the zone(s):
NOTE: This procedure is required to share the alternate cache directory with the EMS zone.
For OBIEE, STMS, EMS-MPT, and EMS-XDM version 8.1 and higher, this procedure also needs
to be operated for the Oracle zone.
1. As user root, run the ZoneAdmin tool and select the relevant zone.
The Zone Actions Menu appears.

2. Select 3 Settings Menu.

The Settings menu appears.
3. Select 3 Define Global Shared Directory.

A prompt appears for a directory to share.
4. Enter the directory path and y to confirm.

The directory is shared.
The directory is shared.
NOTE: To remove sharing, select 4 Remove Global Shared Directory and then reboot the
zone.

4.6 Mirror Component Configuration

This section describes various configuration actions required following mirror component installation.
NOTE: Reverse update doesn't use an alternative mirror cache directory (if it was defined).
4.6.1 Disabling Application Auto Start

The standard component installation process automatically enables the Application Auto Start feature,
which causes the NMS, or EMS applications to start up automatically when a station starts. The feature
must be disabled while the component is in Standby mode.
Application Auto Start should be re-enabled upon switchover to the mirror component, as described in
Setting the Mirror Component.
To disable application auto start:

 To disable automatic startup, create matching flag file/s by entering the script line/s for the required
application/s, as shown below. (Enter only the line relevant for the required application.)
touch /etc/ .NO_NMS_AUTO_START (Any NMS)
touch /etc/ .NO_SYN_AUTO_START (EMS-Syncom B10.100 or later)
touch /etc/ .NO_XDM_AUTO_START (EMS-XDM V5 or later)
touch /etc/ .NO_STMS_AUTO_START (STMS V4.1 or later)
touch /etc/ .NO_OBI_AUTO_START (OBIEE)
4.6.2 Restoring Large Mirror Component DB with Alternate

Cache Location
The default cache location used on the mirror component (var/containers/share) accommodates
approximately 10 GB capacity. If you will restore larger DBs in a multi-zone environment, you can configure
a different path for the cache that will accommodate a larger recovery file size.
NOTE: Alternate cache location is not relevant for NMS, OBIEE, STMS, EMS-MPT, EMS-XDM,
and EMS-Syncom instances.
NOTE: The alternate cache location applies only for recovery actions, not for reverse update.
For information about reverse update, see Restarting the Primary Instance after Recovery
(Reverse Update).

To configure the Mirror Component to use an alternate cache location:

1. At the Mirror station, from the RDR Instances list (see RDR Instances List):
a. Enter r.
The RDR Common Actions Menu appears (see RDR Common Actions Menu). )
b. Select 5 Command Center Mode.

The Possible RDR modes of Activity menu appears.
c. Select 3 Mirror Component Actions.

The RDR Mirror Component Actions menu appears. (This choice applies even if you are restoring
to a primary component.)
2. Select 2 Configure Mirror Component Options.

The Configuration dialog appears. It asks for Backup Server name or IP.
3. Enter the required name or IP. You are asked for the cache location path.
4. Enter the required cache location path.

A confirmation of the parameters appears.
5. Enter y to complete the configuration.

5 Creating and Scheduling Backups
This section describes how to create and schedule regular backups or static archives, and view Crontab
entries. A backup can only be performed after configuring the instance.
NOTE: Large automatic database backups may impair system performance. They take time
and heavily load the system. You can avoid network congestion by assigning appropriate
offsets to each instance’s replication sessions, so that they do not run at the same time.
IMPORTANT: You Can Not perform simultaneous backup of instances (applications) using the
same Oracle DB Server.
5.1 Activating an Unscheduled Backup

In addition to scheduled backups, you can perform a backup at any time. For example, an immediate
backup is needed:
 After first-time configurations. After completing first-time instance configurations, it is strongly
suggested to do a full backup for each instance.
 Before an upgrade.
To begin an unscheduled regular backup:
NOTE: Full backups may take a long time.
2. Select 3 Start Regular Backup Session.
The backup session begins.
NOTE: Only one backup session can run on a primary component at a time. If you try to run a
backup on a primary component that has another backup session in progress, you receive a
Backup Session Overrun error.

Remote Data Replicator (RDR) User Guide Creating and Scheduling Backups
5.2 Activating an Unscheduled Archive Backup

An archive backup is a static backup of the system at a specific time. Use the archive option in order to
"freeze" the system state at a specific time to ensure additional redundancy.
NOTE: Even though archive backups ensure additional redundancy, take into account that an
archived replica uses additional disk space.
To begin an unscheduled archive backup:

The RDR Instance Actions Menu is displayed.
2. Select 4 Start Archive Backup Session.
You are prompted to give a name to the archive backup.
3. Enter a name or accept the default (archive).
The archive backup begins.

5.3 Scheduling Backups

You can schedule regular or archive backups to be done automatically for each primary component
instance at intervals that are constant (set time span between backups) or non-constant (specific time on
one or more days of the week or month).
Replicas at constant intervals can be set to occur as little as 10 minutes apart. The selected interval cannot
be shorter than the backup creation time.
To simplify recovery, it is advisable to schedule all primary component instances with the same backup
intervals. Offsets can be used to stagger the individual starting times a number of minutes apart according
to database size, and therefore balancing the load and avoiding network congestion.
NOTE: Scheduling a backup session is a very sensitive operation and must be performed
cautiously. Be careful to avoid scheduling conflicts and backup session overlaps.
To define a backup schedule:

The RDR instance Actions Menu is displayed.
3. Select 3 Schedule Instance Backups to start RDR Scheduler utility.

4. Select an instance.
The types of available scheduling methods are listed.
5. Select a scheduling method and answer all the questions about scheduling. For more information, see
Backup Sched.
6. When you are finished, enter q.
The Crontab entries are listed, including the backup sessions you have just scheduled.
The pending entry is displayed in regular font with the word {pending} in red. The backups that have
already been added to Crontab are in a bold black font.
NOTE: At this point, you have only defined the scheduled backup. It is listed as a Crontab
entry with a "pending" status. It will not take effect until you append it to the Crontab as
explained in the following step.
Backup Sessions that have taken effect are applied entries and are displayed in bold.
The following options are available.

 Select an entry by its number.
 Enter a to define another backup entry.
 Enter q to exit.
7. To append a pending backup session, enter its number.
The RDR displays the option that you selected and presents the following options:
 1 Apply the entry to the Cron Table: The scheduled backup session will take effect.

 2 Remove this temporary entry: Deletes the entry.

 3 Show entry details: Displays the entry details.
8. To apply the entry, select 1 Apply this entry to Cron Table.

The backup is scheduled.
5.3.1 Backup Schedules

There are 2 methods of backup session scheduling:
 By constant interval: Schedule periodic backups in a constant time interval of minutes or hours. Use
offset to distribute backups, preventing overlapping and overloading of different
components/instances backups.
 At specific time of the day: Define a backup session invocation at a specific time of the day. The
action can be repeated daily or on specific day(s) of the week or the month.
The following table describes the options available in the RDR Scheduler menu.
Table 5-1: RDR scheduler menu
Menu option Description

Regular Backup - by Constant A regular backup scheduled at a constant time interval.
Interval A regular backup is a standard RDR backup session overwriting the oldest
existing cyclical replica. (The amount of replicas saved is according to the
predefined number of replicas. For details, see Replicas.)
Regular Backup - at Specific A regular backup, scheduled at a specific time of a specific day.
Time of the Day

Menu option Description

Archive Backup - by Constant An archive backup, scheduled at a constant time interval.
Interval An archive backup is a special backup session to a named separate replica
(default name – archive).
Archive Backup - at Specific An archive backup, scheduled at a specific time of a specific day.
Time of the Day
Use the following illustrated examples to guide you in configuring the backup schedule:
Figure 5-1: Scheduling a regular backup at constant interval
Figure 5-2: Scheduling a regular backup at a specific time
Figure 5-3: Scheduling an archive backup at constant interval

Figure 5-4: Scheduling an archive backup at a specific time
5.4 Viewing Crontab Entries

This section describes how to view the scheduled Crontab entries of a specified instance.
To view Crontab entries:

The RDR instance Actions Menu is displayed.
3. Select 3 Schedule Instance Backups to start RDR Scheduler utility.
The backups that have already been scheduled are listed.

5.5 Backup Log Files

The RDR creates log files for each Backup instance. Every time the RDR backs up an instance, it updates the
log file with information such as if the backup was successful or failed.
The RDR automatically names the log files according to the format, <instance>@<Hostname>_<zone>.log,
and stores them in the folder /var/RDR/logs.

6 Restoring from a Backup
This section describes how to recover from a backed-up replica in the event of a primary station database
failure. This includes the following topics:
 Recovery to a mirror component, via any replica on the Backup component.
 Recovery to a primary component. This can be done:
 Via any replica on the Backup component (similar to recovery to a mirror component)
 Via a shortcut procedure which uses the latest replica currently in the primary component
cache.
NOTE: Before restoring from backup, make sure that the application is configured in the
target server.
NOTE: For an STMS backup, the following items are not maintained in the DB and must be
stored and backed up separately on a Network File System (NFS) server that is mounted under
the root directory of the STMS server:
 Historical counters
 Software builds
If the NFS server is mounted at the same point in the file system, the standby STMS is able to
access these items.
6.1 Restoring to the Mirror or Primary

Component
The following sections describe how to restore to any appropriately configured station from a Backup
component replica. Essentially the same basic procedure applies whether the station will serve as the
mirror or primary component. Slight differences in that procedure are described in context. Additional pre-
and post- configuration procedures apply to recovery to a mirror component.
6.1.1 Recovery to a Mirror Component

The following notes apply to recovery to a mirror component only.
Mirror components are normally in standby mode, meaning the instance on the mirror component is
installed but not running and ready for a command to launch the recovery process. When a primary
component fails, the operator can start a mirror station from any backed-up replica. The mirror site is
instructed from which database replica to recover. After database synchronization is completed, work can
carry on as usual.

Remote Data Replicator (RDR) User Guide Restoring from a Backup
The recovery to mirror component procedure is in two main parts:

1. Starting a Mirror or Primary Recovery Session.
2. Setting the mirror component with required parameters from the primary component, as described in
Starting a Mirror or Primary Recovery Session.
NOTE: Additional manual configuration operations may be required to provide full system
functionality on the mirror site. These operations are application specific depending on the
recovery case, RDR, and the managed network topology, and are beyond the scope of this
manual. For information, refer to the relevant application manuals and engineering
procedures.
On a system with LightSOFT and EMS(s), first start the LightSOFT server and then the EMS(s), so that each
EMS is registered on the LightSOFT server.
Upon successful completion of the recovery session, start the application in the regular way.
After the primary component is ready to be returned to operation, a Reverse Update procedure is used to
load the primary component with changes that occurred to the system when the mirror component was
active. This is described in Restarting the Primary Instance after Recovery (Reverse Update).
NOTE: When a mirror station is installed with components that do not have to be mirrored
(for example a single mirror station supporting an nms server and ems residing on two
stations), be sure to only start the relevant mirror component/s.
6.2 Starting a Mirror or Primary Recovery Session

This procedure restores a selected Back Up replica to the current Mirror or Primary component.
NOTE: When the procedure is performed on a primary component, the menu text implies
that a "mirror" component is involved. However all the steps apply to the type of component
currently being restored and the presented instance choices pertain to the current
component.
 Ensure that the primary instance is down.

 Ensure that the appropriate application is correctly installed and it not running on a mirror
component.
 (Recovery to mirror only) If a special cache configuration is required for the mirror component, ensure
that the procedure described in Mirror Component Configuration has been performed.

To start a mirror (or primary) recovery session:

1. At the Mirror (or Primary) station, from the RDR Instances list (see RDR Instances List):
a. Enter r.

Select 3 Mirror Component Actions. The RDR Mirror Component Actions menu appears. (This
choice applies even if you are restoring to a primary component.)
2. Select 1 Start Mirror Recovery Session.

RDR asks for the Backup Server to restore from:
3. Enter the backup server to restore from.

The RDR checks the connection to the backup server selected. It then lists the instances (all zones)
available on the local mirror (or primary) component.
4. Select an instance to restore the DB to.
NOTE: If the instance is running, the following warning appears and you cannot continue with
the restore.
"Error!!! Cannot perform recover when LightSoft Network Manager Server is running."

RDR then lists the instances available on the backup server which match the type of mirror (or
primary) instance you have selected in this step.
5. Select a backed-up instance to restore from.

The RDR lists the replicas available of the instance selected.
NOTE: The RDR lists both automatic and archive backup replicas.
6. Select a replica.
The utility compares the versions of the selected instance to recover with the one existing on the
mirror.
 If they do not match, the following warning appears.

 If they do match, or you selected y above, RDR displays a summary of the recovery session
defined in the previous steps. A confirmation appears.
The recovery session begins.
At the end of a successful recovery, the following message appears:
6.3 Setting the Mirror Component

The procedures in this section must be performed following recovery to a mirror component. They do not
apply after recovery to a primary component.
After restoring to the mirror component, you need to configure the mirror component with the primary
component parameters, and set the other components to recognize the mirror component instead of the
failed primary component.

NOTE:
Valid mirror station configurations in the following procedures may include:
LightSOFT client on a dedicated station, OR
EMSs on a dedicated station, OR
LightSOFT server in combination with a LightSOFT client and/or EMSs
A mirror station cannot only include an active LightSOFT client and EMS(s).
When the LightSOFT client and/or EMSs must be recovered on the same mirror station as the
LightSOFT server, perform the LightSOFT server recovery procedure first.
1. Restore the required instances to the mirror component (see Starting a Mirror or Primary Recovery
Session).
2. Enable autostart for each component that will be activated by the Mirror by running the following
commands as root user:
touch /etc/ .NO_NMS_AUTO_START (Any NMS)
touch /etc/ .NO_SYN_AUTO_START (EMS-Syncom B10.100 or later)
touch /etc/ .NO_XDM_AUTO_START (EMS-XDM V5 or later)
touch /etc/ .NO_STMS_AUTO_START (STMS V4.1 or later)
touch /etc/ .NO_OBI_AUTO_START (OBIEE)
To recover the LightSOFT server to the mirror site:

1. In the mirror site, activate the nms instance on the mirror component, as follows:
a. Enter rm /etc/.NO_NMS_AUTO_START to enable autostart on boot. )
b. Enter /opt/NMS/server/sh/SetupNMS.sh.
c. If LightSOFT server is alone on the mirror station, select
Configure NMS single server.
OR
If LightSOFT server is distributed amongst multiple servers, select Configure NMS cluster.
(In this case, the same Primary Servers WorkStation ID(s) should be copied to the alternate
mirror component.)
OR
If the EMS, and/or LightSOFT client share the same mirror station, select Combined Mode
(LightSoft + EMS + Client).
2. In the primary site, on each LightSOFT client that remains active, enter
/opt/NMS/server/sh/SetupNMS.sh
3. In the primary site, on each EMS that remains active, do the following:
a. Update ems.conf or enm.conf by modifying the expression
S &env_ns_port ENBARH_NAMESERV_PARAMS Primary:5075:2
substituting the applicable mirror host name in place of Primary (the primary host name).

b. Enter RegisterEMS -f Mirror:5075:2

substituting the applicable mirror host name in place of Mirror (the mirror host name).
To recover a LightSOFT client to the mirror site:
NOTE: If the same mirror station is also used to recover the LightSOFT server, perform the
LightSOFT server recovery procedure first.
 In the mirror site, activate the required LightSOFT clients on the mirror component, as follows:
 If only a LightSOFT client is to be activated on the mirror (the LightSOFT server remains active on
the primary site), enter /opt/NMS/client/sh/SetupNMS.sh
OR
 If the LightSOFT server is distributed amongst multiple servers, select Configure NMS cluster.
OR
 If both the LightSOFT server and a LightSOFT client are to be activated on the same mirror, enter
/opt/NMS/server/sh/SetupNMS.sh
No actions are required on either LightSOFT clients or EMSs on the primary site.
To recover an EMS to the mirror site:
In the mirror site, activate the required EMSs on the mirror component as follows:
1. Update ems.conf or enm.conf by modifying the expression
R &env_mtnm_ems_no EMS_INSTANCE_NUMBER ### 1 999
substituting ### with the EMS ID of the Primary EMS.
2. Update ems.conf or enm.conf by modifying the expression
S &env_ns_port ENBARH_NAMESERV_PARAMS NMSComp:5075:2
substituting NMSComp with the hostname of the station that functions as the LightSOFT server, as
follows:
 If the LightSOFT server remains active on the primary component, specify the primary
component station.
 If the LightSOFT server has been recovered on a mirror station, specify that station’s name.
3. Enter RegisterEMS -f NMSComp:5075:2
In place of NMSComp, substitute the hostname of the station that functions as the LightSOFT server.

4. Enter :
No actions are required on either LightSOFT clients or the LightSOFT server on the primary site.
To recover an STMS to the mirror site:
In the mirror site, activate the required EMSs on the mirror component as follows:
1. Configure the STMS using ConfigureSTMS.sh. If the STMS server was already configured, reconfigure it
(using "ConfigureSTMS.sh –U" to un-configure and then run the configuration tool). Pay attention to
the following configuration parameters:
a. is this STMS Server being integrated with ECI LightSOFT NMS? (yes / no)
if yes: )
b. Enter NMS server hostname or IP

c. Enter "EMS Instance Id: "
2. Run:
rm /etc/.NO_STMS_AUTO_START (STMS V4.1 or higher)
No actions are required on either LightSOFT clients or the LightSOFT server on the primary site.
To recover an OBIEE to the mirror site:

 In the mirror site, activate the OBIEE instance on the mirror component to auto-start at boot by
entering the following command:
rm /etc/.NO_OBI_AUTO_START
6.4 Performing Direct Recovery

If it is determined that only the DB is corrupted and other aspects of the Primary component, including the
primary cache, are intact, you can return the primary instance to normal operation through a direct
recovery session. For example, if the NMS main server DB is corrupted, the operator can quickly revert to
the last backup data instead of performing a full recovery session from the remote Backup server.
The restoration is done directly from the last RDR cache on the same host, and avoids the transfer time of
copying from the remote Backup server that is described in Restoring to the Mirror or Primary Component.
This is possible because the Backup replica was originally created by copying from primary to backup via the
primary component’s cache.

 Ensure that the instance application to be recovered is shut down on the primary component.
 Ensure that the appropriate applications are correctly installed on the primary component.
NOTE: You cannot perform direct recovery after a reverse update. In such a case, a backup
should be taken.
To start a direct recovery session:

1. At the Primary station, from the RDR Instances list (see RDR Instances List):
a. Enter r.

c. Select 2 Primary Component.

The RDR Primary Component Actions menu appears.
2. Select 2 Start Direct Recovery Session.

The Instances in Cache menu appears, showing the available instances. Select the primary instance
you want to restore to.

3. RDR displays a summary of the recovery session defined in previous steps. A confirmation appears.
4. Enter y to continue. The processing starts.
A success message appears when finished.
6.5 Recovery Log Files

The RDR creates log files for each Recovery instance. Every time recovery actions are performed, it updates
the log file with information such as if the recovery was successful or failed.
The RDR automatically stores the log file in the path and folder: /var/RDR/log/restore.log.
The log file is located in the station acting as the mirror component. If the recovery is to the primary
component instead of the mirror component, the log will be located in the primary component.

7 Restarting the Primary Instance after
Recovery
This section describes how to restart the primary component to normal operation after recovery from a
failure through a reverse update session from the mirror component.
7.1 Performing Reverse Update

You can return the primary component to normal operation after recovery from a failure through a reverse
update session. The process involves loading the primary component with changes that occurred in the
system since the mirror component was activated.
Reverse update is performed as a cold backup session and must be implemented only when instance
applications on mirror and primary components are down.
The procedure includes two main steps:
1. Performing reverse update to the primary component.
2. Setting the other components to recognize that the primary component has been returned to duty in
place of the mirror component.
NOTE: Reverse update doesn't use an alternative mirror cache directory (if it was defined).
NOTE: The Reverse update feature uses the standard default cache (/var/containers/share)
and not an alternate mirror cache configured to accommodate large DBs in a multi-zone
environment; see Restoring Large Mirror Component DB with Alternate Cache Location. If the
standard cache system is insufficient for the current DB, reverse update must be performed
using a manual procedure.
 Ensure that the instance application to be reverse updated is shut down on the mirror and primary
components.
 Ensure that the appropriate applications are correctly installed on the primary component.
This section describes how to perform reverse update to the primary component.
After completing this procedure, you must set the other servers to recognize that the primary component
has been returned to duty in place of the mirror component.

Remote Data Replicator (RDR) User Guide Restarting the Primary Instance after Recovery
To start a reverse update session:

1. At the Mirror (or Primary) station, from the RDR Instances list (see RDR Instances List):
a. Enter r.

c. Select 2 Primary Component Actions.

The RDR Primary Component Actions menu appears. (This choice applies even if you are
restoring to a primary component.)
2. Select 3 Start Reverse Update Session.

The RDR asks from which mirror server to restore.
3. Enter the mirror server to restore from.

The RDR checks the mirror server connectivity and then displays the installed instances on the
primary component.
4. Select a primary instance to restore to.

The RDR lists instances on the mirror server that match the primary instance you have selected in this
step.

Remote Data Replicator (RDR) User Guide Restarting the Primary Instance after Recovery
The following message appears if the instance is active.
5. Select a backup instance to restore from.
The utility compares the versions of the selected mirror and primary instances. If they do not match, a
warning appears.
The RDR lists the details of the reverse update with a warning that the reverse update will overwrite
all current data
6. Confirm the reverse update session.
The session begins.
A success message appears when finished.
7.2 Recognizing the Primary Component

After reverse update to the primary component (see Performing Reverse Update), you must set other
servers to recognize and communicate with the primary component that has been returned to duty in place
of the mirror component.
This procedure is similar to setting the mirror component after recovery, as described in Setting the Mirror
Component.

8 Suspending or Resuming RDR Operation
This appendix describes how to suspend RDR activities, for example, in order to perform maintenance
operations or a software upgrade, and to resume the activities when required.
To suspend or resume all RDR operation:

2. Select 6 Suspend All Backups/6 Resume All Backups.
To suspend or resume the RDR operations of a specific instance:

1. From the RDR Instances list (see RDR Instances List), select an instance.
2. Select 5 Suspend Instance Backups/5 Resume Instance Backups.
Figure 8-1: RDR Instance Actions Menu

9 RDR Command Center Diag Mode
To help diagnose problems, you can activate the command center mode in order to create a log file with
the following information:
 System information, such as HostInfo, menuconf, and networking.
 All configuration activities.
To activate the command center diag mode:

2. Select 7 Turn ON/OFF RDR Command Center Diag Mode.

The menu reappears marked with Diag Mode ON and a new option, 8 Collect Diagnostic Information,
is added.
3. To view the information, select 8 Collect Diagnostic Information.

10 RDR from SPARC to x86
This procedure describes how to run RDR when the EMS-MPT, or EMS-XDM main site is on a SPARC station
and the backup is on an x86.
NOTE: This procedure is not applicable for EMS-MPT V2.1 and up.
Operate the following procedure:

1. Install the RDR package in both the EMS global server and the Oracle server.
2. Using RDR, configure the primary instance (EMS SPARC) from a backup server.
3. Take the backup using RDR.
4. Run RDR in the mirror station and perform a mirror recovery.
5. Run the EndianDBMigration script .
6. Start EMS in the mirror (x86).
7. After the primary station is up, perform a reverse update procedure.
8. Run the EndianDBMigration script.
9. Start the EMS in the primary (SPARC).

11 RDR from x86 to SPARC
This procedure describes how to run RDR when the EMS-MPT, or EMS-XDM main site is on an x86 and the
backup is on a SPARC station.
NOTE: This procedure is not applicable for EMS-MPT V2.1 and up.
Operate the following procedure:

1. Install the RDR package in both the EMS global server and the Oracle server.
2. Using RDR, configure the primary instance (EMS x86) from a backup server.
3. Take the backup using RDR.
4. Run RDR in the mirror station and perform a mirror recovery.
6. Start EMS in the mirror (SPARC).
7. After the primary station is up, perform a reverse update procedure.
9. Start the EMS in the primary (x86)

12 RDR Commands
This section describes various UNIX scripts that can be used to perform specialized RDR operations. This
section is for expert reference use only. Users should perform regular RDR operations using the RDR menu
structure accessed with the RDR command, as described in the procedures in this manual.
12.1 SyncMaster
RDR synchronization (replication) utility.
Function description: Performs direct replication between the primary component and backup server.
Supports regular and archive replications. Normally invoked by cron (see SetCronRDR).
Usage:SyncMaster [-i inst_name] [-dest target]
[-a] [-l] [-ll log_level] [-dd debug_level]
[ -suspend | -continue ] [-help ]
Options:
-i <instance name> Instance name.
-dest <target> Backup to specific target (replica name).
-a Archive backup.
-dd <debug_ level> Set debug level [0-3, default - 0].
-l Enable logging.
-ll <log_level> Set log level [0-3, default - 1].
-suspend Temporarily suspend activity.
-continue Resume backup activity (if suspended).
-help Print help message.
12.2 ReverseUpdate
RDR Primary component restore utility.
Functional description: Restore Primary Component from Mirror
Usage: ReverseUpdate
[-M mirror host] [-p primary_instance]
[-m mirror_instance] [-dd debug_level] [-f ] [ -help ]
Options:
M <hostname> Restore from specified mirror host.
- p <instance name> Instance on Primary Host to restore to.
- m <instance name>D Instance on Mirror Host from where to
restore.
-dd <debug_level> Set debug level [0-3], default – 0.
-f Set force (non-interactive mode).

Remote Data Replicator (RDR) User Guide RDR Commands
12.3 RestartMirror
RDR restore (recovery) utility.
Functional description: Interactive utility for restoring a replica from a backup server and launching an
application on a mirror component.
Usage: RestartMirror
[-p inst_name] [-m inst_name] [-b hostname]
[-r replica] [-f] [-dd debug_level] [-help]
Options:
--p <inst_name> Primary instance name.
--m <inst_name> Mirror instance name.
-b <hostname> Backup Server from which to restore.
r <replica> Replica from which to restore.
dd <debug_level> Set debug level [0-3].

13 Alarm Notification Lists
The following table lists the alarm notification messages and suggestions for troubleshooting purposes.
Error No. Alarm Notifications Diagnosis

1 Fatal installation/config problem There is a problem with the RDR package
configuration.
3 Transfer cannot be completed There is a problem with the application
configuration.
5 Request cannot be completed
6 RDR cannot connect to A handshake cannot be established.
$PRIM_MASTER
12 RDR cannot transfer $inst_name Either the disk is full or there is a problem with
permissions.
11 Transfer cannot be complete There is a problem with the $BACKUP_SERVER
configuration.
10 RDR cannot connect to $inst_name There is a problem with the rsync server
$inst_name configuration.
20 Transfer interrupted A disk or network problem.
23 RDR cannot transfer $inst_name A permissions or network problem.
2|4|13|14|21|22|30 RDR cannot transfer $inst_name
99 Backup Session Overrun The previous session is still opened (pid `cat
$master_lock`).
50 RDR cannot replicate from
$PRIM_MASTER
51 RDR cannot make replica dir on A permissions or configuration problem.
$shadow_server
60 RDR cannot backup DB on
$PRIM_MASTER
70 RDR cannot backup local DB on A local cache size problem or a database
$PRIM_MASTER problem.
71 RDR cannot restore local DB
0 exit 0
* Unknown problem

14 Glossary
This glossary defines various terms used throughout this manual.
Application Software to be protected by RDR
Backup Server RDR component to store replicas
Backup Client Primary host to be backed up by backup server
Primary site Original set of computers running applications to be
protected
Mirror site Redundant set of computers running applications to
be protected
Primary component Host belonging to the primary site
Mirror component Host belonging to the mirror site
Shadow component Host backing up the Backup Server
Slave manager In the case of an integrated application host running
slave manager
Synchronization Process of copying data between components
Replica A single copy of application data stored on a backup
server
Archive Backup Special copy of application data for long-term storage
(replica)
Reverse Update Process of restoring data on a primary component
from a mirror component
Mirror Restart Starting the application on a mirror site after primary
failure
Site Protection Highest redundancy level providing recovery in the
event of total site disaster
Host Protection Redundancy solution providing recovery in case of
application host crash
Disk Protection Redundancy solution providing recovery in the event
of data disk crash
Instance Set of the RDR-supported application data associated
with the RDR component
Instance tag Symbolic name for instance identification
Hot backup Method of backing up application data without
shutting down the application
Cold backup Method of backing up application data that requires
application shutdown
Incremental backup Backup method that copies only the differences
relative to the last backup
Backup level In incremental backup method, a number specifying
the increment value

Remote Data Replicator (RDR) User Guide Glossary
crontab file UNIX file containing instructions for launching

commands at a specific time
Backup session Process of instance data copying to a backup server
Recovery session Process of restoring backup data on a mirror
component
Automatic backup Backup session invoked by crontab
session
Post-recovery action Instance-dependent action for setting up data after
recovery
Timestamp Special unique file created for every backup session
containing time and identification data

Remote Data Replicator (RDR) V6.1 User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Remote Data Replicator (RDR) V6.1 User Guide

Uploaded by

Copyright:

Available Formats

Remote Data Replicator (RDR)

ECI's NPT-1200, NPT-1020, and NPT-1010 are CE2.0 certified.

NPT-1600 complies with the MEF9 and MEF14 standards.

Remote Data Replicator's management applications run on VMWare virtualization

© Copyright, 2002-2016. All rights reserved worldwide.

1 About RDR................................................................................................... 1-1

2 Preliminary Requirements and Installation.................................................. 2-1

3 RDR Menus ................................................................................................. 3-1

ECI Telecom Ltd. Proprietary iii

4 RDR Configuration ....................................................................................... 4-1

5 Creating and Scheduling Backups ................................................................ 5-1

6 Restoring from a Backup ............................................................................. 6-1

7 Restarting the Primary Instance after Recovery ........................................... 7-1

ECI Telecom Ltd. Proprietary iv

8 Suspending or Resuming RDR Operation ..................................................... 8-1

9 RDR Command Center Diag Mode ............................................................... 9-1

10 RDR from SPARC to x86 ............................................................................. 10-1

11 RDR from x86 to SPARC ............................................................................. 11-1

12 RDR Commands ......................................................................................... 12-1

13 Alarm Notification Lists ............................................................................. 13-1

14 Glossary .................................................................................................... 14-1

ECI Telecom Ltd. Proprietary v

ECI Telecom Ltd. Proprietary vi

1.1 Functional Description

ECI Telecom Ltd. Proprietary 1-1

1.1.1.1 Primary Components

1.1.1.2 Backup Components

ECI Telecom Ltd. Proprietary 1-2

1.1.1.3 Mirror Components

NOTE: Dots (".") cannot be used in zone names.

ECI Telecom Ltd. Proprietary 1-3

ECI Telecom Ltd. Proprietary 1-4

1.2 Typical RDR Configurations

1.2.1 Backup Deployment

1.2.1.1 Shadow Backup Server

ECI Telecom Ltd. Proprietary 1-5

1.2.2 Primary and Mirror Configurations

1.2.2.1 1:1 Configuration

ECI Telecom Ltd. Proprietary 1-6

1.2.2.2 2:2 Configuration

ECI Telecom Ltd. Proprietary 1-7

1.2.2.3 N:2 Configuration

ECI Telecom Ltd. Proprietary 1-8

1.2.3 EMS Instance Configurations

1.2.4 LightSOFT Instance Configurations

1.3 Activation Overview

1.3.1 Backup Session

ECI Telecom Ltd. Proprietary 1-9

1.3.2 Recovery from Backup to Mirror

ECI Telecom Ltd. Proprietary 1-10

1.3.3 Reverse Update to the Primary Site

This process involves the following main steps:

1.3.4 Alarms Notification

1.3.5 RDR Activity Monitor

The Activity Monitor window displays the following information:

ECI Telecom Ltd. Proprietary 1-11

NOTE: The Activity Monitor is only displayed on the backup server.

To access the Activity Monitor window:

ECI Telecom Ltd. Proprietary 1-12

2.1 Application Requirements

ECI Telecom Ltd. Proprietary 2-1

NOTE: When upgrading NMS from v7 to v8.1, or v9 do the following:

2.1.1 Preliminary Requirements

2.1.2 Preconfigured Values