Remote Data Replicator (RDR) : User Manual

Remote Data Replicator (RDR)
User Manual
V 3.5
417006-2705-0H3-A00
Remote Data Replicator (RDR) User Manual
V 3.5
Catalog No: X34217
July 2005
st
1 Edition
© Copyright by ECI Telecom, 2005. All rights reserved worldwide.

This is a legal agreement between you, the end user, and ECI Telecom Ltd. (“ECI Telecom”). 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 YOU OBTAINED THEM.
The information contained in the documentation and/or disk is proprietary and is subject to all relevant copyright,
patent and other laws protecting intellectual property, as well as any specific agreement protecting ECI Telecom's
rights in the aforesaid information. Neither this document nor the information contained in the documentation and/or
disk may be published, reproduced or disclosed to third parties, in whole or in part, without the express, prior
written permission of ECI Telecom. In addition, any use of this document, the documentation and/or the disk, or the
information contained therein for any purposes other than those for which it was disclosed is strictly forbidden.
ECI Telecom reserves the right, without prior notice or liability, to make changes in equipment design or
specifications. Information supplied by ECI Telecom is believed to be accurate and reliable. However, no
responsibility whatsoever is assumed by ECI Telecom for the use thereof, nor for the rights of third parties, which
may be affected in any way by the use and/or dissemination thereof.
Any representation(s) in the documentation and/or disk concerning performance of ECI Telecom's product(s) are
for informational purposes only and are not warranties of product performance or otherwise, either express or
implied. ECI Telecom's standard limited warranty, stated in its sales contract or order confirmation form, is the only
warranty offered by ECI Telecom.
The documentation and/or disk is provided “AS IS” and may contain flaws, omissions or typesetting errors. No
warranty is granted nor liability assumed in relation thereto unless specifically undertaken in ECI Telecom's sales
contract or order confirmation. Information contained in the documentation and in the disk is periodically updated,
and changes will be incorporated into subsequent editions. If you have encountered an error, please notify ECI
Telecom. All specifications are subject to change without prior notice.
The documentation and/or disk and all information contained therein is owned by ECI Telecom and is protected by
all relevant copyright, patent and other applicable laws and international treaty provisions. Therefore, you must
treat the information contained in the documentation and disk as any other copyrighted material (e.g., a book or
musical recording).
Other Restrictions. You may not rent, lease, sell or otherwise dispose of the documentation and disk, as applicable.
YOU MAY NOT USE, COPY, MODIFY, OR TRANSFER THE DOCUMENTATION AND/OR DISK OR ANY COPY
IN WHOLE OR PART, EXCEPT AS EXPRESSLY PROVIDED IN THIS LICENSE. ALL RIGHTS NOT EXPRESSLY
GRANTED ARE RESERVED BY ECI TELECOM.
All trademarks mentioned herein are the property of their respective holders.
ECI Telecom 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 this documentation and/or disk, the information contained
therein, its use or otherwise. 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 documentation and/or disk and/or the information contained therein howsoever caused even if
advised of the possibility of such damages.
RDR User Manual Contents
Contents
About this Manual......................................................................... vii
Overview ............................................................................................................ vii
Intended Audience ............................................................................................. vii
Document Organization..................................................................................... viii
Document Conventions ....................................................................................... ix
Related Documentation........................................................................................x
Obtaining Technical Documentation ....................................................................x
Technical Assistance............................................................................................x
Your Opinion Is Very Important To Us ................................................................ xi
1 Introduction.............................................................................. 1-1
Overview .......................................................................................................... 1-1
What is RDR?................................................................................................... 1-2
Functional Description...................................................................................... 1-2
Typical RDR Configurations ............................................................................. 1-7
Activation Overview........................................................................................ 1-12
2 Preliminary Requirements ...................................................... 2-1

Overview .......................................................................................................... 2-1
Application Requirements ................................................................................ 2-1
Minimum Backup Server Disk Capacity ........................................................... 2-2
Communications and Bandwidth Requirements .............................................. 2-3
3 RDR Menus .............................................................................. 3-1

Overview .......................................................................................................... 3-1
RDR Main Menu............................................................................................... 3-1
RDR Configuration Menu ................................................................................. 3-3
RDR Utilities/Actions Menu .............................................................................. 3-4
4 Configuring Primary Components ......................................... 4-1

Overview .......................................................................................................... 4-1
Configuration Workflow .................................................................................... 4-2
Configuring Primary Components .................................................................... 4-3
Configuring the Display of Messages............................................................... 4-8
432006-2419-013-A00 ECI Telecom Ltd. Proprietary i

Contents RDR User Manual
5 Configuring Backup Components ......................................... 5-1

Overview .......................................................................................................... 5-1
Configuring the Backup Server ........................................................................ 5-2
Viewing Instance and Replica Status ............................................................... 5-5
Testing the Backup Configuration .................................................................... 5-6
Configuring a Shadow Backup Server ............................................................. 5-6
6 Configuring Mirror Components ............................................ 6-1

Overview .......................................................................................................... 6-1
Configuring the Mirror Component ................................................................... 6-1
Reconfiguring the Mirror Component ............................................................... 6-3
Application Auto Start....................................................................................... 6-3
7 Creating and Scheduling Backups of Primary Component

Instances .................................................................................. 7-1
Overview .......................................................................................................... 7-1
Creating Regular or Archive Backups .............................................................. 7-2
Defining Backup Schedules ............................................................................. 7-3
Viewing crontab Entries.................................................................................... 7-8
8 Recovering to a Mirror Component ....................................... 8-1

Overview .......................................................................................................... 8-1
Restoring to the Mirror Component .................................................................. 8-2
Setting the Mirror Component .......................................................................... 8-7
9 Restarting the Primary Instance After Recovery

(Reverse Update) ..................................................................... 9-1
Overview .......................................................................................................... 9-1
Performing Reverse Update............................................................................. 9-2
Recognizing the Primary Component............................................................... 9-5
ii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

A Suspending or Resuming RDR Primary Component

Operation................................................................................. A-1
10 RDR Commands ..................................................................... B-1
11 Glossary .................................................................................. C-1
12 Index .......................................................................................... I-1
432006-2419-013-A00 ECI Telecom Ltd. Proprietary iii

Table of Figures
Figure 1-1: Sequence of LightSoft instance backups over time ................................... 1-6
Figure 1-2: Simple configuration example – 1:1 ........................................................... 1-9
Figure 1-3: Simple configuration example – 2:2 ......................................................... 1-10
Figure 1-4: RDR complex configuration – N:2 with independent backup server ........ 1-11
Figure 1-5: General replication scheme...................................................................... 1-13
432006-2419-013-A00 ECI Telecom Ltd. Proprietary v

About this Manual
In this Section
Overview .........................................................................................................vii
Intended Audience...........................................................................................vii
Document Organization................................................................................. viii
Document Conventions ....................................................................................ix
Related Documentation .....................................................................................x
Obtaining Technical Documentation.................................................................x
Technical Assistance .........................................................................................x
Overview
The Remote Data Replicator (RDR) application provides redundancy features
for the network management applications of ECI Telecom's Optical Network
Division – EMS-XDM®, EMS-SYNCOM, and LightSoft®.
This manual describes the requirements for successful RDR installation, and
detailed procedures for configuration and activation.
This manual is intended for use with RDR V 3.5, but most procedures are also
compatible with previous versions. Differences in use between RDR versions
are noted where applicable.
Intended Audience
This manual is intended for telecommunications network personnel backing up
management system databases, and implementing effective recovery from
those backups as required.
432006-2419-013-A00 ECI Telecom Ltd. Proprietary vii

About this Manual RDR User Manual
Document Organization
The manual includes the following chapters:
Chapter 1, Introduction, provides a general and functional description of
RDR, its topological elements, features, and typical configurations.
Chapter 2, Preliminary Requirements, describes the preconditions for
successful installation.
Chapter 3, RDR Menus, describes some principal menus in configuration
and activation procedures.
Chapter 4, Configuring Primary Components, provides an overview of
the component configuration workflow, and how to configure primary
components to use RDR for replicating and creating optional display
messages.
Chapter 5, Configuring Backup Components, describes how to
configure backup components as repositories for RDR replicas.
Chapter 6, Configuring Mirror Components, describes how to configure
mirror components of the system to enable recovery from a selected replica
in the event of a primary failure.
Chapter 7, Creating and Scheduling Backups of Primary Component
Instances, describes how to create regular backups or static archives,
schedule automatic backups, and view the schedule (crontab) entries
generated by the Unix cron scheduling mechanism.
Chapter 8, Recovering to a Mirror Component, describes how to start a
mirror station from any backed up replica in the event of a primary station
failure.
Chapter 9, Restarting the Primary Instance After Recovery (Reverse
Update), describes how to return the primary component to normal
operation.
Appendix A, Suspending or Resuming RDR Primary Component
Operation, describes how to suspend and resume RDR primary component
activities, for example in the case of maintenance operations or software
upgrade.
Appendix B, RDR Commands, describes the Unix scripts for specialized
RDR operations. For expert reference use only.
Appendix C, Glossary.
viii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR User Manual About this Manual
Document Conventions
The following conventions are used in this manual:
Table 1: Document conventions
Convention Indicates Example

