Veritas Access Appliance Administrator's Guide
- Section I. Introducing Access Appliance
- Section II. Configuring Access Appliance
- Managing users
- Configuring the network
- Configuring authentication services
- Configuring user authentication using digital certificates or smart cards
- Section III. Managing Access Appliance storage
- Configuring storage
- Managing disks
- Access Appliance as an iSCSI target
- Configuring storage
- Section IV. Managing Access Appliance file access services
- Configuring the NFS server
- Setting up Kerberos authentication for NFS clients
- Using Access Appliance as a CIFS server
- About configuring CIFS for Active Directory (AD) domain mode
- About setting trusted domains
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- About managing local users and groups
- Using Access Appliance as an Object Store server
- Configuring the NFS server
- Section V. Managing Access Appliance security
- Section VI. Monitoring and troubleshooting
- Configuring event notifications and audit logs
- About alert management
- Appliance log files
- Configuring event notifications and audit logs
- Section VII. Provisioning and managing Access Appliance file systems
- Creating and maintaining file systems
- Considerations for creating a file system
- About managing application I/O workloads using maximum IOPS settings
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VIII. Provisioning and managing Access Appliance shares
- Creating shares for applications
- Creating and maintaining NFS shares
- About the NFS shares
- Creating and maintaining CIFS shares
- About the CIFS shares
- About managing CIFS shares for Enterprise Vault
- Integrating Access Appliance with Data Insight
- Section IX. Managing Access Appliance storage services
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Access Appliance continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Configuring episodic replication
- Section X. Reference
Displaying continuous replication information and status
The Replication continuous show and Replication continuous status commands display information on continuous replication which lets you confirm any changes that are made to your replication file system and view the current file system status.
To display the list of file systems which are configured under continuous replication
- To display the list of file systems which are configured under continuous replication, enter the following command:
Replication> continuous show
To display the status of a replication file system
- To display the status of a replication file system, enter the following command:
Replication> continuous status fs_name
fs_name
Specify the file system name that you have configured for continuous replication.
Table: describes the important attributes displayed by the Replication> continuous status command.
Table:
Attribute | Description |
---|---|
Replicated Data Set | Specifies the name of the replicated data set |
Replication role | Specifies the role of the cluster in continuous replication. It is either primary or secondary. |
Replication link | Specifies the link name which is created during the authentication of the source and the destination cluster. |
Primary site Info | Provides the details of continuous replication related to the source cluster like host name and RVG state. |
Secondary site Info | Provides the details of continuous replication related to the destination cluster like host name, configured mode, data status, replication status, current mode, and timestamp information. |
Host name | For the primary site, it provides the continuous replication IP which binds on the source cluster using the Replication> continuous config bind command. For the secondary site, it provides the continuous replication IP which binds on the destination cluster using the Replication> continuous config bind command. |
RVG state | Specifies the state of the primary RVG. See Table: RVG status for details on its various states. |
Configured mode | Specifies the continuous replication configured mode. It may be synchronous-override or asynchronous. |
Current mode | Specifies the mode of replication - asynchronous or synchronous that is used to replicate data to the secondary. |
Data status | Shows the data status for the secondary. See Table: Data status for details on its various states. |
Replication status | Specifies the status of the replication to the secondary. See Table: Replication status for details on its various states. |
Logging to | Indicates whether updates for the secondary are tracked on the primary using the SRL or DCM. See Table: Logging to status for details on its various states. |
Timestamp information | Shows the time by which secondary is lagging behind the primary. |
Table: RVG status describes the values for the RVG state.
Table: RVG status
Value | Description |
---|---|
acting_secondary | The primary RVG is currently the acting secondary as part of the fast failback process. Writes to the data volumes in this RVG are disabled independent of whether the RVG is started or stopped. |
Disabled for I/O | Primary RVG is disabled for I/O. The RVG is stopped. |
Enabled for I/O | Primary RVG is enabled for I/O. The RVG has been started. |
Needs recovery | State of the RVG after an import or restart. |
Passthru | The primary RVG is in passthru mode because the primary SRL is detached or missing. |
Table: Data status describes the values for the Data status.
Table: Data status
Value | Description |
---|---|
consistent, behind | Secondary data is consistent but not up to date with the primary data. |
consistent, stale | The data on the secondary is consistent. Replication to the secondary has been stopped. The primary RLINK is detached. |
consistent, up-to-date | The secondary data is consistent and is current or up-to-date with the primary data. The primary role can be migrated to the secondary. |
inconsistent | The data on the secondary volumes is not consistent and the secondary cannot take over. |
N/A | Current state of the secondary data cannot be determined. This may occur because of a configuration error on the secondary. |
Table: Replication status describes the values for the Replication status.
Table: Replication status
Value | Description |
---|---|
logging to DCM | DCM is active for the secondary. New updates on primary are tracked using DCM for the secondary. The following information may be displayed:
|
Needs failback synchronization | The primary RVG is acting as secondary as part of the fast failback process. Start failback resynchronization on the new primary to continue replication. |
Not replicating | Data is not being replicated to secondary because primary RLINK is in needs_recovery state.
|
Paused by user | Replication to secondary is paused due to some administrative action. This results in the following states:
|
Paused due to error | Replication to secondary is paused due to the following errors:
|
Paused due to network disconnection | Replication to secondary is paused due to some network problem. |
Replicating | Replication can take place if there are updates on the primary data volumes. |
Resync in progress | Resynchronization to the secondary is in progress.
|
Resync paused by user. | Resynchronization to secondary is paused due to some administrative action. This results in the following states:
|
Resync paused due to error. | Resynchronization to Secondary is paused because of the following errors:
|
Resync paused due to network disconnection. | Resynchronization to secondary is paused due to some network problem. |
Stopped | Replication to secondary is stopped due to the following:
|
N/A | The replication status cannot be determined. |
Table: Logging to status describes the values for the Logging to field.
Table: Logging to status
Value | Description |
---|---|
DCM (contains xxx KB) (log_type) | DCM is active (in use) for the replication to the secondary. The log_type can be autosync, failback logging, or SRL protection logging. The yyy% value can sometimes reach beyond 100%. If synchronization is restarted and the DCM map is full, new incoming writes cause the total yyy% to exceed 100%. |
SRL (xxx KB behind, yyy % full) | Updates to be transferred to secondary are logged into the SRL and are currently occupying xxx KB or yyy% of the SRL. |
SRL | SRL is used for logging. Check the Data status field for the status of the secondary data. |