Symantec logo


On a Secondary RLINK, the active state indicates that it is ready to receive updates from the Primary.


Asynchronous mode queues writes persistently and holds them at the Primary for later transmission.

automatic synchronization

A feature of VVR that synchronizes the Secondary while the application is running on the Primary.


If the inconsistent and can_sync flags are set, there is enough information in the Secondary SRL to make it consistent again. In this case, the RLINK does not need to be fully resynchronized and is still a suitable candidate for takeover.


If the RLINK flag is cant_sync, the RLINK is inconsistent and the Secondary needs a full synchronization before it can take part in replication again.


A feature of VVR that allows replay of the SRL from an earlier point than the current position. A checkpoint delineates with starting and ending points the section of the SRL to be replayed later.


If the Primary RVG is in the clean active state, the RLINK must be attached.


A technique for preserving the original data. Before data is modified by a write operation, the original copy of data is copied to a different location.


A term indicating that data is recoverable by the system or application using it; for example, a file system or database. In VVR, a Secondary that is consistent can be used for takeover.

data volume

A volume that is associated with an RVG and contains application data.

DCM (Data Change Map)

An object containing a bitmap that can be optionally associated with a data volume on the Primary RVG. The bits represent regions of data that are different between the Primary and the Secondary. The bitmap is used during synchronization and resynchronization.

disaster recovery

Disaster Recovery (DR) has a wide scope, which ranges from the storage of backup tapes off site to the setup and maintenance of a duplicate remote standby node. VVR aids disaster recovery by providing timely replication of data to a remote site.

distributed command

A command or task that can be performed on an RDS from any host in the RDS environment; a related task is performed in sequence on all hosts in the RDS, if appropriate.


If the Primary RVG state is empty, an RLINK can be attached with no special options.


A Secondary RLINK can enter the fail state when the Secondary data volume has an error or when an ACTIVE Secondary RLINK is paused with the -w option. A Primary RLINK enters the fail state when the corresponding Secondary RLINK enters the fail state.


Failover is a term associated with the Veritas Cluster Server environment. See Primary takeover for a description in the VVR environment.


A feature that is used to perform quick and efficient resynchronization of stale mirrors, and to increase the efficiency of the snapshot mechanism. Also see Persistent FastResync and Non-Persistent FastResync.

heartbeat protocol

The heartbeat protocol is a continuous exchange of messages to ensure that the nodes in an RDS will detect any network outage or a node crash. The protocol allows the nodes to reestablish a connection later.


See In-Band Control Messaging.

In-Band Control Messaging

A facility that enables applications to inject control messages in the replication stream. The contents of the control message itself are application-defined and opaque to the replication process.


In VVR, a Secondary is inconsistent if it is not a viable candidate for takeover, because it is known that the application will not be able to recover.

latency protection

For RLINKs operating in asynchronous mode, which may fall behind, the latency protection attribute (latencyprot) of the RLINK is used to limit the maximum number of outstanding write requests. The maximum number of outstanding write requests cannot exceed the value set in latency_high_mark, and cannot increase until the number of outstanding writes falls to the latency_low_mark.


See latency protection.


The node on which VVR performs replication when replicating in a shared disk group environment. For synchronous RLINKs, VVR also performs writes on the logowner node.

metadata shipping

The process of exchanging information between the non-logowner nodes that issue writes and the logowner, and then writing locally on the non-logowner nodes, when replicating in asynchronous mode.

nmcom pool

The amount of buffer space available for updates coming in to the Secondary over the network.

Non-Persistent FastResync

A form of FastResync that cannot preserve its maps across reboots of the system because it stores its change map in memory.

object recovery

The process of making an object usable after a system crash.


Typically, writes to a Primary RVG are written to the SRL first, and then to the RLINKs and data volumes. If there is no SRL or the SRL is detached, writes are no longer written to the SRL and the RVG is in passthru mode. No replication takes place.

Persistent FastResync

A form of FastResync that can preserve its maps across reboots of the system by storing its change map in a DCO volume on disk.


A copy of a volume and its data in the form of an ordered collection of subdisks. Each plex is a copy of the volume with which it is associated. The terms mirror and plex can be used synonymously.

Primary checkpoint

A method for synchronizing a Secondary with the Primary without stopping the application. A command marks the start of the checkpoint. All Primary data volumes are backed-up and then the end of the checkpoint is marked. The data is restored on the Secondary and the Primary can then begin from the start of the checkpoint. The Secondary becomes consistent when the end of the checkpoint is reached.

Primary pause

An administrator at the Primary volume node may pause updates to any particular RLINK of an RVG. During a pause, the Primary continues to keep a history of volume updates, but active update of the RLINK ceases and the network connection between the Primary and Secondary is broken. A Primary pause is intended as a maintenance feature and allows certain configuration changes to be made, such as a change to the network connecting two nodes.