Title case Checkboxes, window and Press Return to accept the
dialog box options, keyboard default option
keys, tab names
Bold and Title Window, dialog box, menu and On the Alarms menu…
Case command names, menu options
Courier Command line text, /opt/NMS/server/sql/
programming code sqlDump
Courier Bold Values to be entered in response Please select an
to screen prompts item ... [?,??,q]: 1
> Current menu option displaying On the Main menu bar, select
a submenu or leading to another Configuration > Create >
command; menu options to be Topology Link
selected in the indicated order
Italics New terms, emphasized text Build-as-you-grow™
architecture
Boxes around text Notes, cautions, warnings See examples below
Icons Used in text descriptions and Click to display the Find
procedures dialog box
>, #, ok Used in command line prompts Usage varies according to the
station mode (pre-boot=ok,
post-boot) and logged-in user
(root=#, enm=>)
NOTE: Clarifying information, specific instructions, commentary,

sidelights, or interesting points of information.
CAUTION: Failure to follow directions could result in damage to

equipment or loss of information.
WARNING: Failure to follow directions could result in bodily

harm or loss of life.
432006-2419-013-A00 ECI Telecom Ltd. Proprietary ix

Related Documentation
The following documents may be of assistance in RDR installation,
configuration, and activation processes:
EMS-XDM User Manual
EMS-SYNCOM User Manual
eNM LightSoft and LightSoft User Manuals
Obtaining Technical Documentation

To obtain technical documentation related to RDR or any other ECI Telecom
product, please contact:
ECI Telecom Ltd.
Optical Networks Division
Documentation Department
30 Hasivim St.
Petach Tikva 49130
Israel
Fax: 972-3-9268022
email: on.documentation@ecitele.com
Technical Assistance
The configuration and operation of RDR are highly specialized processes. If
you have questions or concerns about your network design or operation, the
services of ECI Telecom’s design engineers and highly trained field service
personnel are available to you at any time.
If you are interested in obtaining design assistance or a network installation
plan from ECI Telecom Customer Support team, contact your ECI Telecom
sales representative. With any support related issues, technical or logistic,
please contact the ECI Telecom Customer Support center at your location. If
you are not familiar with that location, you can contact our central customer
support center action line at:
Telephone + 972-3-9266000
Telefax + 972-3-9266370
Email on.support@ecitele.com
x ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR User Manual About this Manual
Your Opinion Is Very Important To Us

The Documentation Department at ECI Telecom's Optical Networks Division would like your
feedback on the quality and usefulness of this document. Your comments can be of great value in
helping us improve our documentation.
When you have completed this form, please fax it to: +972-3-9268060.
Product Name: Date:
Document Title: Name:
Document Number: Company:
Release Date: Email:
On a scale from 1 (poor) to 5 (excellent), rate the following:
1 2 3 4 5
Is the information clearly presented?
Was it easy to find the information you were looking for?
What is your overall assessment of this document?
Do you need more information? Yes No
If yes, please indicate the topic/s:
What features did you like most about this manual?
If you found errors or have any other suggestions for improving this document, please indicate the
topic, section, and page number below:
Please check the ways you feel we could improve this document:
Document organization Make it shorter
Table of contents Add more detail
Index Make it less/more technical
Include more figures Add more/better reference aids
Clearer procedures/instructions Other (please indicate):
Please add any other detail you would like to mention for improvement:
432006-2419-013-A00 ECI Telecom Ltd. Proprietary xi

xii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

1
1 Introduction
In This Chapter
Overview ..................................................................................................... 1-1
What is RDR?.............................................................................................. 1-2
Functional Description ................................................................................ 1-2
Typical RDR Configurations....................................................................... 1-7
Activation Overview.................................................................................. 1-12
Overview
This chapter provides a general description of RDR and functional descriptions
of its topological elements. Also included are typical configurations and an
overview of the current version's new features.
NOTE:
RDR supports the eNM LightSoft application as well as its later
version, LightSoft. In this manual, LightSoft may be used to denote
either of these applications.
LightSoft denotes the application running on LightSoft server
hosts, which maintain databases. This should not be confused with
the corresponding RDR instance (nms) – see Instances, page 1-4,
for information about RDR instances.
ems, enm, and nms are used to identify RDR instances, while
EMS-XDM, EMS-SYNCOM, and LightSoft are used to identify
the corresponding applications.
A configuration of an instance on a specific component is referred
to as a component instance. (In the RDR interface, “client” may be
used to denote a component instance.)
432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-1

Introduction RDR User Manual
What is RDR?
RDR is a tool that provides redundancy features for ECI Telecom's Optical
Networks Division’s management applications, including EMS-SYNCOM,
EMS-XDM, and LightSoft 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 site protection solution (primary and backup sites
connected via a long distance link), as well as a server (station) protection
solution (primary and mirror sites connected via LAN).
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 stations replacing failed
or deactivated primary components).
Components
RDR components provide the infrastructure for RDR backup and
synchronization functionality on servers. There are three types of component:
Primary: Administers RDR operations on the stations that normally
manage the network
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
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.
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,
page 1-4).
1-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR User Manual Introduction
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.
Primary stations generally invoke their backup sessions according to a
user-defined schedule.
The number of supported primary components and instances is limited only by
the overall backup server storage capacity - see Minimum Backup Server Disk
Capacity, page 2-2.
Backup components
A backup component is used to store replicas. It may either reside on a
dedicated station, or share a station with one of the mirror components.
RDR also supports multiple backup components, each instance on the primary
component configured to use a different RDR backup server.
Each configured instance in the primary host performs file transfers to replicas
on the backup server. Each regular backup session is performed to a sequential
replica (cyclic – incremental). The backup server therefore normally stores a
set number of last successful replicas.
The number of stored replicas per instance is configurable (see Replicas, page
1-5), and only limited by available disk capacity (see Minimum Backup Server
Disk Capacity, page 2-2).
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,
page 1-8.
Instances
RDR instances are sets of RDR-supported application data (specific application
settings) that each primary and mirror component is configured to maintain –
one per supported management application (EMS-SYNCOM, EMS-XDM,
and/or LightSoft, in any combination).
The application instances are identified by the following names (instance tags)
in RDR menus and scripts:
ems – EMS-XDM
enm – EMS-SYNCOM
nms – LightSoft
RDR instances are related to but conceptually distinct from the corresponding
applications running on a server.
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.

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.
From 2 to 5 full regular replicas can be configured for each primary component
instance (ems, enm, or nms), 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 Capacity, page 2-2).
For each primary component instance, backups can be scheduled to be
performed automatically at constant intervals (set time span between backups)
or nonconstant intervals (specific time on selected days of the week).
Replicas at constant intervals can be set to occur at very short intervals – as
frequently as every 5 minutes, according to user requirements. (Naturally, the
selected interval cannot be shorter than the time it takes to create a backup. In
this respect, nms instance backups provide great flexibility – see LightSoft
Instance Backup Levels, page 1-5.)
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.
LightSoft Instance Backup Levels

Backups of LightSoft instances (nms) can be configured at much shorter
intervals. This is because most nms backups are based on incremental changes
rather than full backups, so requiring far less processing time per backup and
less delay before each next backup can start.
The nms replication scheme defines three nested backup levels:
Level 0 (L0) full regular replicas (up to 5 can be defined), similar to ems or
enm regular replicas
Level 1 (L1) incremental backups (up to 3 can be defined), recording
changes since the immediately preceding L0 full backup was performed

Level 2 (L2) incremental backups (up to 5 can be defined), recording

changes since the immediately preceding L1 backup was performed
Like ems or enm recovery, nms recovery is based on a choice of up to five full
cyclical backups (L0 backups). But the L0 backup is also continuously updated
with latest associated L1 and L2 incremental changes.
The levels are configured for each primary component instance during the
primary component configuration procedure (see Configuring Primary
Components, page 4-3).
The following diagram shows an example of a sequence of backups performed
over time for a selected primary component instance, and the implications for
recovery:
L0 1 L0 11
L1 2 L1 5 L1 8
L2 3 L2 4 L2 6 L2 7 L2 9 L2 10
Figure 1-1: Sequence of LightSoft instance backups over time
(Levels configuration for this example is set to L1=2 and L2=2. The subscripts
beside the entries denote a backup's point in time. For example, the top leftmost
L0 backup was performed at Time1. The backups are spaced according to
user-specified intervals.)
At Time1 a full backup is created (L01).
Reconstituting the database between Time1 and Time2 requires restoring
from the full backup L01.
At Time2 an intermediate backup of differences between Time1 and Time2
is created (L12).
the L01 full backup, supplemented by the L12 difference.
At Time3, an intermediate backup of differences between Time2 and
Time3 is created (L23).
the L01 full backup, supplemented by both the L12 difference plus the L23
difference.


Time4 is created (L24). (Notice that this spans two intervals.)
the L01 full backup, supplemented by the L12 difference plus the L24
difference. (The previous L23 difference is no longer relevant.)
Time5 is created (L15). (Notice that this spans four intervals.)
the L01 full backup, supplemented by only the L15 difference. (The
previous L24 difference is no longer relevant.)
At Time6 through Time10, similar incremental backups are performed,
with recovery requiring a combination of the L0 full backup and relevant
intermediate L1 and L2 backups.
At Time11, a new full backup is created (L011), starting a new cycle.
Any combination of L1 and L2 intermediate backups may be defined. The
greater their number (maximum L1=3 and L2=5), and the shorter the selected
interval (as short as 5 minutes between backups depending on database size),
the more up-to-date the latest backup will be.
Typical RDR Configurations

The following sections describe a few of possible RDR configurations. RDR
flexibly enables a wide variety of topologies according to the required
protection level, geographic distribution of infrastructure, and equipment
budget.
NOTE:
For convenience, servers are generally referred to in procedures by

their host names. For example, in this manual the server containing
a primary component is called MainComp. (Multiple primary
servers may be called MainComp1, MainComp2, and so on.)
Similarly, separate backup and mirror servers might be called

BackupComp and MirrorComp, respectively.
The examples in this manual are primarily based on a backup and a

mirror component that share the same server, named StandbyComp.
The procedures can be adapted to any topology by substituting the
applicable host names.
The IP addresses corresponding to named hosts are identified in the

/etc/hosts file.

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 (see next section), the backup site’s hardware must be
at least as large as the largest primary site being backed up.
Shadow backup server

A shadow backup server is a clone of an RDR backup server that maintains a
copy of the replicas contained in the RDR backup server. Its purpose is to grant
higher redundancy to the RDR backup system. One shadow backup can support
multiple backup servers.
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:1 configuration
The following shows a 1:1 configuration with a dedicated mirror host for each
primary host.
Figure 1-2: Simple configuration example – 1:1
In this example, the backup and mirror components share a common host.

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-XDM as a slave manager.
Figure 1-3: 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.
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-4: 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.
EMS-SYNCOM or EMS-XDM Configurations

The primary and backup/mirror sites will usually each have their own set of
gateway NEs (which may be shared by both sites), although this is not
required.
X-terminals 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.
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.
Activation Overview
Backup Session
The RDR implementation is based on replication of a supported application’s
database from a primary component to the backup component.
The primary station can be set to automatically invoke backup sessions at
prescheduled times. These regular replicas are stored cyclically on the backup
component. Archive backups, that are not overwritten, can also be configured
for each instance.
The backup scheme utilizes a local cache to eliminate communications link
bottlenecks. Synchronization is performed in two stages:
From the application store to the local cache
From the local cache to the backup server
The local cache location on the primary host is configurable for each
application, enabling RDR to use available disk space on the host in the most
efficient way.

The general replication scheme is shown in the following figure.
Figure 1-5: General replication scheme
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 main steps:
1. Restore a replica, as follows:
a. Select a primary component and instance.
b. Select the required replica.
c. Restore the replica to the mirror component.
2. 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.
3. Start the application on the mirror component.

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 free the mirror component to handle any other potential failure.)
This process involves the following main steps:
1. Since LightSoft and EMS databases are usually unsynchronized after a
restore from mirror to primary, a reverse update procedure is used 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.
3. Resume work as usual. The mirror site returns to standby mode.

