Data is considered to be consistent if the system or application using it can be successfully restarted using this data. For example, if the data belongs to a file system, the data is consistent if the chkdsk command can be run successfully on it. If the data contains a database, the data is consistent if the database recovery program can be run on it and the database can be restarted.

The data on the Secondary is consistent if it correctly reflects the data on the Primary at some time in the past. Volume Replicator tries to maintain the data at the Secondary in a consistent state at all times.

Data is considered consistent only if it contains all the updates up to some point-in-time and none of the updates that come after that point. For example, in the case of a file system, the most recently created files may be missing when it is abruptly stopped. In the case of a database, one or more of the most recently committed transactions may be missing.

Data that is up-to-date contains all the latest changes. For example, if you replicate a database, all the committed transactions will be available on the Secondary host.

You can choose whether you want the data on the Secondary to always be up-to-date by using either the asynchronous or synchronous mode of replication.

The synchronous mode of replication ensures that the data on the Secondary is always up-to-date. However, in the asynchronous mode Volume Replicator cannot guarantee that the data is up-to-date. Another mode of replication that Volume Replicator supports is synchronous override. In this mode, Volume Replicator replicates synchronously as long as the required network bandwidth is continuously available. However, if the network becomes unavailable, then Volume Replicator replicates asynchronously. Note that Volume Replicator maintains write-order fidelity irrespective of the mode of replication used.