Primary migration

The Primary role of a volume can be migrated from a Primary node to a Secondary node, within certain restrictions. The process is manual and requires cooperative administrative action on the Primary and all Secondary nodes. During this process, update of the former Primary must be halted and cannot be resumed on the new Primary until the migration is complete.

The Primary role can only be migrated to an up-to-date RLINK that is consistent and is not in an error state. Any out-of-date Secondaries must be fully resynchronized with the new Primary.

Primary node

The Primary node is where the application is running, and from which data is being replicated to the Secondary.

Primary node crash

If a Primary node crash occurs, the Primary SRL and all data volumes in the RVG must be recovered. Both are recovered using VVR specific recovery, rather than the usual Volume Manager volume recovery.

Primary node data volume failure

If there is an error accessing a Primary data volume, the data volume and the RVG are automatically detached, and the RVG state changes to fail. RLINKs are not affected. If the SRL volume was not empty at the time of the volume error, the updates continue to flow from the SRL to the Secondary RLINKs.

Primary node SRL overflow

Because the Primary SRL is finite, prolonged halts in update activity to any RLINK can exceed the SRL's ability to maintain all the necessary update history to bring an RLINK up-to-date. When this occurs, the RLINK is marked as STALE and requires manual recovery before replication can proceed.

Primary Replicated Volume Group

See RVG (Replicated Volume Group).

Primary SRL failure

See Passthru

Primary takeover

The Primary role can be arbitrarily taken over by a Secondary node. This process is similar to a Primary role migration but presumes that the old Primary is inoperable and unable to participate in the migration process.

Primary takeover is intended to support disaster recovery applications. Only a limited number of error scenarios prior to loss of the Primary node can prevent a takeover because they leave the RLINK in an inconsistent state. All such scenarios require the hardware failure of a data volume or SRL.

RDS (Replicated Data Set)

The group of the RVG on a Primary and the corresponding RVGs on one or more Secondary hosts.


The process of retrieving a write request from the SRL in order to send it across the RLINK.

readback pool

The amount of buffer space available for readbacks.


An RLINK represents the communication link between the corresponding RVGs on the Primary and Secondary nodes.

RVG (Replicated Volume Group)

A component of VVR that is made up of a set of data volumes, one or more RLINKs, and an SRL. VVR replicates from the Primary RVG, on the node where the application is running, to one or more Secondary RVGs.

RVIO pool

The amount of buffer space allocated within the operating system to handle incoming writes.

Secondary checkpoint

See checkpoint.

Secondary data volume failure

Secondary data volume failure causes the RLINK to be put in the fail state. The Primary stops sending requests to the RLINK, but logging continues on the Primary node. When the failure has been corrected, it can be restored from a backup made earlier using a Secondary checkpoint.

Secondary node

The node to which VVR is replicating data from the Primary.

Secondary pause

An administrator at the Secondary node can pause updates to the RLINK. Unlike a Primary pause, the Primary-Secondary network connection is maintained. This enables the Secondary to notify the Primary when it wants updates of the RLINK to continue. A Secondary pause can be effected even when the Primary and Secondary have lost contact.

Secondary Replicated Volume Group

See RVG (Replicated Volume Group).


A point-in-time image of a volume or file system that can be used as a backup.

snapshot volume

An exact copy of a volume, at a specific point in time. The snapshot volume is created by breaking a snapshot plex from the original volume and placing it in a new volume, which is then used for online backup purposes.

SRL (Storage Replicator Log)

The Storage Replicator Log (SRL) is a circular buffer of writes for an RVG. Writes stored in the SRL are waiting to be shipped to the Secondary from the Primary, or waiting to be written to the data volumes in the RVG.

SRL overflow protection

A feature of VVR that ensures that a Secondary RVG does not require a full resynchronization after a Primary node SRL overflow.


The RLINK state that indicates that the RLINK has either not been attached yet or it has overflowed.


The process of making the data on the Secondary identical to the data on the Primary.


In synchronous mode, the Secondary is kept up-to-date with the Primary by waiting for each write request to be acknowledged by the Secondary before the application sees the successful completion of the write on the Primary.

unrecoverable errors

Some errors, in particular hard errors such as media failures, require manual intervention to repair. The chances of such failures can be minimized by using standard VxVM setups to maintain mirrored copies of each data volume and the SRL.


Data from the Primary corresponding to an application write sent to the Secondary.

Volume Replicator Objects

The objects used for replication such as RVG (Replicated Volume Group), SRL (Storage Replicator Log), RLINK, and DCM (Data Change Map).

write-order fidelity

A feature of VVR that applies writes on the Secondary in the same order as they are received on the Primary. This ensures that the data on the Secondary is consistent with the data on the Primary.

write shipping

The process of sending the writes issued on nodes other than the logowner over the cluster network to the logowner.