2
2 Preliminary Requirements
In This Chapter
Overview ....................................................................................................... 2-1
Application Requirements ............................................................................. 2-1
Minimum Backup Server Disk Capacity....................................................... 2-2
Communications and Bandwidth Requirements ........................................... 2-3
Overview
This chapter describes the preconditions for successful installation. It also
provides an overview of the workflow for component configuration detailed in
subsequent chapters.
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.
Application Requirements
The following products, versions, and configurations are supported:
EMS-SYNCOM v.1 and later – standalone and integrated
EMS-XDM v.3 and later – standalone and integrated
eNM LightSoft/LightSoft server
NOTE: RDR can also be used in networks that include other EMS
types such as BroadGate™ and µLAN. In these cases, the EMSs
are not backed up by RDR but rather deployed in parallel in both
the primary and backup sites.

Preliminary Requirements RDR User Manual
Application Requirements for Mirror Stations

Each station to be configured as a mirror station must meet the following
application requirements:
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)
Minimum Backup Server Disk Capacity

The number of replicas that are stored is configurable (see Replicas, page 1-5),
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)
+ NPDB * (1.5*NNR +1)
where
EPDBi = size of each primary component ems or enm database
ENRi = number (from 2 to 5) of regular replicas of each primary
component ems or enm instance (plus 1 for the archive replica)
NPDB = size of the primary component nms database
NNR = number (from 2 to 5) of level 0 regular replicas of the primary
component nms instance (plus 1 for the archive replica)
For EPDB and NPDB, use the actual instance database sizes, or estimate the
required capacity as follows:
For each XDM network element – minimum capacity per replica:
Estimate 50 MB for backup initiated from EMS-XDM
Estimate 60 MB for backup initiated from LightSoft
For each SYNCOM network element – minimum capacity per replica:
Estimate 5 MB for backup initiated from EMS-SYNCOM or LightSoft
Be sure to include sufficient additional capacity for network growth.

RDR User Manual Preliminary Requirements
NOTE: Due to partition (/sdh_home) considerations, effective free

disk size is 3.5 GB for a 9 GB disk, 9.1 GB for an 18 GB disk, 26
GB for a 36 GB disk, and 60 GB for a 73 GB disk. (When the
backup component is installed on a dedicated server, the difference
between free and effective disk size can be 3 GB or less.)
Communications and Bandwidth

Requirements
RDR operation requires the following conditions:
Appropriate network communication configurations on all components
(primary, backup server, and mirror), enabling valid network routing
between sites
2 Mbps minimum link bandwidth between components (assuming replicas
are scheduled on a staggered basis to avoid overlap)

Preliminary Requirements RDR User Manual

3
3 RDR Menus
In This Chapter
Overview ..................................................................................................... 3-1
RDR Main Menu ......................................................................................... 3-1
RDR Configuration Menu ........................................................................... 3-3
RDR Utilities/Actions Menu ....................................................................... 3-4
Overview
This chapter describes some principal menus used by the configuration and
activation procedures in this manual.
NOTE: The menu illustrations and procedures primarily relate to

V 3.5. Differences with previous RDR versions are noted where
applicable.
RDR Main Menu

The RDR Main menu is the principal menu for accessing RDR functionality
for the current host.

RDR Menus RDR User Manual
To access the RDR Main menu:

Log in as a root user and start the primary RDR component configuration
session by entering RDR. The RDR Main menu appears.
# RDR
***********************************************************
* *
* **** **** **** ***** ***** *
* * * * * * * * * *
* * * * * * * ** **** *
* **** * * **** * * *
* * * * * * * * * * *
* * * **** * * *** * **** *
* *
* Remote Data Replicator Command Center ver. 35.10 *
* *
* Network Management Division *
* ECI Telecom Ltd. *
***********************************************************
RDR Components on MainComp: NOT configured yet.
RDR host "MainComp" Main Menu

___________________________
1 Configuration Menu
2 RDR Utilities/Actions Menu
3 Show RDR Components Status
4 About RDR
Please select an item (q for exit) ... [?,??,q]:
The RDR Main menu contains the following options:

Menu option Description
Configuration Configures RDR components (primary, backup, and mirror) on
Menu the current host with the required instances (ems, enm, and/or
nms), as well as the required alarms messaging and diagnostics
mode setup.
RDR Used to perform a variety of component instance activation
Utilities/Actions functions, such as starting backup, synchronization, or update
Menu sessions.
Show RDR Displays RDR configuration summary.
Components
Status
About RDR Provides RDR version information.
NOTE: If you are using a previous RDR version, the Configure

Alarms Notification option is also included here. (In RDR V 3.5, it
is in the RDR Configuration menu.)

RDR User Manual RDR Menus
RDR Configuration Menu

The RDR Configuration menu is used to configure RDR components
(primary, backup, and mirror) on the current host with the required instances
(ems, enm, and/or nms), as well as the required alarms messaging and
diagnostics mode setup.
To access the RDR Configuration menu:

On the RDR Main menu, select RDR Configuration Menu. The RDR
Configuration menu appears.
RDR Configuration Menu (host - MainComp)
________________________________________
1 Configure RDR Primary Component

2 Configure RDR Backup Server
3 Configure RDR Mirror Component
4 Unconfigure RDR Instance/Component(s)
5 Configure Alarms Notification
6 Toggle RDR CC Diag Mode
q Return to Main Menu
Please select an item ... [?,??,q]:
The RDR Configuration menu contains the following options:

Configure RDR Primary Configures primary component settings.
Component
Configure RDR Backup Configures backup server component settings.
Server
Configure RDR Mirror Configures mirror component settings.
Component
Unconfigure RDR Clears the current component settings.
Instance/Component(s)
Configure Alarms Configures alarms messaging.
Notification
Toggle RDR CC Diag Activates the “diag” mode, creating a log file with the
Mode following information for problem diagnostics:
Displays system information, such as HostInfo,
memconf, and networking
Logs all configuration activities

RDR Utilities/Actions Menu

The RDR Utilities/Actions menu is used to perform a variety of component
instance activation functions, such as starting backup, synchronization, or
update sessions. The menu options can be used only after the relevant system
components have been configured.
To access the RDR Utilities/Actions menu:

1. On the RDR Main menu, select RDR Utilities/Actions Menu. The RDR
Instances Available menu appears.
RDR instances available on "MainComp":
____________________________________________
1 common General Primary Actions

2 ems XDM Element Manager
3 enm eNM / Syncom Element Manager
4 nms NMS (LightSoft eNM) Server
Please select an instance ... [?,??,q]: 2
2. Select the required option - generally an instance (ems, enm, or nms). Only
the instances that have been configured for the component are shown.
(The common option is relevant only for special purpose procedures that
are described in context, as required.)
The corresponding Actions menu appears.
EMS-XDM Actions Menu

__________________________________
1 Start Regular Backup Session

2 Start Archive Backup Session
3 Perform Full Synchronization
4 Start Reverse Update Session
5 Set Scheduler Configuration
6 Start Local Backup session
7 Start Local Restore session
Please select an action ... [?,??,q]: 1

RDR User Manual RDR Menus
This menu contains the following options:

Start Regular Backup Starts a manually initiated backup session (in addition to
Session any scheduled automatic backups).
Start Archive Backup Creates a static archive backup (that is not overwritten by
Session any scheduled or regular backups).
Perform Full Fills all the full regular replicas (see Replicas, page 1-5)
Synchronization configured for a specified EMS-XDM and EMS-SYNCOM
instance, one after the other, without regard to scheduling.
This action is performed once, after first configuration, and
is relevant only for EMS instances. For a LightSoft
instance, fills only the first L0 replica (see LightSoft
Instance Backup Levels, page 1-5) in the same way as a
regular backup.
Start Reverse Update Updates the primary component instance from the mirror
Session component instance after mirror activation, and returns
control to the primary component.
Set Scheduler Enables configuring rules for automatic periodic backup
Configuration generation.
Start Local Backup Creates a backup on the local component (before upgrade).
Session
Start Local Restore Restores a backup to the local component.
Session


4
4 Configuring Primary
Components
In This Chapter
Overview ....................................................................................................... 4-1
Configuration Workflow ............................................................................... 4-2
Configuring Primary Components................................................................. 4-3
Configuring the Display of Messages............................................................ 4-8
Overview
This chapter provides an overview of the workflow for component
configuration detailed in this and subsequent chapters.
It then describes how to configure the primary components of the system to
enable replication of instances (ems, enm, and/or nms) with RDR. You can also
optionally configure messages to appear on specified displays of the system
infrastructure.
NOTE: Backup server configuration must be completed (see Chapter

5, Configuring Backup Components) before activating a primary
component (see Chapter 7, Creating and Scheduling Backups of
Primary Component Instances).
The configuration procedure assumes that the system has already been prepared
and installed in the relevant stations, as described in Chapter 2, Preliminary
Requirements.
The examples provided relate primarily to ems screens and scripts. The enm or
nms screens and scripts are very similar. Any significant differences are noted.

Configuring Primary Components RDR User Manual
Configuration Workflow
After installing RDR on all relevant hosts, each RDR component – primary,
backup and mirror – must be configured as described in Chapters 4, 5, and 6.
It is recommended that you test the backup configuration directly after
configuring the primary and backup components. You do this by performing an
initial manual backup and scheduling automatic backup sessions at set intervals
(see Chapter 7, Creating and Scheduling Backups of Primary Component
Instances).
The mirror component configuration may be postponed until mirror
functionality is required.
The following is an overview of the steps leading to activation of the primary,
backup, and mirror components:
1. Ensure that the preliminary requirements for installation described in this
chapter are fulfilled. RDR is installed on all relevant stations by ECI
Telecom’s support staff.
2. Configure the primary components – see Chapter 4, Configuring Primary
Components.
3. Configure the backup servers – see Chapter 5, Configuring Backup
Components.
4. Perform backups to test the replication process (recommended) – see
Instances:
a. Use the Full Synchronization function (see page 3-5) to fill all the full
regular replicas configured for each primary component EMS instance
(see Replicas, page 1-5), or the first L0 replica of a LightSoft instance
(see LightSoft Instance Backup Levels, page 1-5).
b. Schedule automatic backup sessions (set interval).
5. Configure a mirror component – see Chapter 6, Configuring Mirror
Components.
6. Configure a shadow backup component if required – see Chapter 5,
Configuring Backup Components.
NOTES:
Not all commands may be supported by previous RDR versions.
Messages displayed on screens may differ slightly from those
illustrated in this manual.

RDR User Manual Configuring Primary Components
Configuring Primary Components

This section describes how to configure a primary component in the system
with RDR instances - ems, enm, or nms.
The examples show a topology where three instances are configured on the
same primary component deployed on a single host (called MainComp).
However, instances can be deployed in any combination on any number of
dedicated primary servers. (For information about hostnames, see the note in
Typical RDR Configurations, page 1-7.)
To configure the primary components:

1. Log in as a root user.
2. On the RDR Configuration menu, select Configure RDR Primary
Component. The Configure RDR Primary Component menu appears.
Configure RDR Primary Component on "MainComp"
RDR instances to be configured on "MainComp":

