Related Topics
A snapshot may not necessarily be useful if the data on the target is in a bad state. You only want snapshots of data that is in a good state. Therefore, you need to understand when the data is in a good or bad state.
| Action | State | Description | Automatic Action Taken for Scheduled and Automatic Snapshots | User Interaction Required for Manual Snapshots |
|---|---|---|---|---|
| Mirror Started | Bad | Mirroring has started, but is not complete. The data on the source and target will not be synchronized until the mirror is complete. | Scheduled and automatic snapshots will be delayed until the mirror is complete before taking a snapshot. | Wait until the mirror is complete and the data is in a good state, then take a manual snapshot. |
| Mirror Stopped | Bad | Mirroring has stopped without completing. The data on the source and target will not be synchronized until the mirror is complete. | Scheduled and automatic snapshots will be delayed until the mirror has been restarted and is complete before taking a snapshot. | Restart the mirror, wait until it is complete and the data is in a good state, and then take a manual snapshot. |
| Mirror Complete | Good | Because the mirror is complete, the data on the source and target is synchronized. Double-Take Availability will take a snapshot while the data is in a good state. | Scheduled and automatic snapshots will occur normally. | Manual snapshots can be taken normally. |
| Write Operation Retried | Good | An operation cannot be written to the hard drive on the target. For example, the file could be in use by another application on the target. | Scheduled and automatic snapshots will occur normally, although the operation that is being retried will not be included in the snapshot. | Manual snapshots can be taken normally, although the operation that is being retried will not be included in the snapshot. |
| Write Operation Dropped | Bad | An operation could not be written to the hard drive on the target, even after multiple retries. For example, the file could be in use by another application on the target. |
An automatic snapshot will be taken just prior to the operation being dropped. Scheduled snapshots will be delayed until the target data is back in a good state. |
Start a mirror, wait until it is complete and the data is in a good state, and then take a manual snapshot. |
| Write Operation Succeeded | Good | An operation that was retrying on the target has been successfully written to the hard drive. | Scheduled and automatic snapshots will occur normally. | Manual snapshots can be taken normally. |
| Target Restarted with Connection Persistence | Good | The target service was able to persist connection information prior to restarting. | Scheduled and automatic snapshots will occur normally. | Manual snapshots can be taken normally. |
| Target Restarted without Connection Persistence | Bad | The target service has been restarted and was unable to persist connection information, therefore, operations that were in the queue have been lost. |
An automatic snapshot will be taken after the target restarts, if the target data was in a good state prior to the target restart and the connection is configured to auto-remirror on auto-reconnect. Scheduled snapshots will be delayed until the target data is back in a good state. |
Start a mirror, wait until it is complete and the data is in a good state, and then take a manual snapshot. |
| Restore Required | Good or Bad | The data on the target no longer matches the data on the source because of a failover. This does not necessarily mean that the data on the target is bad. | Scheduled and automatic snapshots will be delayed until a restore is completed or the Restore Required state is overruled by a mirror. Once the restoration or mirror is complete, automatic and scheduled snapshots will occur normally. | Restore the target data back to the source or overrule the Restore Required state by performing a mirror. Once the restoration or mirror is complete, manual snapshots can be taken normally. |
| Snapshot Reverted | Good or Bad | The data on the target no longer matches the data on the source because a snapshot has been applied on the target. This does not necessarily mean that the data on the target is bad. | Scheduled and automatic snapshots will be delayed until a restore is completed or the Snapshot Reverted state is overruled by a mirror. Once the restoration or mirror is complete, automatic and scheduled snapshots will occur normally. | Restore the target data back to the source or overrule the Snapshot Reverted state by performing a mirror. Once the restoration or mirror is complete, manual snapshots can be taken normally. |
| Restore Complete | Good | Because the restoration is complete, the data on the source and target is synchronized. | Scheduled and automatic snapshots will occur normally. | Manual snapshots can be taken normally. |
To be completely assured that your data on the target is good, automatic and scheduled snapshots only occur when the data is in a good Double-Take Availability state. However, manual snapshots can be taken during any state. There are instances when you may want to take a manual snapshot, even if the target data is in a bad state. For example, if you drop an operation, that does not necessarily mean your data on the target is corrupt or the target would be unable to stand in for the source in the event of a failure. A snapshot of a bad state may be useful and usable, depending on your environment. If your source is a file server and an operation has been dropped, it is just one user file that is out-of-date. All of the remaining target files are intact and can be accessed in the event of a failure.
However, if your source is an application server and an operation has been dropped, that one file could cause the application not to start on the target in the event of a failure. In these cases, manual snapshots of a bad state depend on the context of your environment.
| Note: | Because the driver for Volume Shadow Copy is started before the driver for Double-Take Availability, if you revert any files on the source that are contained in your replication set, Double-Take Availability will not be aware of the revert and, therefore, the file change will not be replicated to the target. The file change will be mirrored to the target during the next mirroring process. |