This topic describes how to map from backup and recovery requirements to solutions.
With requirements and detailed knowledge of the deployment architecture, we can map to solutions tailored for the features provided by the underlying infrastructure.
Based on these failure points and recovery features, you can use the following table to map requirements to architectural components: VMware (V), Delphix (D), or storage (S). This can drive implementation based on infrastructure capabilities and recovery objectives.
|Fault Recovery Features|
|Server Failure||V||-||V S D||-|
|Storage Failure||-||-||V S D||V S|
|Site Failure||-||-||V S D||V S|
|Administrative Error||-||V S||-||V S|
Recovery Point Objective (RPO)
|Clustering||Zero||All changes committed to disk are automatically propagated to the new server. Any pending changes in memory are lost.|
|Replication||Near zero||Most solutions offer scheduled replication, but many can offer continuous replication with near-zero data loss.|
|Snapshots||Snapshot period (for example, one hour)||Given their relatively low cost, snapshots tend to be taken at a higher frequency than a traditional backup schedule.|
|Backup||Backup period (for example, one day)||Backup policies can be configured in a variety of ways, but even with incremental backups, most deployments operate no more frequently than once a day because of the cost of full backups, and the impact of incremental backups on recovery time.|
Recovery Time Objective (RTO)
|Clustering||Near zero||VM clustering with the Delphix Engine provides near zero downtime in the event of failure, but clients may be briefly paused or interrupted.|
|Replication||15 minutes||The target side environment is kept in hot standby mode, so it is relatively quick to switch over to the target environment. Depending on the scope of the failure, however, some configuration information may need to be changed on the target side prior to enabling operation.|
|Snapshots||15 minutes||The Delphix Engine can be rolled back to a previous state. Changes made to systems external to the Delphix Engine (for example, deleting a VDB) can cause inconsistencies after rollback.|
|Backup||Hours or days||Restoring a full backup can be very time consuming. In addition to having to read, transfer, and write all of the data, the same process will need to be run for each incremental backup to reach the objective point.|
Recovery Time Granularity
Only the current system state can be recovered.
|Replication||None||Only the nearest replicated state can be recovered, unless combined with snapshots.|
|Snapshots||Snapshot period (for example, one hour)||Determined by the snapshot schedule.|
|Backup||Backup period (for example, one day)||Determined by the backup schedule.|