Your address will show here +01 (414) 230 - 5550

Solution Architectures


The diagram below shows the architecture of a proposed disaster recovery solution. At the production site, DR Prophet® creates a thinly provisioned mirror volume (“SAN Mirror”) for each protected disk using a local storage server. An application-aware agent running on the application server ensures the consistency and integrity of the mirrored data. All subsequent backup or disaster recovery related activities such as snapshots or DR rehearsal are performed against the SAN Mirror to avoid any performance impact on the production system.

  • Text Hover
DR Prophet® also creates a block-level remote replica (“Remote Replica”) of the SAN Mirror at the DR site. All IP traffic transmitted over the Internet is fully WAN-optimized. The DR Prophet® instance run at the DR site takes snapshots and performs DR rehearsal against the Remote Replica entirely independent of the production site.

This architecture also includes a complete set of standby servers that mimic the exact configurations at the production site. In case of a catastrophic failure of the production servers, business operation can be quickly resumed at the DR site using these standby servers and the data on the Remote Replica.

Recovery Point Objective (RPO)


With traditional tape-based systems, backups are typically performed once at the end of each business day to avoid slowing down the production system due to resource contention. In addition, once started, backing up data on tapes takes hours to complete, which also makes tape backup during business hours infeasible.

  • Text Hover
Application-Aware Snapshots

Snapshots taken randomly without coordinating with the applications will often leave common business applications like Oracle or Microsoft SQL Server in a crash consistent state in the snapshot image. DR Prophet® agent actively communicates with the application and puts it in a quiescent state, an online backup state, before a snapshot is taken. This essentially ensures that the state of the database remains consistent in the snapshot and the point-in-time image can be used immediately to resume the application without having to go through the tedious and time consuming steps such as verification or replaying database log files.

Recovery Time Objective (RTO)


To recover from a non-catastrophic minor failure such as file corruption or accidental deletion of a folder, simply select a known-good point-in-time snapshot and mount it on the application server and it will appear as a new disk with all the data the application can use immediately.To recover from a non-catastrophic minor failure such as file corruption or accidental deletion of a folder, simply select a known-good point-in-time snapshot and mount it on the application server and it will appear as a new disk with all the data the application can use immediately.
  • Text Hover
For catastrophic server or hard disk failures, instead of having to wait for the hardware vendor to bring the failed hardware back online, a virtualized copy of the server can be spun up on the standby virtualization server to rapidly resume the service using the SAN Mirror. When the failed hardware is finally replaced, data can be transferred back from the SAN Mirror.

 

Failure ScenarioDR Prophet® ActionLocal RecoveryRTO
Loss/corrupted files or foldersValidationYes10 minutes
Database corruptionMount last known-good snapshotYes20 minutes
OS/Application crashFull system recovery including boot driver or P2V/V2V on standby VMYes15 minutes
Failed storage hardwareFull data mirror available (LVM*)Yes0 minutes
Site lossLaunch DR site into production within 1 HourNo1~2 hours
* LVM mirror is for AIX protection only.
Share