How is the data from Primary to secondary confirmed

I think you are on the wrong forum perhaps?

This forum is only for Enterprise Vault

Moved to the Volume Replication forum, as I belive that's the product you're searching advice for.

Cheers

thanks Miehel
-------------------

Hello SUdhir,

There are a few different methods of replication (Synchronous, Synchronous Overrride, and Asynchronous), and VVR behaves differently in regards to determining data consistency between the source and target depending on what option is chosen. I'll provide a bit of detail on each of these replication options, and will also include some information on commands that can be run to determine the status of replication.

Synchronous Replication:
This is a mode of replication where the disk writes are written to the secondary server, and once confirmed, the write is made on the primary and the process continues on. This mode is normally done in environments where having an exact replica of the primary server is necessary. In these cases, during a fail-over to the secondary, it would be known that the secondary would have all the writes that the primary had.

The easiest description of this is: If any changes are not committed to both servers (source and target), the change is rolled back and is commited to NO servers. In this case, the above application making the write would fail unless both (or all) servers in the replication configuration were properly updated.

Synchronous replication is needed in environments where there can not be any risk that changes that occurred on the primary will not be on the secondary when it comes up in the case of a disaster.

Because changes are being made to the secondary before success is returned to the above application making the write, disk access will only be as fast as the WAN link being used for replication. If the link is slow and can't handle the load, it will slow down the applications on the primary server which would be noticeable to the users.

Another major concern with this configuration is if the network connection to the secondary failed. In these cases, I/O would stop on the secondary until the link was re-established and replication could begin again. To help avoid this, there is another Synchronous option called ‘Synchronous Override’.

Synchronous Override:
The synchronous override mode of replication is a mode where replication is synchronous, as long as the network is available. If the replication network becomes unavailable, then replication pauses but there is no discruption to the primary and writes continue to be written successfully (and stored in the Storage Replicator Log that tracks changes). When the network link comes back online, a resynch process occurs where changes that were stored in the Replicator Log are transferred and applied to the secondary (using asynchronous mode). As soon as all changes have been applied and the resynch is complete, the replication reverts back to Synchronous mode.

If a network outage did occur, followed by a primary site failure, the data on the secondary would be consistent, but would be missing any writes that occurred after the replication network link when down and before the primary site failed.

Synchronous replication should be used in enviornments where there is no room for data loss and if the primary goes down, the secondary volumes must be identical to the primary. In addition, it should only be used in environments with enough bandwidth to handle writes as fast as they occur on the primary, otherwise, users will notice a slowdown when making writes to the server.

If there is room for a slight loss of data when a site failure occurs and/or the WAN link used for replication is not fast enough to handle the server load, then asynchronous replication should be used.

Asynchronous Replication:
Changes are always written to the primary and writes to the secondary occur as fast as the network link allows (which can approach real-time when a large enough network pipe exists between the servers). In these cases, no matter what is happening with replication, it will never cause performance issues on your primary server (i.e. I/O will never be stalled). In this case, all writes are made to the Storage Replicator Log (SRL) and those changes are transmitted to the secondary as fast as possible to be applied. However, this means that the primary returns a successful write to the application as soon as the write has succeeded on the primary server, and not when it happens on the secondary. This means if the primary site failed after a write had just been made, migrating to the secondary would not have that change.

It's important to note that after the initial synch in replication, VVR maintains write order fidelity so with asynchronous replication you may experience data loss for writes that never made it across to the secondary (if the primary site went down). If this were Exchange for example, you may be missing the last few emails that came in before the primary site went down, but there would be no corruption because the writes to the primary occur in the exact same order on the secondary, so the data always remains consistent, it just may be behind.

======================================================================================
Once the replication mode is determined, there are several ways to check on the status of replication:

Note: You did not provide the version of SFW being used, but I have included a link to the Admin Guide for VVR which you can review for more information on the details provided below (ftp://exftpp.symantec.com/pub/support/products/Sto...).

1. GUI - On page 146 of 441 in the pdf (or Pg 130 of the printed manual), you will see documentation on how to use the Veritas Enterprise Administrator (VEA) to monitor the status of replication in real-time.

2. CLI - The same information seen in the GUI can be seen from the command line using the vxrlink stats command (on the primary server). YOu can read more about this on page 154 of 441 (Pg 138 of the printed manual).

3. A utility called Vxrsync can be used to compare the source and target volumes, but this command must be run when the volumes are offline (i.e. If Exchange, take Exchange down for an outage window to allow the vxrsync to compare the source and target. If changes are occurring while this command runs, it will always find differences and the results wouldn't be valid. This utility is explained in the Admin Guide on Page 422 of 441 (Appendix A).

4. You can also use the FlashSnap option in SFW which would allow you to create Snapshots of the Exchange volumes on the secondary site. These could be snapped off, and eseutil run against them to verify consistency, and once complete, they can be snapped back, awaiting the next time to be snapped for a consistency check. This of course would require twice the amount of disk space on the secondary, but gives you another method for confirming integrity.

Lastly, there are private fixes for VVR (post 5.0 and 5.1) that will need to be applied as they are serious issues that could result in data loss in specific situations.

If running 5.1, ensure that the following public patch is applied: http://support.veritas.com/docs/311479

If running 5.0, ensure that the RP2 public patch is applied:

SFW 5.0 RP2 (32-bit):
http://support.veritas.com/docs/319690

SFW 5.0 RP2 (64-bit):
http://support.veritas.com/docs/319691

I hope this helps. If you require any further specific detail, please let me know.

Cheers,
rhanley