While storage Snapshots can be a very powerful mechanism for fast database recovery, snapshots are not substitutes for database backups. Unlike backups, snapshots are not normally retained for prolonged periods, and depending on the change rate and capacity available, snapshots may have a Time To Live (TTL) of few hours to few days. Certain kinds of “silent” logical corruptions may not be noticed in the application for weeks or months – beyond the life cycle of most snapshots. Therefore, database backups should form part of the overall database protection strategy along with Disaster Recovery sites, and storage Snapshots.

On systems that operate continuously, however, the busy online day is usually followed by a full schedule of nightly batch jobs, report runs, or resource-intensive analytics processes. It can be challenging to create a backup window without affecting the nightly jobs, while still ensuring that backups are completed within the Service Level Objectives (SLOs).

Using PowerFlex snapshots, backup processing can be “offloaded” to a backup server, thereby not affecting any production batch workloads.

Prerequisites

This following procedure requires that the backup media be available as a filesystem share to both the main production server(s), and the backup server.

Use Case 3: Backup offloading steps

1. Create a custom storage snapshot for the backup or use an existing scheduled snapshot. Ensure the storage volumes that contain the database (including DATA, FRA and REDO disk groups) are snapped as a consistency group.

Give the snapshot a name and suffix.

2. Map the backup snapshots to a backup server, in this case “pflex05”.

3. On the Backup server, identify the newly presented snapshots, update the UDEV rules file, and reload the rules.
   
   Note: If using ASMLib, follow the steps in the Oracle documentation to create the ASMLib devices
    

Identify the newly presented Powerflex Snapshot devices

# lsblk | grep scini

Use the following example script to generate the UDEV entries for the snapshot devices (inserting the device names identified in step a)

#!/bin/ksh

#

# Simple script to generate UDEV entries

# Version 1.1

# Dell Technologies

# June 2021

#

# EDIT THE FOLLOWING LINE AND LIST ALL DEVICE NAMES

for i in scinif scinig scinih

do

c=$(expr $c + 1)

dev_id=$(/opt/emc/scaleio/sdc/bin/drv_cfg --query_block_device_id --block_device /dev/$i)

echo 'KERNEL=="scini*", SUBSYSTEM=="block", PROGRAM="/opt/emc/scaleio/sdc/bin/drv_cfg --query_block_device_id --block_device /dev/%k", RESULT=="'$dev_id'", SYMLINK+="oracleasm/snapdisk'$c'", OWNER="grid", GROUP="oinstall", MODE="0660"'

done

Example script output:

KERNEL=="scini*", SUBSYSTEM=="block", PROGRAM="/opt/emc/scaleio/sdc/bin/drv_cfg --query_block_device_id --block_device /dev/%k", RESULT=="3ab393750b18d00f-3d262a920000001c", SYMLINK+="oracleasm/snapdisk1", OWNER="grid", GROUP="oinstall", MODE="0660"

KERNEL=="scini*", SUBSYSTEM=="block", PROGRAM="/opt/emc/scaleio/sdc/bin/drv_cfg --query_block_device_id --block_device /dev/%k", RESULT=="3ab393750b18d00f-3d262a940000001e", SYMLINK+="oracleasm/snapdisk2", OWNER="grid", GROUP="oinstall", MODE="0660"

1. Append the output from the above script into the PowerFlex UDEV rules file (e.g. /etc/udev/rules.d/99-oracleasm.rules) and reload the UDEV rules

# /sbin/udevadm control --reload-rules;/sbin/udevadm trigger

4. Mount the ASM Disk Groups

5. Start the database on the backup server in mount mode.

6. Use RMAN to back up the database and archive logs. In this case the backup media is provided by a Dell EMC Data Domain system, accessed via the /orabackup filesystem share.

7. On the primary production system, use RMAN to catalog the database and archive log backups that were made on the backup server.

8. On the primary production system, backed up archive ogs can be deleted to free up space.

Use Case 3: Recovery steps

This procedure assumes that a snapshot cannot be used.

1. Identify the latest backup taken prior to the “silent” corruption occurring. In this example, we identified that data file 7 (USER.DBF) needed restoring from July 1st.

Use RMAN as shown below to identify the TAG associated with the specific backup on the date required.

2. Using RMAN, restore the datafiles(s) needed for recovery, using the backup/backup set identified in step 1.

3. Roll the datafiles(s) forward to the current point in time.

4. Open the database and continue normal operations.