The script makes a GET request to the Phoenix Backup Store to get the status of the backup mount. For example: curl -X GET http://192.0.2.1:9090/druva-phoenix/v1/mounts/testmount/backup 2> /dev/null

The Phoenix Backup Store returns a JSON object. For example: { "error_code": 0, "error_msg": “”, "result": { "mount_name": "testmount", "is_reached_max_snapshots": false, } }

This is a sample response that the script receives if there is no issue with the backup mount. If there is no issue with the backup mount, then RMAN can start a database backup. The JSON object is returned with an error if there is an issue with the Phoenix Backup Store. Druva recommends that the next step is not performed if "is_reached_max_snapshots" is returned as true. In template script workflow, the script execution stops if "is_reached_max_snapshots" is returned as true.

The script makes a POST request to the Phoenix Backup Store. Based on the response, it runs RMAN commands to start the database backup and write the backup data on the backup mount. For example: curl -X POST http://192.0.2.1:9090/druva-phoenix/v1/mounts/testmount/backup 2> /dev/null

The Phoenix Backup Store returns a JSON object. For example: { "error_code": 0, "error_msg": “”, "result": { "mount_path": "/Phoenix/testmount/oracle_data", "mount_name": "testmount", "mount_params": {“timeo”:1200, “retrans”:5}, } }

This is a sample response that the script receives if there is no issue with the backup mount, and then runs RMAN commands that:

The JSON object is returned with an error if there is an issue with the backup mount or with the Phoenix Backup Store configuration.

The script makes the following POST request after:

The script makes this request to notify Phoenix Backup Store to upload the RMAN logs to the Druva Cloud along with the recovery point of the Oracle RMAN backup. For example:

curl -X POST -H "Content-Type: multipart/form-data" -F "file=/home/test-usr/rman-log-directory/rman_full_backup_$file_stamp.log" -F mountpoint=/local/testmount -F platform=linux http://192.0.2.1:9090/druva-phoenix/v1/mounts/testmount/uploadlog 2> /dev/null

The Phoenix Backup Store returns a JSON object. For example: { "error_code": 0, "error_msg": “”, "result": { "mount_name": "testmount", } }

This is a sample response that the script receives if there is no issue with the backup mount or the Phoenix Backup Store. The JSON object is returned with an error if there is an issue with the backup mount or with the Phoenix Backup Store configuration. If you are using a custom script, this API request is optional. However, Druva recommends using this API request since this request lets Druva map a database to its files in the Oracle RMAN backup. The mapping between a database and its file is useful when an administrator runs a restore job. If this mapping is available, the administrator can see files in a database and additional files backed up.

After the request to upload RMAN logs is successful, the script makes a PUT request to notify the Phoenix Backup Store that the Oracle RMAN backup was written successfully to the backup mount and it can upload the recovery point to the Druva Cloud. For example: curl -X PUT http://192.0.2.1:9090/druva-phoenix/v1/mounts/testmount/backup 2> /dev/null

The Phoenix Backup Store returns a JSON object. For example: { "error_code": 0, "error_msg": "", "result": { "snap_name": "UID_1", "mount_name": "testmount", } }

This is a sample response that the script receives if there is no issue with the backup mount or Phoenix Backup Store after RMAN completes writing Oracle RMAN backup successfully. The successful PUT request also updates the Phoenix Backup Store services to create a ZFS recovery point of the Oracle RMAN backup and upload the recovery point to the Druva Cloud. The JSON object is returned with an error if there is an issue with the backup mount or with the Phoenix Backup Store configuration.

After the Oracle RMAN backup is written successfully on the Phoenix Backup Store, the PUT request updates Phoenix Backup Store services that: