Crash consistent backups and database cloning with Virtual Volumes

In the first part of this series we provided a high level view of the benefits of using Virtual Volumes enabled storage for database operations. In the second part of this series we examined in more detail how Virtual Volumes can improve the backup and recovery capabilities for business critical databases, specifically Oracle.

The backups for Oracle can be Database consistent or Crash consistent. In this part we will look at Crash consistent backup and recovery and also how database cloning is simplified by the use of VVol.

The Setup:

The setup of the infrastructure is the same as discussed in the second part of this series. Please refer to setup section for details of the infrastructure and the database configuration.

Database Crash Consistent Recovery and cloning use case Scenarios:

Crash Database Backup & Recovery using VVol Snapshots:

Crash Consistent Backup:

A crash consistent backup is the backup of a point-in-time image of an Oracle database that is equivalent to a database crash induced by a power outage, other failures or a shutdown abort.

This is the most common backup method used for storage based backups and is fully supported by Oracle as long as the following conditions are met.

From the “Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies (Doc ID 604683.1)”:

The third party vendor needs to guarantee and held accountable that their snapshots conform to all the following requirements:

Integrated with Oracle’s recommended restore and recovery operations above
Database crash consistent at the point of the snapshot
Write ordering is preserved for each file within a snapshot

Crash consistent Backup and Recovery Testing:

The following steps were used for this exercise:

A Crash consistent snapshot was taken of the database with no quiescing or interaction with the Oracle database.

2. A VMware snapshot is taken for the database virtual machine in crash consistent mode as shown in the picture below:

Figure 1: Virtual Machine snapshot of a Crash Consistent Oracle Database

On completion of the snapshot one can look at the volumes associated with the Oracle virtual machine. When the snapshot is taken each SubLun for the VMDKs have an additional copy that is created at the storage level. The number of SubLuns have now increased from 7 to 12 as explained earlier (7 SubLuns for the original VM plus 5 additional SubLuns for the VM vmdk’s)

[root@sanblaze1 ~]# grep SubLun /port0/alias0lun0 ; echo ; grep SubLun /port0/alias0lun0 | grep VMW_VVolType | echo “Number of Subluns = ” wc -l

SubLuns=1024

……..

SubLun2=d28000020000,d2a000020000:600110dac045c0450100800000800002 165888:30720 MB (339738624:62914560 blocks) 1 VMW_VvolProfile=f4e5bade-15a2-4805-bf8e-52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_GosType=oracleLinux64Guest;VMW_VVolName=Oracle-VVOL.vmdk;VMW_VVolNamespace=/vmfs/volumes/vvol:600110dac045c045-41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVolType=Data;VMW_VmID=501109af-235d-3c2a-c6d6-a11a096364a0;VMW_VvolAllocationType=4;VMW_VVolParentContainer=600110dac045c045-41000000f3b02415

SubLun7=d28000070000,d2a000070000:600110dac045c0450100800000800007 196608:30720 MB (402653184:62914560 blocks) 3 VMW_VvolProfile=f4e5bade-15a2-4805-bf8e-52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_GosType=oracleLinux64Guest;VMW_VVolName=Oracle-VVOL_1.vmdk;VMW_VVolNamespace=/vmfs/volumes/vvol:600110dac045c045-41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVolType=Data;VMW_VmID=501109af-235d-3c2a-c6d6-a11a096364a0;VMW_VvolAllocationType=4;VMW_VVolParentContainer=600110dac045c045-41000000f3b02415

SubLun8=d28000080000,d2a000080000:600110dac045c0450100800000800008 227328:30720 MB (465567744:62914560 blocks) 4 VMW_VvolProfile=f4e5bade-15a2-4805-bf8e-52318c4ce443:0;VMW_ContainerId=600110dac045c04541000000f3b02415;VMW_GosType=oracleLinux64Guest;VMW_VVolName=Oracle-VVOL_2.vmdk;VMW_VVolNamespace=/vmfs/volumes/vvol:600110dac045c045-41000000f3b02415/naa.600110dac045c0450100800000800000;VMW_VVolType=Data;VMW_VmID=501109af-235d-3c2a-c6d6-a11a096364a0;VMW_VvolAllocationType=4;VMW_VVolParentContainer=600110dac045c045-41000000f3b02415

……

Number of SubLuns = 12

4. A cloning script is then run to create a cloned DB Virtual machine from the Crash consistent VMware snapshot.

Figure 2: Virtual Machine snapshot of a Crash Consistent Oracle Database

5. On database startup Oracle automatically performs crash recovery.

6. The database recovers successfully indicating that vVols based snapshots can be used for crash consistent backup and recovery. A snippet of the Alert log of the database shown below displays the media recovery steps taken:

Figure 3: Successful Oracle Database recovery from crash consistent backup

Oracle Database Cloning:

The following steps were used for this exercise:

A VMware level cloning operation is initiated to clone the running Oracle VM.

Figure 4: Cloning of an Oracle Database VM on VVol

2. The cloning operation uses a point in time snapshot of the database virtual machine in a crash consistent state and makes a copy.

3. On completion of the Clone one can look at the volumes associated with the Oracle virtual machine. The number of SubLuns have now increased from 7 to 14 as explained earlier (7 SubLuns for the original VM plus 7 additional SubLuns for the cloned VM). This clearly shows that the actual cloning happen at the storage level when VVol is leveraged.

[root@sanblaze1 ~]# grep SubLun /port0/alias0lun0 ; echo ; grep SubLun /port0/alias0lun0 | grep VMW_VVolType | echo “Number of Subluns = ” wc -l

SubLuns=1024

……..

……

Number of SubLuns = 14

4. On database startup Oracle automatically performs crash recovery.

5. The database recovers successfully indicating that VVol based cloning can simplify database cloning and refresh operations.

Figure 5: Successful Oracle Database recovery after cloning.

VVol greatly enhances Database Crash consistent Backup and Cloning capabilities:

We have seen through the two use cases that VVol enables storage level snapshots with VM granularity. This is due to the fact that every VMDK is represented by an independent virtual volume and snapshots create a point in time copy of the volume that can be used for backup, recovery and cloning activities.

Through this exercise we have shown that business critical database platforms such as Oracle RDBMS can be backed up and cloned in a crash consistent manner with ease by leveraging VVol.

In the next blog post we will examine the how SPBM (Storage Policy-Based Management) features available with VVol can be used for creating different storage tiers for business critical databases.

To learn more about Virtual Volumes and how to plan, architect and administer a business-critical Oracle environment, see the VMware vSphere Virtual Volumes: A Game Changer for Business-Critical Oracle Databases white paper.

Crash consistent backups and database cloning with Virtual Volumes

Crash Database Backup & Recovery using VVol Snapshots:

VVol greatly enhances Database Crash consistent Backup and Cloning capabilities:

Related Articles

VMware NVMeoF Virtual Volumes (vVols) on Pure Storage Flash Array for Oracle Workloads - NVMeoF vVol v/s SCSI vVol

Announcing VMware vSAN Max Storage for Business-Critical Oracle Workloads

VMware vSAN 8 Express Storage Architecture (ESA) for Oracle Workloads – Performance