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

 

Mirror stopped

 

Mirror complete

 

Write operation retried

 

Write operation dropped

 

Write operation succeeded

 

Target restarted with job persistence

 

Target restarted without job persistence

 

Restore required

 

Snapshot reverted

 

Restore complete

 

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.