____________________________________________

Please select an instance to configure ( q for exit )... [?,??,q]:

1
3. Select a required instance – ems, enm or nms. (The screen examples are
specific to ems. The screens that you will encounter for enm or nms are
essentially the same; any major differences are described in the text.)
4. A prompt for Cache Folder path appears. Press Enter to accept the default.
Configure instance "ems" on MainComp:
ems -> Enter Cache Folder path on MainComp [

default=/sdh_home/RDR.CACHE ] [?] [Enter]
5. A prompt for the backup server name appears. Enter it as required.

(Mandatory – no default is provided.)
ems -> Enter backup server name or IP [?] StandbyComp
6. A prompt for the backup directory path appears. Press Enter to accept the
default.
ems -> Enter backup dir path on StandbyComp [
default=/sdh_home/Replica ]
[?] [Enter]

7. A prompt for the primary host name appears.

ems -> Enter Primary Host name or IP [ default=MainComp ] [?]
Enter the name of the primary component. If the primary component has
several network adapters, choose the name of the network interface
connected to the backup server.
8. A prompt for the number of regular replicas appears.

ems -> Enter number of regular replicas on StandbyComp [ default=2
] [2-5,?] 3
Choose the number of replicas according to the desired reliability level and
existing disk capacity. For more details, see Replicas, page 1-5.
9. (nms only)
Prompts for the number of backups during the database backup cycle at
level 1 and level 2 appear. Press Enter to accept the defaults.
nms -> Number of level 1 backups during DB backup cycle [
default=2 ] [1-3,?] [Enter]
nms -> Number of level 2 backups during DB backup cycle [

default=3 ] [1-5,?] [Enter]
Level 1 is an incremental backup from Level 0 - the full regular backup

dealt with in step 8. Level 2 is an incremental backup from the previous
Level 1. For more details about LightSoft levels, see LightSoft Instance
Backup Levels, page 1-5.
10. The parameters that you entered appear. Enter y to apply the parameters.
--- Configuration parameters ---
Common RDR parameters (instance "ems"):

_____________________________________
Primary Master Host: MainComp

Cache Directory: /sdh_home/RDR.CACHE
Backup Server: StandbyComp
Backup Directory: /sdh_home/Replica
Number of regular replicas: 3
Do you want to apply these parameters? y
Backup server registration is performed.
Check backup server connectivity -- MainComp -> 147.234.144.30 ...

OK
Creating Instance Configuration File... OK
Transferring configuration data to StandbyComp ... OK

At the end of the process, the Configure RDR Primary Component menu
reappears.

____________________________________________


2
11. Repeat steps 3 to 10 to configure every required primary instance.

12. When you have completed configuring primary instances, enter q or press
Enter at successive prompts to redisplay the RDR Main menu. (The next
section is a reminder of subsequent steps in the configuration process,
detailed in chapter 6.)
____________________________________________


q
*****************************************************************
*
* Primary RDR component on "MainComp" configured.
*
* Next steps:
*
* 1. Configure backup server on "StandbyComp"
* 2. Perform Test Synchronization "MainComp"
* 3. Run /opt/RDR/bin/SetCronRDR to schedule automatic
replications
*
* Prompt: Use <RDR> to launch RDR Command Center.
*
*****************************************************************
Press Return to continue...
RDR Configuration Menu (host - MainComp)

________________________________________
1 Configure RDR Primary Component

2 Configure RDR Backup Server
3 Configure RDR Mirror Component
4 Unconfigure RDR Instance/Component(s)
6 Toggle RDR CC Diag Mode
Please select an item ... [?,??,q]: q

13. On the RDR Main menu, select Show RDR Components Status.
___________________________
4 About RDR
Please select an item (q for exit) ... [?,??,q]: 3
The following information window shows the configuration settings for the
primary components.

5 About RDR
RDR Components on MainComp: Primary
A. Primary component data:

_________________________
RDR activation status: Active
RDR instance "enm":

----------------------------------------------
----------------------------------------------
RDR instance "ems":
----------------------------------------------
----------------------------------------------
RDR instance "nms":
----------------------------------------------
Specific instance nms parameters :

_____________________________________
Number of level 1 backups: 2

Number of level 2 backups: 3
Backup Cycle counter status: none
----------------------------------------------
RDR crontab entries on :
--------------------------------------
0 0,12 * * * /opt/RDR/bin/SyncMaster -t enm >>
/var/tmp/RDR.log.enm
0 0,12 * * * /opt/RDR/bin/SyncMaster -t nms -np -- -a >>
/var/tmp/RDR.log.nms
14. Press Enter or enter q at successive prompts to redisplay the main menu.
Please select an item (q for exit) ... [?,??,q]: q
15. Use the Full Synchronization function (see page 3-5) to fill all the full
regular replicas configured for each primary component EMS instance (see
Replicas, page 1-5), or the first L0 replica of a LightSoft instance (see
LightSoft Instance Backup Levels, page 1-5).

Configuring the Display of Messages

Warning/error messages are shown by default on all connected displays,
excluding specific displays. Earlier RDR versions before V 3.22 display
messages only on the primary component console.
The administrator can also configure that messages appear on specific displays.
To configure messages to appear in specified displays:

2. On the RDR Configuration menu, select Configure Alarms Notification.
The RDR Alarm Display Editor menu appears.
RDR Alarm Display Editor – Main Menu

_____________________________________
1 Add a Display Rule

2 Remove a Display Rule
3 Show Displays Rules
4 Restore Defaults
NOTE: If you are using a previous RDR version, select Configure

Alarms Notification on the RDR Main menu.
3. Select Add a Display Rule. The following menu appears.

Please select an item (q for exit) ... [?,??,q]: 1 (Add a
display rule)
Add Display Rules Menu

_______________________
1 Enable "All-Displays"
2 Enable "All-Xterminal-Displays"
3 Enable "All-GO-Global-Displays"
4 Enable specific display ( of Xterminal )


Enable All-Displays Displays messages to all active users.
(All-Displays)
Enable All-Xterminal-Displays Displays messages to all X-terminal users
(All-Xterm) (not GO-Global/xRMS).
Enable All-GO-Global-Displays Displays messages to all GO-Global/xRMS
(All-GO-Global) users (not X-terminal).
Enable specific display Displays messages to specific (one or more)
(Specific) X-terminals. At the prompt, specify the host
name or IP address of a required terminal.
(Only hostnames that are preconfigured in the
/etc/hosts are valid.)
4. Enter the required options, one after the other (any combination is valid).
The menu reappears after each selection.
The following interdependencies apply:
All-Displays
Condition Action Result
When All-Displays is selected N/A All-Xterm
and All GO-Global are
automatically enabled
All-Xterm and All-GO-Global

And you then
enable
All-Displays All-Xterm and/or
If All-Xterm and/or
All-GO-Global
All-GO-Global are enabled And you then remain enabled
disable
All-Displays
And you then All-Xterm and/or
enable All-GO-Global
If All-Xterm and/or All-Displays become enabled
All-GO-Global are disabled And you then All-Xterm and/or
disable All-GO-Global
All-Displays become disabled
(For details about disabling displays, see step 4.)

Specific Display
Condition Action Result*
And you then
If Specific was used to enable a enable All-Xterm The specific display
specific display And you then remains enabled
disable All-Xterm
And you then
If Specific was used to disable enable All-Xterm The specific display
a specific display And you then becomes enabled
disable All-Xterm
* The display does not need to have an open session with the primary component. It is
sufficient that it runs X-server.
If you are using RDR V 3.22, the following specific display

interdependencies apply instead:
And you then The specific display
If Specific was used to enable a enable All-Xterm remains enabled*
specific display And you then The specific display
disable All-Xterm remains enabled
And you then The specific display
If Specific was used to disable enable All-Xterm becomes enabled*
a specific display And you then The specific display
disable All-Xterm becomes disabled
* This behavior applies only for an X-terminal that has an open session with the
primary component. Otherwise, enabling All-Displays or All-Xterm disables the
specific display.
NOTES:
A station that is not a remote display of the primary RDR
component (for example, a dedicated Sun station installed with
LightSoft client), requires a specific display setup.
X-Terminals should be defined in the /etc/hosts file.
5. When no more Enable actions are required, enter q to redisplay the RDR
Alarm Display Editor menu.

6. To disable displays from receiving messages, on the RDR Alarm Display

Editor menu (see step 2), select Remove a Display Rule. The following
menu appears:
Remove Display Rules Menu
__________________________
1 Disable "All-Displays"
2 Disable "All-Xterminal-Displays"
3 Disable "All-GO-Global-Displays"
4 Disable specific display ( of Xterminal )
5 Remove all Rules ( only console enabled )

Disable functions Disable messages on displays. Functions like the enable

option in step 3 enables messages.
Remove all Rules Prevents messages from appearing on all displays. Messages
appear only on the primary station console.
7. To configure RDR to display messages on all active sessions, on the RDR

Alarm Display Editor menu (see step 2), select Restore Defaults.
8. To view your selections, on the RDR Alarm Display Editor menu (see
step 2), select Show Display Rules. A list of the currently defined rules
appears.


5
5 Configuring Backup
Components
In This Chapter
Overview ....................................................................................................... 5-1
Configuring the Backup Server ..................................................................... 5-2
Viewing Instance and Replica Status ............................................................ 5-5
Testing the Backup Configuration................................................................. 5-6
Configuring a Shadow Backup Server .......................................................... 5-6
Overview
This chapter describes how to configure backup components to act as
repositories for RDR replicas. You can also view the status of all primary
component instances (configured or pending), and details of replicas that were
created for various configured instances on the backup server.
Requirements.
Directly after configuring the primary and backup components, it is
recommended to test the backup configuration by performing an initial manual
backup and by scheduling automatic backup sessions at set intervals (see
Instances).
The mirror component configuration may be postponed until mirror
functionality is required.

Configuring Backup Components RDR User Manual
Configuring the Backup Server

This section describes how to configure the backup server to accommodate
replicas of ems, enm, and/or nms instances, as required.
The examples show a topology where the backup component is deployed on
the same host as a mirror component (named StandbyComp). Backup
components can also be deployed on dedicated servers. (For information about
hostnames, see the note in Typical RDR Configurations, page 1-7.)
To configure the backup server:

2. On the RDR Configuration menu, select Configure RDR Backup
Server.
3. When configuring a dedicated backup server (not an EMS or LightSoft
station), if the backup server was not previously configured with Unix ems,
enm, or nms users, you are prompted to confirm the creation of the Unix
user environments.
Do you want to install enm user on local databases [y,n,?] y
Creating user enm...OK
Do you want to install ems user on local databases [y,n,?] y

Creating user ems...OK
Do you want to install nms user on local databases [y,n,?] y

Creating user enm...OK
Checking environment ... OK
Configuring RDR Backup server ...
4. At the end of the process, the Backup Server Configuration menu

