Disaster Recovery Process

When configured, disaster recovery works as follows:

1. At regular intervals, the production site takes a snapshot of filesystem data from its active server instances and sends this snapshot to an appliance at the backup site.
   Under normal, fully operational behavior, Production-A sends instance 0 snapshots to Backup-A, and Production-B sends instance 1 snapshots to Backup-B.
2. If Production-A fails, both EMS server instances 0 and 1 are running on Production-B. Assuming both backup site appliances are available, Production-B begins sending instance 0 snapshots to Backup-A, and continues sending instance 1 snapshots to Backup-B.
   Warning: You should not start the EMS server instance on an appliance while it is acting as a backup. In case of a recovery event, the data from previous activity using those servers will be lost.
3. If both Production-A and Production-B fail, you must manually initiate the DR recovery procedure at the backup site. See Recovering to a Backup Site for details.
   Note that disaster recovery does not imply that there is no data loss. Any activity that occurred after the most recent snapshot may be lost. The recovery process erases all prior data from the backup site and overwrites it with the data from the production site snapshot.
4. If at the time of a DR event only one appliance is available at the backup site, the disaster recovery process can be initiated on the available appliance. For example, if the backup site experienced an FT event or planned downtime on one of the appliances, the client operations can still be recovered at the backup site.
5. When the production site is restored, it must be reactivated manually using the dr-restore command.