You are here: Other protection information > Snapshot states

Snapshot states

A snapshot is an image of the source replica data on the target taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover from cases where corrupted source data was replicated to the target. If you are using Double-Take Availability snapshots, when failover is triggered, you can use the live target data at the time of failover or you can failover to a snapshot of the target data.

Snapshots are not available for all job types.

When Double-Take Availability transitions from a good state to a bad state, it will automatically attempt to take a snapshot of the data before it leaves the good state and enters the bad state. For example, if your data is in a good state and you start a mirror, before the mirror is started, Double-Take Availability will automatically take a snapshot of the target. In the event the mirror fails to complete, you will have a snapshot of the data on the target when it was in its last good state. Only one automatic snapshot per job is maintained on the target. When an automatic snapshot is taken, it replaces any previous automatic snapshots.

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.

Mirror started

State—Bad
Description—Mirroring has started, but is not complete. The data on the source and target will not be synchronized until the mirror is complete.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will be delayed until the mirror is complete before taking a snapshot.
User interaction required for manual snapshots—Wait until the mirror is complete and the data is in a good state, then take a manual snapshot.

Mirror stopped

State—Bad
Description—Mirroring has stopped without completing. The data on the source and target will not be synchronized until the mirror is complete.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will be delayed until the mirror has been restarted and is complete before taking a snapshot.
User interaction required for manual snapshots—Restart the mirror, wait until it is complete and the data is in a good state, and then take a manual snapshot.

Mirror complete

State—Good
Description—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.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally.
User interaction required for manual snapshots—Manual snapshots can be taken normally.

Write operation retried

State—Good
Description—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.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally, although the operation that is being retried will not be included in the snapshot.
User interaction required for manual snapshots—Manual snapshots can be taken normally, although the operation that is being retried will not be included in the snapshot.

Write operation dropped

State—Bad
Description—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.
Automatic action taken for scheduled and automatic snapshots—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.
User interaction required for manual snapshots—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

State—Good
Description—An operation that was retrying on the target has been successfully written to the hard drive.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally.
User interaction required for manual snapshots—Manual snapshots can be taken normally.

Target restarted with job persistence

State—Good
Description—The target service was able to persist job information prior to restarting.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally.
User interaction required for manual snapshots—Manual snapshots can be taken normally.

Target restarted without job persistence

State—Bad
Description—The target service has been restarted and was unable to persist job information, therefore, operations that were in the queue have been lost.
Automatic action taken for scheduled and automatic snapshots—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 job is configured to auto-remirror on auto-reconnect. Scheduled snapshots will be delayed until the target data is back in a good state.
User interaction required for manual snapshots—Start a mirror, wait until it is complete and the data is in a good state, and then take a manual snapshot.

Restore required

State—Good or bad
Description—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.
Automatic action taken for scheduled and automatic snapshots—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.
User interaction required for manual snapshots—Restore the target data back to the source or override the Restore Required state by performing a mirror. Once the restoration or mirror is complete, manual snapshots can be taken normally.

Snapshot reverted

State—Good or bad
Description—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.
Automatic action taken for scheduled and automatic snapshots—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.
User interaction required for manual snapshots—Restore the target data back to the source or override the Snapshot Reverted state by performing a mirror. Once the restoration or mirror is complete, manual snapshots can be taken normally.

Restore complete

State—Good
Description—Because the restoration is complete, the data on the source and target is synchronized.
Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally.
User interaction required for manual snapshots—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.

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 protected by your job, 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.