appears.
Backup Server "StandbyComp" Configuration Menu
===========================================
1 Add Backup Client

2 Remove Backup Client
3 Unconfigure Backup Server
4 Show Backup Server Configuration
Please select an item ... [?,??,q]:

RDR User Manual Configuring Backup Components

Add Backup Client Adds previously configured primary component instances
to the backup server.
Remove Backup Removes an existing instance from the backup server.
Client
Unconfigure Backup Removes the backup server configuration from the host.
Server (You should first remove all the backup clients.)
Show Backup Server Displays the current backup server configuration (both
Configuration configured and pending instances).
5. Select Add Backup Client.

===========================================
1 Add Backup Client

Please select an item ... [?,??,q]: 1
A list of all configured primary component instances not yet assigned to a

backup component appears.
Set Backup Client to Configure:

=========================
1 MainComp ems
2 MainComp enm
3 MainComp nms
Please select a host... [?,??,q]: 1
6. Select a required instance (for example, select MainComp ems).

The Backup Server Configuration menu reappears.
Creating replica folders for MainComp...Done.

Re-configuring rsync server...Done.

===========================================
1 Add Backup Client


7. Select Add Backup Client again.

The Set Backup Client to Configure menu reappears showing the
remaining, not yet selected, instances.
Set Backup Client to Configure:

=========================
2 MainComp enm
3 MainComp nms
Please select a host... [?,??,q]: 2
8. Repeat steps 6 and 7 until all the required instances have been selected.
Then enter q.
NOTE: If the backup server and mirror component share the same
host, you can configure the mirror component immediately after the
backup component is configured (see Chapter 6, Configuring Mirror
Components).

Viewing Instance and Replica Status

You can view the status of all primary component instances (either configured
or pending), and details of replicas that were created for various configured
instances on the backup server.
To view primary component instance and replica status:

1. On the Backup Server Configuration menu (see page 5-2), select Show
Backup Server Configuration. The status of all primary component
instances (either configured or pending) appears.
===========================================
1 Add Backup Client

Backup Server "StandbyComp" current status:

_________________________________________________
Configured backup clients:

_________________________________
client inst backup folder status
MainComp ems /sdh_home/Replica configured

MainComp enm /sdh_home/Replica configured
MainComp nms /sdh_home/Replica configured
No unconfigured clients found
2. A prompt follows enabling viewing details of replicas (if any) created from
instances configured on the backup server. Enter y to view replica status.
Do you want to see Replica status? y
Replicas status on StandbyComp:

_________________________________
Primary host "MainComp", instance "enm":
1 2005/01/06 12:52:06 enm MainComp
Primary host "MainComp", instance "nms":
2 2005/01/06 12:53:18 nms MainComp

If no replicas are found (for example, when the backup server has just been
configured and not yet activated), the following appears:
WARNING! No valid backups found
NOTE: This step applies only to RDR V 3.5.
Testing the Backup Configuration

It is recommended to test the configuration and replication process by creating
and scheduling replicas.
This procedure is required prior to configuring a shadow backup server, to
provide the data necessary to form a shadow replica.
To test the backup configuration:

1. Perform an initial manual backup of each instance – see Creating Regular
or Archive Backups, page 7-2.
2. Schedule automatic backup sessions (set backup interval) – see Defining
Backup Schedules, page 7-3.
Configuring a Shadow Backup Server

A shadow server is a clone of the RDR backup server used to provide higher
redundancy to the RDR backup system.
The RDR shadow component is configured from the RDR backup server using
the SyncShadow utility.
NOTES:
Configure the shadow backup server only after performing an
initial manual backup of each instance to test the replication
process (see Chapter 7, Creating and Scheduling Backups of
Primary Component Instances). This provides the backup data
necessary to form a shadow replica.
It is recommended to postpone shadow backup configuration
until all basic components (including mirror components) have
been configured.
SyncShadow is not available in previous RDR versions.

The SyncShadow utility has the following usage parameters and options:
Usage: SyncShadow [-s|-shadow shadow_server] [-c|-config] [-u|-unconfig]
[-dd debug_level] [-help]
Options:
-s | -shadow Synchronize the specified shadow component
-c | -configure Configure this host as a shadow component
-u | -unconfigure Remove the shadow component configuration from this host
-dd level Specify debug level (for troubleshooting only)
-h | -help Display the Usage and Options details shown here
To configure a shadow server:

2. Configure the shadow server, as follows:
a. Run the following command:
SyncShadow -config
b. When processing is completed, press Enter.

Configuring ShadowComp as RDR Shadow Server:
-
Enter the Replica folder name for shadow

[default=/sdh_home/Replica]: [?] [Enter]
3. Synchronize the shadow server by running the following command:

SyncShadow -s ShadowComp
where ShadowComp is the name or IP of the Shadow component.
NOTE: It is recommended that you add this command to the cron

mechanism (using the SetCron utility).
4. Remove the host’s shadow component configuration by running the

following command:
SyncShadow -unconfig
NOTE: Do not forget to remove the crontab entry from the backup
server (see Action List menu in To define a backup schedule, page
7-4).
The station is now ready to act as an RDR shadow server.


6
6 Configuring Mirror
Components
In This Chapter
Overview ....................................................................................................... 6-1
Configuring the Mirror Component............................................................... 6-1
Reconfiguring the Mirror Component ........................................................... 6-3
Application Auto Start................................................................................... 6-3
Overview
This chapter describes how to configure the mirror components of the system
to recover from a selected backup host in the event of a primary failure. (The
specific instance and replica on that host is selected when the mirror is
activated – see Chapter 8, Recovering to a Mirror Component.)
Requirements.
Configuring the Mirror Component

This chapter describes how to configure a mirror component to restore replicas.
The examples show a topology where the mirror component is deployed on the
same host as a backup component (named StandbyComp). Mirror components
can also be deployed on dedicated servers. (For information about hostnames,
see the note in Typical RDR Configurations, page 1-7.)

Configuring Mirror Components RDR User Manual
NOTE: The mirror component can be configured for only one

backup server at a time. Before the mirror can be activated from a
replica on a different backup server, it must be reconfigured (see
Reconfiguring the Mirror Component, page 6-3).
To configure the mirror component:

2. On the RDR Configuration menu, select Configure RDR Mirror
Component.
3. A prompt for the default backup server host for this mirror component
appears. You can specify any backup server (including a shadow backup
server).
MIRROR -> Enter default Backup Server name or IP [?] StandbyComp
RDR Mirror parameters assumed (host "StandbyComp"):

___________________________________________
Default Backup Server: StandbyComp
Do you want to apply these parameters? y
4. A prompt to confirm the default backup server host appears. Enter y.

5. The mirror component is configured. Press Enter to continue.
Check backup server connectivity -- StandbyComp -> 147.234.144.30
... OK
Creating Instance Configuration File... OK

_____________________________________________________________
Mirror RDR component on "StandbyComp" configured.

Run RestartMirror to initiate RDR recovery procedure
Prompt: Use <RDR> to launch RDR Command Center.
_____________________________________________________________
6. The RDR Configuration menu reappears. Enter q in successive prompts to

return to the main menu.
RDR Configuration Menu (host - StandbyComp)
RDR host "StandbyComp" Main Menu

RDR User Manual Configuring Mirror Components
Reconfiguring the Mirror Component

The mirror can be configured for only one backup server at a time. If the
replicas of primary component instances are distributed on more than one
backup server and the mirror is already configured for one of them, the mirror
must first be reconfigured for the different backup server before it can be
activated from a replica on it.
NOTE: The Unconfigure option used in this procedure erases any

existing configuration.
To reconfigure the mirror component:

2. On the RDR Configuration menu, select Unconfigure RDR
Instance/Component(s).
3. Configure the mirror component as required (see Configuring the Mirror
Component, page 6-1).
Application Auto Start

The Application Auto Start feature available in later RDR versions causes the
application to automatically start up when the station starts. This functionality
can be disabled or enabled again.
To disable application auto startup:

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 V10.100 or later)
touch /etc/.NO_XDM_AUTO_START (EMS-XDM V5 or later)

Configuring Mirror Components RDR User Manual
To enable application auto startup:

To enable automatic startup after disabling it, remove 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.)
rm /etc/.NO_NMS_AUTO_START (Any NMS)
rm /etc/.NO_SYN_AUTO_START (EMS-Syncom V10.100 or later)
rm /etc/.NO_XDM_AUTO_START (EMS-XDM V5 or later)

7
7 Creating and Scheduling
Backups of Primary
Component Instances
In This Chapter
Overview .......................................................................................................7-1
Creating Regular or Archive Backups...........................................................7-2
Defining Backup Schedules...........................................................................7-3
Viewing crontab Entries ................................................................................7-8
Overview
This chapter describes how to create or schedule regular backups or static
archives, and view crontab entries.
The backup server configuration must be completed (see Chapter 5,
Configuring Backup Components) before activating a primary component.
NOTE: Large automatic database backups are system affecting.

They take time and heavily load the system. You can avoid network
congestion by assigning appropriate offsets to each instance’s
replication sessions, so they do not run at the same time.

Creating and Scheduling Backups of RDR User Manual
Primary Component Instances
Creating Regular or Archive Backups

This section describes how to create regular or archive replicas of selected
primary component instances (ems, enm, or nms).
The latest regular replica overwrites the currently oldest backup on a cyclical
basis (the cycle consists of 2 to 5 full regular replicas, according to backup
server configuration). An archive replica that is not automatically overwritten
can also be created for each primary component instance. An archive replica is
a static backup at a specific time, used to freeze the system state on the backup
server.
Recovery can be performed from any cyclical or archive replica.
NOTE: Archive replicas occupy valuable disk space. Use them only
when necessary.
To create a regular or archive backup:

1. Access the RDR Utilities/Actions Menu for a required instance (select
ems, enm, or nms in the RDR Instances Available menu). For details, see
RDR Utilities/Actions Menu, page 3-4.
In the corresponding Actions menu, select:
Start Regular Backup Session to create a regular backup.

(Use the Full Synchronization function the first time backups are
created following initial component configuration - see page 3-5.)
OR
Start Archive Backup Session to create an archive backup.
2. The backup is implemented and scripts similar to the following appear.
Press Enter to continue, as required.
ems and enm
Tue Aug 6 16:49:02 IST 2013 Start instance "enm" cache backup
Exit Code: 0
Tue Aug 6 16:49:03 IST 2013 End of instance "enm" cache backup.
Tue Aug 6 16:49:07 IST 2013 MainComp -> StandbyComp enm (replica
- 1) ... OK

RDR User Manual Creating and Scheduling Backups of
nms
Tue Aug 6 16:49:43 IST 2013 Start instance "nms" level 0

backup...
VERSANT Utility VBACKUP Version 6.0.5.1

