5.0

About Reprotect
With reprotect, you can protect recovered virtual machines after a recovery back to the original protected site,
including reversing the direction of replication.
Reprotect uses the protection information that was established before a recovery to reverse the direction of
protection. You can complete the Reprotect process after a recovery is finished. If the recovery finishes with
errors, you must fix all errors and rerun the recovery, repeating this process until no errors occur.
IMPORTANT Reprotect is supported only for array-based replication. vSphere Replication (VR) reprotect is not
supported. If a recovery plan contains VR groups, remove those groups before you run a reprotect operation.
About Failback
A failback is an optional procedure that restores the original configuration of the protected and recovery sites
after a recovery. You can configure and run a failback procedure when you are ready to restore services to the
protected site.
Failback is a term for a collection of procedures that you can use to restore the original configuration of the
protected and recovery sites after a recovery. Anytime errors occur during a failback, you must resolve those
errors and repeat the failback until the process completes successfully.
After a recovery has occurred, a failback can be completed. Failbacks have three phases. For example, at the
start, A is the protected site and B is the recovery site. A recovery occurs, migrating the virtual machines to
site B. You might choose to run a failback. At that point, the following phases occur:
n
Perform a reprotect. The former recovery site, B, is made the protected site and information about
protection is used to establish protection with A being the recovery site.
n
Perform a planned migration. The virtual machines are recovered to site A. To avoid interruptions in
virtual machine availability, you may want to run a test before actually completing the planned migration.
If errors are identified by the test, these issues can be resolved before actually performing the planned
migration.
n
Perform a second reprotect, this time with site A being protected with site B as the recovery site.
About the Site Recovery Manager Database
The SRM server requires its own database, which it uses to store data such as recovery plans and inventory
information.
The SRM database is a critical part of any SRM installation. The database must be created and a database
connection established before you can install SRM. If you are updating SRM to a new release, you can use the
existing database connection, but you must back up the database first, otherwise, you will not be able to revert
to the previous release of SRM.
The SRM database at each site holds information about virtual machine protection groups and recovery plans.
SRM cannot use the vCenter database because it has different database schema requirements, though you can
use the vCenter database server to create and support the SRM database. Each SRM site requires its own
instance of the SRM database. Before you can install SRM, the database must exist .
When you install SRM, you specify the following information about how SRM connects to the database.
Server Type
The type of database server being used.
DSN
The DSN (database source name) specifies a data structure that contains
information about the SRM database that the ODBC driver needs to connect to
that data source.
Site Recovery Manager Administration Guide
16 VMware, Inc.