Veritas Access Troubleshooting Guide
- Introduction
- General troubleshooting procedures
- About general troubleshooting procedures
- Viewing the Veritas Access log files
- About event logs
- About shell-activity logs
- Setting the CIFS log level
- Setting the NetBackup client log levels and debugging options
- Retrieving and sending debugging information
- Insufficient delay between two successive OpenStack commands may result in failure
- Monitoring Veritas Access
- Common recovery procedures
- About common recovery procedures
- Restarting servers
- Bringing services online
- Recovering from a non-graceful shutdown
- Testing the network connectivity
- Troubleshooting with traceroute
- Using the traceroute command
- Collecting the metasave image of a file system
- Replacing an Ethernet interface card
- Speeding up replication
- Uninstalling a patch release or software upgrade
- Troubleshooting the Veritas Access cloud as a tier feature
- Troubleshooting Veritas Access installation and configuration issues
- Troubleshooting Veritas Access CIFS issues
- Troubleshooting Veritas Access GUI startup issues
About synchronizing a replication job
The first time a replication job is run, Veritas Access makes a full copy of the data from the source location to the destination. Subsequent jobs (triggered manually or through a schedule) only copy incremental changes.
In certain rare cases, data is already present at the destination, but the replication cannot make the incremental changes. Examples of this situation include:
When replication has not been run for several days or weeks, and the changes that are tracked by the VxFS file change log have been overwritten (or possibly corrupted). This log is required for replication.
When a replication job is temporarily disabled and started again, the next job run triggers a full copy of the data.
When some changes have been made to the replication definition. For example, an earlier replication consisted of fs1/folder1, but you want to replicate data in fs1/folder2 also. Because fs1/folder2 requires a full copy, fs1/folder1 is copied once again, even though only incremental changes are needed.
When the direction of the replication has to be reversed from destination to source. Even though most data is present at both the destination and the source, anytime you create a new job at the destination, a full copy is triggered automatically for the first replication.
If an administrator accidentally deletes the internal database for replications and no backup is available, creating a new job (even for an existing configuration) triggers a full copy.
In these cases, instead of waiting to initiate a full copy, you can use the Replication> job sync command to leverage the existing data at the destination and avoid requiring a full copy. The Replication> job sync command returns the replication job to a well-defined state and incremental replication can be used.
After you sync a job, the job is re-enabled, and you can use the standard job trigger or set the replication frequency to trigger incremental replication.
Note:
Synchronization is only supported on enabled jobs. If you are not able to resume from a failed job, and you want to use the Replication> job sync command to recover from this state, follow these steps. First, disable the job, then enable the job again. Then, use the Replication> job sync command to synchronize the job.
Note:
Synchronization can not be performed on a paused replication job. If synchronization is performed on a paused job that has been aborted or stopped, the last recovery point objective (RPO) for the paused job is not available.