Skip to content

Troubleshooting & Additional Information

SyncSafe Replication utility

DNS

Page 429 in OG documentation

DFO Utility

Job Validation Issue Troubleshooting

Job Validation errors are designated by a white X inside a red circle. Warnings are designated by a black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then success messages. Click on any of the validation items to see details. You must correct any errors before you can continue. Depending on the error, you may be able to click Fix or Fix All and let SyncSafe Replication correct the problem for you. For those errors that SyncSafe Replication cannot correct automatically, you will need to modify the source or target to correct the error, or you can select a different target. You must revalidate the selected servers, by clicking Recheck, until the validation check passes without errors. Click the Common Job Validation Warnings and Errors link to open a web browser and view solutions to common validation warnings and errors.

If you receive a path transformation error during job validation indicating a volume does not exist on the target server, even though there is no corresponding data being protected on the source, you will need to manually modify your replication rules. Go back to the Choose Data page and under the Replication Rules, locate the volume from the error message. Remove any rules associated with that volume. Complete the rest of the workflow and the validation should pass.

Before a job is created, the results of the validation checks are logged to the Double-Take Management Service log on the target. After a job is created, the results of the validation checks are logged to the job log. See the SyncSafe Replication for details on the various SyncSafe Replication log files.

Source/Target Disconnects

<<<<<<< HEAD As noted in the Server Configuration Details section of the Initial SyncSafe Replication Configuration page under the Automatically Reconnect During Source Initialization, there are a number of cases that might cause a disconnect between the source and target of a mirror. ======= As noted in the Server Configuration Details section of the Initial SyncSafe Replicate Configuration page under the Automatically Reconnect During Source Initialization, there are a number of cases that might cause a disconnect between the source and target of a mirror.

897742db4bf52242985e942408b322339ff206dc

Automatic Disconnect Scenarios

Disk queues are user configurable and can be extensive, but they are limited. If the amount of disk space specified for disk queuing is met, additional data would not be added to the queue and data would be lost. To avoid any data loss, SyncSafe Replication will automatically disconnect jobs when necessary. If this option is enabled, SyncSafe Replication will automatically reconnect any jobs that it automatically disconnected. These processes are called auto-disconnect and auto-reconnect and can happen in the following scenarios:

<<<<<<< HEAD * Source Server Restart - If your source server is restarted, SyncSafe Replication will automatically reconnect any jobs that were previously connected. Then, if configured, SyncSafe Replication will automatically remirror the data. * Exhausted Queues On The Source - If disk queuing is exhausted on the source, SyncSafe Replication will automatically start disconnecting jobs. This is called auto-disconnect. The transaction logs and system memory are flushed allowing SyncSafe Replication to begin processing anew. The auto-reconnect process ensures that any jobs that were auto-disconnected are automatically reconnected. Then, if configured, SyncSafe Replication will automatically remirror the data. * Exhausted Queues On The Target - If disk queuing is exhausted on the target, the target instructs the source to pause. The source will automatically stop transmitting data to the target and will queue the data changes. When the target recovers, it will automatically tell the source to resume sending data. If the target does not recover by the time the source queues are exhausted, the source will auto-disconnect as described above. The transaction logs and system memory from the source will be flushed then SyncSafe Replication will auto-reconnect. If configured, SyncSafe Replication will auto-remirror. * Queuing Errors - If there are errors during disk queuing on either the source or target, for example, SyncSafe Replication cannot read from or write to the transaction log file, the data integrity cannot be guaranteed. To prevent any loss of data, the source will auto-disconnect and auto-reconnect. If configured, SyncSafe Replication will auto-remirror. * Target Server Interruption - If a target machine experiences an interruption (such as a cable or NIC failure), the source/target network connection is physically broken but both the source and target maintain the connection information. The SyncSafe Replication source, not being able to communicate with the SyncSafe Replication target, stops transmitting data to the target and queues the data changes, similar to the exhausted target queues described above. When the interruption is resolved and the physical source/target connection is reestablished, the source begins sending the queued data to the target. If the source/target connection is not reestablished by the time the source queues are exhausted, the source will auto-disconnect. * Target Service Shutdown - If the target service is stopped and restarted, there could have been data in the target queue when the service was stopped. To prevent any loss of data, the Double-Take service will attempt to persist to disk important target connection information (such as the source and target IP addresses for the connection, various target queue information, the last acknowledged operation, data in memory moved to disk, and so on) before the service is stopped. If SyncSafe Replication is able to successfully persist this information, when the Double-Take service on the target is restarted, SyncSafe Replication will pick up where it left off, without requiring an auto-disconnect, auto-reconnect, or auto-remirror. If SyncSafe Replication cannot successfully persist this information prior to the restart (for example, a server crash or power failure where the target service cannot shutdown gracefully), the source will auto-reconnect when the target is available, and if configured, SyncSafe Replication will auto-remirror. ======= 1. Source Server Restart - If your source server is restarted, SyncSafe Replicate will automatically reconnect any jobs that were previously connected. Then, if configured, SyncSafe Replicate will automatically remirror the data. * Exhausted Queues On The Source - If disk queuing is exhausted on the source, SyncSafe Replicate will automatically start disconnecting jobs. This is called auto-disconnect. The transaction logs and system memory are flushed allowing SyncSafe Replicate to begin processing anew. The auto-reconnect process ensures that any jobs that were auto-disconnected are automatically reconnected. Then, if configured, SyncSafe Replicate will automatically remirror the data. * Exhausted Queues On The Target - If disk queuing is exhausted on the target, the target instructs the source to pause. The source will automatically stop transmitting data to the target and will queue the data changes. When the target recovers, it will automatically tell the source to resume sending data. If the target does not recover by the time the source queues are exhausted, the source will auto-disconnect as described above. The transaction logs and system memory from the source will be flushed then SyncSafe Replicate will auto-reconnect. If configured, SyncSafe Replicate will auto-remirror. * Queuing Errors - If there are errors during disk queuing on either the source or target, for example, SyncSafe Replicate cannot read from or write to the transaction log file, the data integrity cannot be guaranteed. To prevent any loss of data, the source will auto-disconnect and auto-reconnect. If configured, SyncSafe Replicate will auto-remirror. * Target Server Interruption - If a target machine experiences an interruption (such as a cable or NIC failure), the source/target network connection is physically broken but both the source and target maintain the connection information. The SyncSafe Replicate source, not being able to communicate with the SyncSafe Replicate target, stops transmitting data to the target and queues the data changes, similar to the exhausted target queues described above. When the interruption is resolved and the physical source/target connection is reestablished, the source begins sending the queued data to the target. If the source/target connection is not reestablished by the time the source queues are exhausted, the source will auto-disconnect. * Target Service Shutdown - If the target service is stopped and restarted, there could have been data in the target queue when the service was stopped. To prevent any loss of data, the Double-Take service will attempt to persist to disk important target connection information (such as the source and target IP addresses for the connection, various target queue information, the last acknowledged operation, data in memory moved to disk, and so on) before the service is stopped. If SyncSafe Replicate is able to successfully persist this information, when the Double-Take service on the target is restarted, SyncSafe Replicate will pick up where it left off, without requiring an auto-disconnect, auto-reconnect, or auto-remirror. If SyncSafe Replicate cannot successfully persist this information prior to the restart (for example, a server crash or power failure where the target service cannot shutdown gracefully), the source will auto-reconnect when the target is available, and if configured, SyncSafe Replicate will auto-remirror.