Copyright (c) 1989-2002 VERSANT Corporation
Backing up database `nms_db' to device

`/sdh_home/RDR.CACHE/nms/level0/nms_db':
0% 50% 100%
| | | | |
........................................
Backup has completed successfully.

Exit_Status 0
Tue Aug 6 16:49:47 IST 2013 End of instance "nms" backup.

Tue Aug 6 16:49:51 IST 2013 MainComp -> StandbyComp nms (replica
- 3) ... OK
At the end of processing, the Actions menu reappears.
Please select an action ... [?,??,q]: q
3. Enter q to quit. The RDR Main menu reappears.


#
4. If required, repeat steps 2 to 4 to back up another instance. Else enter q

again to exit RDR.
Defining Backup Schedules

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 nonconstant (specific time on one or more days of the
week).
Replicas at constant intervals can be set to occur as little as 5 minutes apart.
The selected interval cannot be shorter than the backup creation time. LightSoft
backups can be scheduled at very short intervals (see LightSoft Instance
Backup Levels, page 1-5).

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,
in this way 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:

2. In the corresponding Actions menu, select Set Scheduler Configuration.
The Action List menu for the selected instance appears (with option
descriptions appropriate to the selected instance).
Action list for RDR NMS:

=========================
1 Regular NMS server Backup Cycle
2 Special NMS server Backup
3 Remove NMS Backup Cron Entries
Please select an action to schedule ( q for exit )... [?,??,q]: 1

Regular Backup Standard backup overwriting the oldest existing cyclical

replica according to the predefined number of replicas. For
details, see Replicas, page 1-5.
(LightSoft Only) A regular backup cycle of an nms
instance automatically performed as either a full (L0)
backup or an intermediate (L1 or L2) incremental backup,
according to the configuration of that primary component
instance. For details, see LightSoft Instance Backup Levels,
page 1-5.
Special Backup Special backup session to any named separate replica
(default name – archive). Special backups always involve
full database backup (for LightSoft corresponding to L0).
Remove NMS Clears any schedule entries associated with the specified
Backup crontab instance.
Entries

3. Select the Regular Backup option. The corresponding RDR Scheduler

for Regular Backup menu appears.
RDR Scheduler for Regular EMS-XDM Backup
[ Command: /opt/RDR/bin/SyncMaster -t ems ]

________________________________________________
1 Schedule action by constant interval

2 Schedule action at specific time
3 Show pending cron entries
4 Show existing cron tab on MainComp
5 Apply crontab update

Schedule action by Defines a backup session to run at specified time intervals

constant interval (hours and/or minutes). An offset prevents backups of
multiple components/instances starting at the same time, so
distributing the backup load and avoiding system
congestion.
Schedule action at Defines a backup session to run at a specific time of day,
specific time repeatable daily or on specific day(s) of the week.
Show pending cron Displays crontab entries defined in the current scheduling
entries session (before applying changes).
Show existing cron Displays actual crontab content on the current host.
tab on hostname
Apply crontab Applies the changes. You can choose to replace the
update existing RDR entries or add to them.
4. If you select Schedule action by constant interval from the RDR

Scheduler menu, the following appears:
Set interval unit (m for min, h for hours) [default - min] [?] m
Enter synchronization interval (min)

[default=5][5,10,12,15,20,30,60,?]20
Possible intervals are:

Hours - 2,3,4,6,8,12 and/or Minutes - 5,10,12,15,20,30,60.
Choose an interval compatible with the database size and available

bandwidth.
a. In this example, m for minutes is specified and a 20-minute interval

between backups is defined. Backups are then automatically triggered
at 00:20, 00:40, 01:00, 01:20, … of each day, the first replica taking
place at the first matching time.
OR

b. If you enter h for Hours, the script provides prompts for both hour and
minute selections. If a 2-hour and 30-minute interval is specified,
backups are automatically triggered at 2:30, 5:00, 7:30, … of each day.
A prompt for an offset value appears, enabling you to distribute the
backup loads for different components/instances.
Enter time offset (min) [default=0] [0-59,?] 0
For example, if a 10-minute offset is specified, with a 2-hour and 30-

minute interval, backups will be triggered at 2:40, 5:10, 7:40, … of
each day).
5. If you select Schedule action at specific time from the RDR Scheduler
menu, the following appears.
Enter a time of day ( HH:MM ) [?] 12:34
Enter the time when the backup should start in the specified format (for
example, for 24 hour clock 1pm is entered as 13:00).
The following prompt appears. Specify if the backup should be repeated at

the same time every day of the week (y) or performed only on specific days
(n):
Repeat the action daily? y
RDR Scheduler for Regular NMS Backup Cycle
[ Command: /opt/RDR/bin/SyncMaster -t nms -np -- -a ]
a. If you answer y, a daily backup cycle is defined at the specified time,

and the RDR Scheduler for Regular Backup menu reappears (go to
step 6).
OR

b. If you answer n, the following appears:

Repeat the action daily? n
*****************************************
* REMINDER: Numbering of week days: *
* *
* Sun - 0 , Mon - 1 *
* Tue - 2 , Wed - 3 *
* Thu - 4 , Fri - 5 *
* Sat - 6 *
* *
*****************************************
Enter a week day number (q for end, ? for help) [0-6,?,q] 3
"Wed" is chosen
Enter a week day number (q for end, ? for help) [0-6,?,q] 6
"Sat" is chosen
Enter a week day number (q for end, ? for help) [0-6,?,q] q
Enter the number corresponding to each required weekday, one at a

time. The prompt reappears after each selection.
When no more day selections are required, enter q. The days of the
week that you selected appear.
You've entered: Wed Sat
Are you sure? y
RDR Scheduler for Regular NMS Backup Cycle
[ Command: /opt/RDR/bin/SyncMaster -t nms -np -- -a ]
Enter y to confirm the selections.

6. After the schedule definition is completed, the RDR Scheduler for
Regular Backup menu reappears.

________________________________________________
1 Schedule action by constant interval

2 Schedule action at specific time
3 Show pending cron entries
5 Apply crontab update
Select Apply crontab update to apply the changes.

7. The current cron (scheduler definition) entry appears.

Pending RDR crontab entries:
0,20,40 * * * * /opt/RDR/bin/SyncMaster -t ems >>

/var/tmp/RDR.log.ems
Do you want to A(ppend) R(eplace) or N(one) ? a
Select one of the following options:
Append: Adds current cron entry(ies) to the crontab table.

Replace: Replaces the instant's existing cron entry with the current one.
None: Cancels current action. The crontab table is not updated.
8. The RDR Scheduler for Regular Backup menu for the currently selected
instance reappears. Enter q (quit) to return the Actions menu.
9. If required, repeat steps 2 to 8 to schedule another instance. Else enter q in
successive prompts to return to the RDR Main menu.
Viewing crontab Entries

This section describes how to view the schedule crontab entries of a specified
instance that were generated by the Unix cron scheduling mechanism.
To view crontab entries:

1. Access the RDR Utilities/Actions Menu for a required instance (ems, enm
or nms).
2. In the corresponding Actions menu (see page 3-4), select Set Scheduler
Configuration.
The corresponding Action List menu appears.
Action list for eNM/Syncom EMS:

1 Regular eNM/EMS-Syncom Backup
Please select an action to schedule ( q for exit )... [?,??,q]: 1

3. Select the Regular Backup option.

The corresponding RDR Scheduler for Regular Backup menu appears.
RDR Scheduler for Regular eNM/EMS-Syncom Backup
[ Command: /opt/RDR/bin/SyncMaster -t enm ]

NOTE: If you are using a previous RDR version, select Show

existing cron tab in the corresponding Actions menu.
4. Select the option Show existing cron tab …. The crontab entries appear.
Crontab content on MainComp:
10 3 * * 0,4 /etc/cron.d/logchecker
10 3 * * 0 /usr/lib/newsyslog
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null
2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] &&
/usr/lib/gss/gsscred_clean
0,20,40 * * * * /opt/RDR/bin/SyncMaster -t enm >>
/var/tmp/RDR.log.enm
0,20,40 * * * * /opt/RDR/bin/SyncMaster -t ems >>
/var/tmp/RDR.log.ems
0,20,40 * * * * /opt/RDR/bin/SyncMaster -t nms -np -- -a >>
/var/tmp/RDR.log.nms
RDR Scheduler for Regular eNM/EMS-Syncom Backup

5. After viewing the entries, enter q and then press Enter. The Actions menu
reappears.
NMS Actions Menu

#
6. Press Enter to continue, and enter q (quit) in successive prompts to return

to the RDR Main menu.


8
8 Recovering to a Mirror
Component
In This Chapter
Overview ....................................................................................................... 8-1
Restoring to the Mirror Component .............................................................. 8-2
Setting the Mirror Component....................................................................... 8-7
Overview
This chapter describes how to start a mirror station from any backed up replica
in the event of a primary station failure.
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.
When the primary component is ready to be returned to operation, the reverse
update procedure is used to load the primary component with changes that
occurred to the system when the mirror component was active. See Chapter 9,
Restarting the Primary Instance After Recovery (Reverse Update).
The procedure is in two main parts:
1. Restoring to the mirror component, as described on page 8-2.
2. Setting the mirror component with required parameters from the primary
component. For details, see Setting the Mirror Component, page 8-7.

Recovering to a Mirror Component RDR User Manual
Before you start:

Ensure that the primary instance is really down
Ensure that the appropriate application is correctly installed and not
running on a mirror component
If the backups of primary component instances are distributed between
more than one backup server, ensure that the mirror is reconfigured for the
relevant backup component before activating it (see Reconfiguring the
Mirror Component, page 6-3). This is necessary as the mirror configuration
stores only one backup server setting.
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 at the LightSoft server.
Upon successful completion of the recovery session, start the application in the
regular way.
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), take
care to start only the relevant mirror component/s and, for example,
not to select Combined mode.
Restoring to the Mirror Component

After completing this procedure, you must configure the mirror component
with required parameters from the primary component, and set other
components to recognize the mirror component in place of the failed primary
component (see Setting the Mirror Component, page 8-7).
To start a recovery session:

1. Log in as root user (either on main console or on any terminal connected to
the mirror host).

RDR User Manual Recovering to a Mirror Component

ems, enm, or nms in the RDR Instances Available menu).
3. On the Actions menu, select Start Recovery Session (mirror).
RDR Components on StandbyComp: Backup Mirror
RDR Mirror component Actions Menu

_________________________________
1 Start Recovery Session (mirror)

(This special purpose Actions menu differs from the generic version
presented on page 3-4.)
4. The RDR Backup Sets menu appears.

****************************************************
RDR Recovery on mirror host "StandbyComp"
****************************************************
RDR Backup Sets on "StandbyComp":

__________________________________
# Client Inst Backup folder
1 MainComp ems /sdh_home/Replica

