Home > Storage > PowerFlex > White Papers > Dell APEX Block Storage for AWS: Backup and Recovery using DDVE and DD Boost Oracle RMAN Agent > Backup procedure
The backup procedure described in the example below is based on a crash-consistent image of the application volumes using PowerFlex consistent snapshots. This method is often referred to as storage-consistent backup. This method provides a simple data protection method that can be automated and used frequently without any coordination with the application. The backup data can then be used to start the application as if it sustained a crash or power-failure. The application simply opens to the point-in-time the snapshot was taken but cannot be recovered further.
The alternate application-consistent backup (not covered in this example) requires that the application is quiesced (for example, MongoDB or PostgreSQL hot backup) to allow the creation of backups that their image can be used to recover the database using additional transaction logs. Such backups can be also automated, though require coordination with the application so it can be quiesced for the few seconds it takes to create the snapshot. In addition, transaction logs are saved in case they are needed for application data recovery.
The example below demonstrates a complete preservation of the PowerFlex volumes data using binary images created using the Linux ‘dd’ command. That images are then copied to BoostFS as a backup. The alternative method (not covered in this example) is to mount the snapshot volumes to the backup host, only copy the application files to BoostFS instead of a binary image of the whole PowerFlex volume.
Any of these methods can be used based on need and application type. The following example demonstrates the most generic backup option to BoostFS.
The high-level steps for the generic PowerFlex volumes backup procedure includes:
Note: The Linux dd command enables streaming (copying) data from one block device or file to another. Use the Linux dd command to read from each PowerFlex snapshot volume and write an image file (binary file) to the BoostFS mounted file system using the S3 object store, which allows generic applications backup to take advantage of DD Boost features.
sysadmin@ddvs# user add <user_name> password <password> role none |
sysadmin@ddve# ddboost user assign <user_name>
sysadmin@ddve# ddboost user show |
sysadmin@ddve# ddboost storage-unit create <storage_unit_name> user <user_name> |
sysadmin@ddve# ddboost storage-unit show |
[root@backup-host ~] # rpm -iv DDBoostFS-7.6.0.7-685537.rhel.x86_64.rpm |
The DD BoostFS installation files are in the following default path: /opt/emc/boostfs/
[root@backup-host ~] # /opt/emc/boostfs/bin/boostfs lockbox set -u <ddboost_user_name> -d <DDVE_hostname_or_IP_Addr> -s <storage_unit> |
The lockbox encrypted files are in the following path: /opt/emc/boostfs/lockbox/
[root@backup-host ~] # mkdir -p /mnt/<mount_name> [root@backup-host ~] # /opt/emc/boostfs/bin/boostfs mount -d <DDVE_Host_name_or_IP_Addr> -s <storage_unit> /mnt/<mount_name> |
Most applications distribute data across multiple volumes or LUNs. PowerFlex allows multiple volumes to be selected to form a consistency group. Snapshots of a consistency group are guaranteed to be from precisely the same point in time and can be used to capture a crash-consistent snapshot-based backup across multiple volumes.
Figure 14. PowerFlex volume snapshot
Figure 15. Snapshot consistency group
[root@backup-host ~] # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT scinia 252:32 0 800G 0 disk └─scinia1 252:33 0 800G 0 part scinib 252:48 0 800G 0 disk └─scinib1 252:49 0 800G 0 part scinic 252:64 0 704G 0 disk └─scinic1 252:65 0 704G 0 part scinid 252:80 0 704G 0 disk └─scinid1 252:81 0 704G 0 part nvme0n1 259:0 0 100G 0 disk ├─nvme0n1p1 259:1 0 1M 0 part └─nvme0n1p2 259:2 0 100G 0 part / [root@backup-host ~] # |
[root@backup-host ~] # CMD="sudo dd if=/dev/scinia of=/mnt/oraclebfs/scinia_day1.img bs=1M oflag=direct status=progress" [root@backup-host ~] # echo $CMD [root@backup-host ~] # time $CMD |
Note: Often, the DDVE Amazon EC2 instance CPU usage determines the copy rate. Because different DDVE licenses support a different number of CPU cores (see the DDVE documentation for exact numbers), the number of Linux dd sessions that can be run simultaneously depends on the type and number of DDVE instances deployed.