897742db4bf52242985e942408b322339ff206dc

Disconnect Troubleshooting

If you are experiencing frequent auto-disconnects, you may want to increase the amount of disk space on the volume where the SyncSafe Replication queue is located or move the disk queue to a larger volume.

If you have manually changed data on the target, for example if you were testing data on the target, SyncSafe Replication is unaware of the target data changes. You must manually remirror your data from the source to the target, overwriting the target data changes that you caused, to ensure data integrity between your source and target.

Email Notification Troubleshooting

Modifying Email Settings

When you modify your e-mail notification settings, you will receive a test e-mail summarizing your new settings. You can also test e-mail notification by clicking Test. By default, the test will be run from the machine where the console is running. If desired, you can send the test message to a different e-mail address by selecting Send To and entering a comma or semicolon separated list of addresses. Modify the Message Textup to 1024 characters, if necessary.Click Send to test the e-mail notification. The results will be displayed in a message box.

Email Notification Issues

Known potential issues:

  1. E-mail notification will not function properly if the Event logs are full.
  2. If an error occurs while sending an e-mail, a message will be generated. This message will not trigger another e-mail. Subsequent e-mail errors will not generate additional messages. When an e-mail is sent successfully, a message will then be generated. If another e-mail fails, one message will again be generated. This is a cyclical process where one message will be generated for each group of failed e-mail messages, one for each group of successful e-mail messages, one for the next group of failed messages, and so on.
  3. If you start and then immediately stop the Double-Take service, you may not get e-mail notifications for the log entries that occur during startup.
  4. By default, most anti-virus software blocks unknown processes from sending traffic on port 25. You need to modify the blocking rule so that SyncSafe Replication e-mail messages are not blocked.

Log Files

Note: Service and Product Name References

Because SyncSafe Replication is powered by Carbonite OpenText, logs may retain the name OpenText Availability or OpenText Migrate; and the log contents may likewise reference the same.

SyncSafe Replication generates a number of log files for the purposes of troubleshooting and verificiation:

<<<<<<< HEAD * Double-Take log - This log records data from the Double-Take service, also referred to as the SyncSafe Replication and SyncSafe Replication engine. The Double-Take service controls the data movement functions like SyncSafe Replication and SyncSafe Replication mirroring and replication. ======= 1. Double-Take log - This log records data from the Double-Take service, also referred to as the SyncSafe Replicate and SyncSafe Replicate engine. The Double-Take service controls the data movement functions like SyncSafe Replicate and SyncSafe Replicate mirroring and replication.

897742db4bf52242985e942408b322339ff206dc * Double-Take Management Service log - This log records data from the Double-Take Management Service. It controls all non-data-movement aspects of each job. * Job log - This log records job specific messages. There is a unique job log for each job you create. * SyncSafe Replication Console log - this log records data and user interaction from the OpenText Replication Console.

Verification Log

See OG Documentation pg 71.

Windows Events Reference

See Reference Guide