2 MainComp enm /sdh_home/Replica
3 MainComp nms /sdh_home/Replica
4 MainComp2 enm /sdh_home/Replica
Please select backup set to restore... [?,??,q]: 1
Select the required instance (for example, MainComp ems).
(The backup component may have replicas from more than one primary
component. If so, an option is presented for each primary component and
instance combination.)
5. The corresponding Replicas menu appears.

Replicas on "StandbyComp" (primary - MainComp, tag - ems):
__________________________________________________
1 Date - 2013/08/07 11:00:07 Replica - 1

2 Date - 2013/08/07 10:40:07 Replica - 3
3 Date - 2013/08/07 10:20:06 Replica - 2
4 Date - 2013/08/06 16:47:44 Replica - archive
Please select a replica to restore... (default: 1) [?,??]: 1
Select the required replica.

6. The Restart Parameters list appears.

----------------- Restart Parameters ----------------
Primary component to be restored: MainComp

RDR instance to be restored: ems
Backup server: StandbyComp
Replica to restore: 1
Do you want to continue? y
Enter y to confirm the parameters.
7. The following notice appears.

Thu Aug 7 11:13:31 IDT 2003 Mirror Recovery Procedure on
StandbyComp starting...
****************************************************************
* A T T E N T I O N !!! *
* *
* 1. All local databases current data will be lost !! *
* *
* 2. Be sure that routing and network interfaces are *
* set properly for application being restored. *
* *
* 3. Be sure that you have valid licenses to run *
* applications on Mirror Component. *
* *
* *
* Network Management Dept *
* Optical Networks Division *
* ECI Telecom Ltd. *
* *
****************************************************************
Do you want to proceed? y
Enter y to proceed. The processing continues.
8. ems and enm only

The data is recovered.
Thu Aug 7 11:13:33 IDT 2003 Start Restore procedure
[instance: ems, primary host: MainComp, replica: 1]
Please, wait ....
-----------------------------------------------
| |
| Recovery session ended successfully. |
| |
-----------------------------------------------
Running post-recovery script for instance ems...

NOTE: If you are using a previous RDR version, after successful

data recovery, you are prompted to set the Fast Start application
mode. Enter y if you want the recovered system to automatically
start all instances.
Force Fast Application Start after recovery ? n
9. nms only
The following script appears, in continuous display - no user responses are
required.
Thu Aug 7 11:15:43 IDT 2003 Start Restore procedure

[instance: nms, primary host: MainComp, replica: 3]
Please, wait ....VERSANT Utility VBACKUP Version 6.0.5.1

Restoring database `nms_db' from device

`/tmp/versant/db/backup//level0/nms_db':
0% 50% 100%
| | | | |
........................................
Restore has completed successfully.
Would you like to do another level of restore

on database `nms_db'? [ default = no ]
Current settings are:
device = `/tmp/versant/db/backup//level0/nms_db'
position = `0'
capacity = `dynamic'
blocking = `10 Kilobytes'
Mount the appropriate tape and press return to begin... [?=help]
position = `0'
Change additional settings or type <return> to proceed. [?=help]

0% 50% 100%
| | | | |
........................................


position = `0'
Mount the appropriate tape and press return to begin... [?=help]
position = `0'
Change additional settings or type <return> to proceed. [?=help]

0% 50% 100%
| | | | |
........................................
After you have verified that the database was

successfully restored, remember to remove
`/sdh_home/versant/db/nms_db/logical.log'.
(Ignore the removal message.)
-----------------------------------------------
| |
| Recovery session ended successfully. |
| |
-----------------------------------------------
10. The RDR Backup Sets menu reappears.

RDR Backup Sets on "StandbyComp":
__________________________________
# Client Inst Backup folder
1 MainComp ems /sdh_home/Replica

2 MainComp enm /sdh_home/Replica
3 MainComp nms /sdh_home/Replica
Please select backup set to restore... [?,??,q]: q
End of script
RDR Mirror component Actions Menu
RDR host "StandbyComp" Main Menu

11. Repeat steps 3 to 10 to restore the next backup set, else enter q or press
Enter at successive prompts to return to the RDR Main menu.
Setting the Mirror Component

This section describes the actions to take in the event of a primary component
failure involving the ems, enm, or nms instances.
In general, when any primary component fails, the recovery involves activating
the corresponding mirror component, and then setting the remaining primary
components to communicate with the newly activated mirror 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.
Before you start:

1. Restore the required instances to the mirror component (see page 8-2)
2. Disable auto start of each component that will be activated on the Mirror by
entering:
touch /etc/.NO_NMS_AUTO_START (for LightSoft server)
AND/OR
touch /etc/.NO_SYN_AUTO_START (for EMS-SYNCOM)
AND/OR
touch /etc/.NO_XDM_AUTO_START (for EMS-XDM)

To recover the LightSoft Server to the mirror site in case of

primary site failure:
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 auto start on boot
b. Enter /opt/NMS/server/sh/ConfigureNMS.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 (valid for LightSoft V 2)
(In this case, the same Primary Servers WorkStation ID(s) should be
copied to the alternate Mirror component)
OR
If EMS-SYNCOM, EMS-XDM 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/ConfigureNMS.sh
3. In the Primary site, on each EMS-SYNCOM or EMS-XDM 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:3075:2
substituting the applicable mirror host name in place of Primary (the
primary host name)
b. Enter RegisterEMS -f Mirror:3075: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/ConfigureNMS.sh
OR
If the LightSoft server is distributed amongst multiple servers, select
Configure NMS cluster (valid for LightSoft V 2)
OR
If both the LightSoft server and a LightSoft client are to be activated on
the same mirror, enter /opt/NMS/server/sh/ConfigureNMS.sh
No actions are required on either LightSoft clients or EMSs on the primary site.
To recover an EMS-SYNCOM and/or EMS-XDM 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 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:3075: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:3075:2
In place of NMSComp, substitute the hostname of the station that
functions as the LightSoft server.
4. Enter
rm /etc/.NO_AUTO_SYN_START /etc/.NO_AUTO_XDM_START
No actions are required on either LightSoft clients or the LightSoft server on
the primary site.

9
9Restarting the Primary
Instance After Recovery
(Reverse Update)
In This Chapter
Overview ....................................................................................................... 9-1
Performing Reverse Update........................................................................... 9-2
Recognizing the Primary Component............................................................ 9-5
Overview
This chapter describes how to perform a Reverse Update session to return the
primary component to normal operation. 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 (see Performing
Reverse Update, page 9-2).
2. Setting the other components to recognize that the primary component has
been returned to duty in place of the mirror component (see Recognizing
the Primary Component, page 9-5).

Restarting the Primary Instance RDR User Manual
After Recovery (Reverse Update)
Before you start:

Ensure that the instance application to be reverse updated is shut down on
the mirror and primary components
Ensure that the appropriate application is correctly installed and not
running on the primary component
When the Reverse Update session has been completed successfully, you can
run the recovered application on the primary component.
Performing Reverse Update

This section describes how to perform reverse update to the primary
component.
After completing this procedure, you must set other servers to recognize that
the primary component has been returned to duty in place of the mirror
component (see Recognizing the Primary Component, page 9-5).
To start a Reverse Update session:

1. Log in as a root user on the primary component.
3. On the corresponding Actions menu, select Start Reverse Update Session.
4. Specify the mirror station on which the instance to be reverse updated is
currently running.
Specify Mirror Host name or IP address: [?] StandbyComp
5. The following notice appears. Enter y to confirm.

Sun Aug 11 17:00:38 IST 2013 Reverse Update Procedure on MainComp
from StandbyComp starting...
********************************************************
* A T T E N T I O N !!! *
* *
* All local databases current data will be lost !!*
* *
* *
********************************************************
Do you want to proceed? y

RDR User Manual Restarting the Primary Instance
6. EMS or SYNCOM/XDM
A “Restore completed successfully” message appears.
Checking connectivity to mirror component:
------------------------------------------
MainComp -> 147.234.144.30 ... OK
Sun Aug 11 18:56:58 IST 2013 Starting Restoring Database to

primary "MainComp"
------------------------------------------------------------------
-------
Restore completed successfully.
Running post-recovery script for instance ems ...
Force Fast Application Start after recovery ? n
NOTE: If you are using a previous RDR version, select y if you

want the primary component to start the EMS (SYNCOM/XDM)
automatically after recovery is completed. In V 3.5, this prompt is
bypassed.
At the end of processing, press Return to redisplay the Actions menu and
continue to step 8.
Exit code: 0

#

7. NMS (continuation from step 5)

A “Restore has completed successfully” message appears.
Checking connectivity to mirror component:
------------------------------------------
MainComp -> 147.234.144.30 ... OK
Preparing Database on mirror component: StandbyComp

--------------------------------------------------
Mon Aug 11 17:02:35 IDT 2003 Start instance "nms" level 0

backup...

Backing up database `nms_db' to device `/tmp/nms/level0/nms_db':
0% 50% 100%
| | | | |
........................................
Backup has completed successfully.

Exit_Status 0
Mon Aug 11 17:02:40 IDT 2003 End of instance "nms" backup.
Sending Database from mirror "StandbyComp" to primary "MainComp":

--------------------------------------------------------------
Mon Aug 11 17:02:44 IDT 2003 StandbyComp -> MainComp nms ... OK
Exit_Status 0
Sun Aug 11 17:00:51 IST 2013 Starting Restoring Database to

primary "MainComp"
------------------------------------------------------------------

`/sdh_home/RDR.CACHE/nms/level0/nms_db':
0% 50% 100%
| | | | |
........................................

After you have verified that the database was

successfully restored, remember to remove
`/sdh_home/versant/db/nms_db/logical.log'.
No user actions are required. Ignore the prompts “Would you like to do
another level of restore” and “remember to remove”.
Press Enter to redisplay the Actions menu.
8. To reverse update of another instance, repeat from step 2. Else enter q in

successive prompts to return to the main menu.

RDR User Manual Restarting the Primary Instance
Recognizing the Primary Component

After reverse update to the primary component (see page 9-2), 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 from page 8-7.


A
A Suspending or Resuming
RDR Primary Component
Operation
This appendix describes how to suspend RDR primary component activities,
for example in order to perform maintenance operations or software upgrade,
and to resume the primary activities when required.
To suspend or resume RDR operation:

2. Access the RDR Utilities/Actions Menu (selecting Common in the RDR
Instances Available menu). For details, see Chapter 3, RDR Menus.
The General Primary Actions menu is displayed.
General Primary Actions Menu

____________________________
1 Suspend Primary Backup Activity

2 Resume Primary Backup Activity
Please select an action ... [?,??,q]: 1 or 2
3. Select the required option to Suspend or Resume. The Suspend mode is

turned on or off accordingly.
Sat Aug 31 09:55:29 IST 2013 Suspend mode ON mode OFF
432006-2419-013-A00 ECI Telecom Ltd. Proprietary A-1

