Recovery Time objective and Recovery Point Objective

Whenever we design DR solution, the main point comes what is RTO and RPO. Lot of time we confused that what is the difference between them

Recovery Point Objective (RPO) describes the interval of time that might pass during a disruption before the quantity of data lost during that period exceeds the Business Continuity Plan’s maximum allowable threshold or “tolerance.” Example: If the last available good copy of data upon an outage is from 18 hours ago, and the RPO for this business is 20 hours then we are still within the parameters of the Business Continuity Plan’s RPO. In other words it the answers the question – “Up to what point in time could the Business Process’s recovery proceed tolerably given the volume of data lost during that interval? “

Recovery Time Objectives (RTO): The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity. In other words the RTO is the answer to the question: “How much time did you take to recovery after notification of business process disruption.

Make sure you determine the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each workload, so when you’re creating your business continuity and disaster recovery plans, your backup and recovery policies are aligned with your business priorities.

Advance config parameter of esxi for DR

Available in vsish nodes, These parameters are usable while configuring DR on ESXi.:

ESX server provides two different mechanism to access copies of VMFS volumess. These are two advanced configuration parameters:



Note: This is for information, we don’t need to touch these parameters while using SRM

These two configuration parameters control the behavior of the ESX VMkernel when presented with copies of a VMware file system(VMFS volume)

/config/LVM/intOpts/> get /config/LVM/intOpts/EnableResignature

Vmkernel Config Option {    Default value:0    Min value:0    Max value:1    Current value:0    hidden config option:1   

Description:Enable Volume Resignaturing. This option will be deprecated in future releases. }

vsish />  /config/LVM/intOpts/> get /config/LVM/intOpts/DisallowSnapshotLun Vmkernel

Config Option {    Default value:1    Min value:0    Max value:1    Current value:1    hidden config option:1 

Description:Disallow access to snapshot LUN if resignaturing is off. This is ignored if resignaturing is on. This option will be deprecated in future releases.

If LVM.DisallowSnapshotLun is set to 0,the copy of the data is presented with same level name and signature as the source device.However,caution be exercised in environments where an ESX has access both source and target device,in this case parameter should be left at its default value of 1.

If LVM.EnableResignature is set to 1, the VMFS volume holding the copy of the Vmware file system is automatically resignatured with the computed signature (using the UID and Lun number of target device).In additon users will notice in Virtual Center that VMFS lavel is appended to inclued “snap-x”,where x is a hexadecimal number that can be 0x2 to 0xfffffff.The default value of this parameter is 0 . If this parameter is changed to 1, the advanced pareameter LVM.DisallowSnapshotLun is ignored.