Suspending or Resuming RDR RDR User Manual
Primary Component Operation
4. Enter q to redisplay the RDR Main menu.

General Primary Actions Menu
____________________________
1 Suspend Primary Backup Activity

2 Resume Primary Backup Activity
A-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

B
10 RDR Commands
This appendix 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.
RDR
RDR Command Center.

Functional description: An interactive menu driven utility for launching most
useable RDR functions, for example:
RDR components configuration
Running different types of backup sessions
Scheduling automatic backups
Performing reverse update
Performing a recovery session on a mirror component
Viewing a README file
SyncMaster
RDR synchronization (replication) utility.

Function description: Performs direct replication between Primary component
and Backup-Server. Supports regular and archive replications. Normally
invoked by cron (see SetCronRDR).
Usage: SyncMaster -t tag [-b backup_hostname]

[-dest target] [-a] [-v] [-i] [-h] [-suspend|-continue]
432006-2419-013-A00 ECI Telecom Ltd. Proprietary B-1

RDR Commands RDR User Manual
Options:
-t Instance tag (required)
-b Backup server name or IP (default – Backup Server)
dest Use specific backup target folder
-a Archive backup
-suspend Temporarily suspend synchronization
-continue Continue synchronization (if suspended)
-v Verbose mode
-i Interactive mode
-h This message
RDR.config
Main configuration utility.

Functional description: Configures all RDR components (Primary, Backup
and Mirror).
Usage: RDR.config [-mirror] [-backup] [-unconfig] [-h]

Options (default - primary):
-mirror Configure Mirror component
-backup Configure Backup-Server
-unconfigure Unconfigure RDR on current component
-h Print help message
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
[-t|-tag] [-b hostname] [-nt|-no_trans] [-help]
Options:
-t Restore from specified instance
-b hostname Restore from specified backup component
-nt Restore from previous found cache on mirror component
-help This message
B-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR User Manual RDR Commands
ReverseUpdate
RDR Primary component restore utility.

Functional description: Restore Primary Component from Mirror
Usage: ReverseUpdate -m mirror_host -t TAG [-D]
Options:
hostname Mirror Component name or IP (required)
-t tag Instance tag (required)
-D Debug mode
SetCronRDR
Sets Unix crontab for automatic replication.

Functional description: Interactive utility for replication of interval setting on
Primary Component.
Usage: SetCronRDR [-t tag] [-h]

Options:
-t tag Instance tag, Set automatic replication for a specified instance.
-h Print help message
LocalBackup
Creates a local backup copy of an instance on the same host.

Usage: LocalBackup [ -d backup dir]
Options:
-d backup dir Specify directory to backup to ( default: - $HOME/BACKUP)
NOTE:
LocalBackup can be performed at any time and does not require
RDR configuration.
The instance for an action is derived from current UNIX user
(nms/enm/ems).
432006-2419-013-A00 ECI Telecom Ltd. Proprietary B-3

RDR Commands RDR User Manual
RestoreLocal
Restores an RDR instance from a local backup copy on the same host.
Usage: RestoreLocal [ -d backup dir]
Options:
-d backup dir Specify directory to backup to ( default: - $HOME/BACKUP)
NOTE:
RestoreLocal can be performed at any time and does not require
RDR configuration.
The instance for an action is derived from the current UNIX user
(nms/enm/ems).
B-4 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

C
11 Glossary
This appendix 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 (replica) Special copy of application data for long term storage
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
432006-2419-013-A00 ECI Telecom Ltd. Proprietary C-1

Glossary RDR User Manual
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
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 session Backup session invoked by crontab
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
C-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

12 Index
A C
About This Manual • vii Commands • See RDR Commands
Activation • See Component Activation Communications Requirements • 2-3
Application Requirements • 2-1 Component Activation
mirror stations • 2-2 backup session • 1-13, 7-1
Archive Backups • 7-2, 7-4 recovering from backup to mirror • 1-
Auto Start Applications on Mirror • 6-3 14, 8-1
reverse update to primary • 1-15, 9-1
B
Components • 1-2
Backup Component Configuration • 5-1 backup • 1-3
configuration procedure • 5-2 mirror • 1-4
testing the configuration • 5-6 primary • 1-3
viewing instance and replica status • Configuration Menu • 3-3
5-5
Configuration Workflow • 4-2
Backup Components • 1-3
Configurations in RDR • 1-8
configuration • 5-1
backup deployment • 1-8
Backup Deployment • 1-8
EMS configuration issues • 1-12
shadow backup server • 1-9
LightSoft configuration issues • 1-13
Backup Levels for LightSoft Instances •
1-6 primary-to-mirror ratio • 1-9
Backup Server Disk Capacity • 2-2 Configuring
Backup Session • 1-13 backup components • 5-1
Backups messages display • 4-8
creating and scheduling • 7-1 mirror components • 6-1
creating regular or archive backups • mirror settings after restore • 8-8
7-2 primary components • 4-1, 4-3
cron entries • 7-10 shadow backup server • 5-7
defining backup schedules • 7-4 Cron Entries • 7-10
Bandwidth Requirements • 2-3
432006-2419-013-A00 ECI Telecom Ltd. Proprietary I-1

Index RDR User Manual
E P
EMS Configurations • 1-12 Preliminary Requirements Before
Installation • 2-1
F
application requirements • 2-1
Frequencies and wavelengths • 1 backup server disk capacity • 2-2
Functional Description • 1-2 communications and bandwidth • 2-3
components • 1-2 Primary Components • 1-3
instances • 1-4 backing up • 7-1
replicas • 1-5 configuration procedure • 4-3
G messages display configuration • 4-8
reactivating • 9-1
Glossary of Terms • 1
suspending or resuming operation • 1
I
Primary-to-Mirror Configurations • 1-9
Installation Requirements • See 1 to 1 • 1-10
Preliminary Requirements Before
2 to 2 • 1-11
Installation
N to 2 • 1-12
Instances • 1-4
LightSoft backup levels • 1-6 R
viewing status • 5-5 RDR
L configurations • 1-8
functional description • 1-2
LightSoft Instance Configurations • 1-13
terminology • 1-1
LocalBackup Command • 4
what is? • 1-2
M RDR Commands • 1
Main Menu • 3-2 LocalBackup • 4
Menus • See RDR Menus RDR • 1
Messages Display Configuration • 4-8 RDR.config • 2
Mirror Components • 1-4 Restart Mirror • 2
application auto start • 6-3 RestoreLocal • 4
configuration procedure • 6-1 Reverse Update • 3
reconfiguring • 6-3 SetCronRDR • 3
recovery to • 8-1 SyncMaster • 2
Mirror Station Application Requirements RDR Menus • 3-1
• 2-2 Configuration menu • 3-3
N Main menu • 3-2
N to 2 Configuration • 1-12 Utilities/Actions menu • 3-4
RDR.config Command • 2
I-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR User Manual Index
Recovery from Backup to Mirror • 1-14, X

8-1
XDM system overview • 1-1
restore procedure • 8-3
setting the mirror component • 8-8
Replicas • 1-5
viewing status • 5-5
Restart Mirror Command • 2
Restarting the Primary • 9-1
performing reverse update • 9-2
recognizing the primary component •
9-5
RestoreLocal Command • 4
Resuming Primary Operation • 1
Reverse Update Command • 3
Reverse Update to Primary • 1-15
S
Scheduling Backups • 7-1
SetCronRDR Command • 3
Shadow Backup Server • 1-9
Status of Instances and Replicas • 5-5
Suspending Primary Operation • 1
SyncMaster Command • 2
T
Technical Assistance • xi
Terminology • 1-1
Typographical Conventions • ix
U
Utilities/Actions Menu • 3-4
W
What Is RDR? • 1-2
Workflow
432006-2419-013-A00 ECI Telecom Ltd. Proprietary I-3

Index RDR User Manual
I-4 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

Remote Data Replicator (RDR) : User Manual

Uploaded by

Copyright:

Available Formats

You might also like

Remote Data Replicator (RDR) : User Manual

Uploaded by

Document Information

Original Title

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) : User Manual

Uploaded by

Copyright:

Available Formats

Remote Data Replicator (RDR)

© Copyright by ECI Telecom, 2005. All rights reserved worldwide.

2 Preliminary Requirements ...................................................... 2-1

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

4 Configuring Primary Components ......................................... 4-1

432006-2419-013-A00 ECI Telecom Ltd. Proprietary i

5 Configuring Backup Components ......................................... 5-1

6 Configuring Mirror Components ............................................ 6-1

7 Creating and Scheduling Backups of Primary Component

8 Recovering to a Mirror Component ....................................... 8-1

9 Restarting the Primary Instance After Recovery

ii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

A Suspending or Resuming RDR Primary Component

10 RDR Commands ..................................................................... B-1

11 Glossary .................................................................................. C-1

12 Index .......................................................................................... I-1

432006-2419-013-A00 ECI Telecom Ltd. Proprietary iii

432006-2419-013-A00 ECI Telecom Ltd. Proprietary v

432006-2419-013-A00 ECI Telecom Ltd. Proprietary vii

viii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

Convention Indicates Example

NOTE: Clarifying information, specific instructions, commentary,

CAUTION: Failure to follow directions could result in damage to

WARNING: Failure to follow directions could result in bodily

432006-2419-013-A00 ECI Telecom Ltd. Proprietary ix

Obtaining Technical Documentation

x ECI Telecom Ltd. Proprietary 432006-2419-013-A00

Your Opinion Is Very Important To Us

What features did you like most about this manual?

432006-2419-013-A00 ECI Telecom Ltd. Proprietary xi

xii ECI Telecom Ltd. Proprietary 432006-2419-013-A00

432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-1

1-2 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

RDR manages an independent backup session for every primary component

432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-3

NOTE: When the LightSoft server involves a cluster configuration

1-4 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

LightSoft Instance Backup Levels

432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-5

Level 2 (L2) incremental backups (up to 5 can be defined), recording

Figure 1-1: Sequence of LightSoft instance backups over time

1-6 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

At Time4, an intermediate backup of differences between Time2 and

Typical RDR Configurations

For convenience, servers are generally referred to in procedures by

Similarly, separate backup and mirror servers might be called

The examples in this manual are primarily based on a backup and a

The IP addresses corresponding to named hosts are identified in the

432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-7

On a dedicated backup server. The server is configured with only two

Shadow backup server

Primary and Mirror Configurations

1-8 ECI Telecom Ltd. Proprietary 432006-2419-013-A00

Figure 1-2: Simple configuration example – 1:1

432006-2419-013-A00 ECI Telecom Ltd. Proprietary 1-9

Figure 1-3: Simple configuration example – 2:2

NOTE: If required, the primary component 2 application can be

1-10 ECI Telecom Ltd. Proprietary 432006-2419-013-A00