Skip to main content

How can we help you?

Druva Documentation

About RMAN hosts, Phoenix Backup Store, Administrators, and Retention

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite


This article provides information about:

  • How the Phoenix Backup Store works with Oracle Recovery Manager (RMAN) host
  • The administrators who handle the backup and restore jobs
  • The period for which the Druva Cloud will retain snapshots

Phoenix Backup Store

The Phoenix Backup Store is an Ubuntu based NAS device with Druva provided Phoenix Backup Store Debian package installed on it. After the administrators set up the NAS device, install the Debian package, and activate the Debian package on the device:

  • The NAS device is configured as a Phoenix Backup Store
  • It is registered with Druva
  • It creates a persistent connection with the Druva Cloud

When an administrator adds a backup mount on the Management Console, it is created on the Phoenix Backup Store as a shared directory over the network. The shared directory serves as the mount point point, and the Oracle Database Administrator has to map it to the host where RMAN is running. When a backup job is run using RMAN, it creates an Oracle RMAN backup and stores it on the backup mount. The RMAN requires the read and write permissions on the backup mount.

RMAN hosts

Typically, the backup and restore of Oracle databases is handled using an Oracle provided backup and recovery manager call RMAN. RMAN provides utilities to the Oracle Database Administrators to run backup jobs of databases and create Oracle RMAN backups. The RMAN is connected to the databases, and a Database Administrator runs a backup job using it. The host on which the RMAN is running is called the RMAN host, and the backup mount is mapped to the host. After a backup job is run, RMAN creates an Oracle RMAN backup and stores it on the backup mount. 


Two administrators are involved in the backup and restore of Oracle databases:

  • Oracle Database Administrators
  • Druva administrators

Oracle Database Administrators

Oracle Database Administrators use RMAN to run backups. They define when a backup job is run, and they use Druva provided APIs and scripts to ensure that the Oracle RMAN backups are stored on the backup mount.

Druva administrators

Druva administrators perform the following tasks:

  • Create Organizations on the Management Console
  • Create administrative groups on the Management Console
  • Deploy and register a Phoenix Backup Store under an Organization on the Management Console
  • Assign administrative groups to Phoenix Backup Stores
  • Create backup mounts on the Phoenix Backup Store using the Management Console
  • Select a storage on the Druva Cloud for the snapshots
  • Provide the IP addresses of the RMAN hosts that can access and read or write to the backup mount 
  • Provide a bandwidth available to the Phoenix Backup Store for uploading the snapshots to the Druva Cloud
  • Define the retention period for the snapshots of the Oracle RMAN backups stored on the backup mount on the Management Console
  • Run restore jobs on the Management Console
  • Edit name, disable backups, change administrative groups, upgrade clients of the Phoenix Backup Store
  • Re-register Phoenix Backup Stores if it gets disconnected from the Druva Cloud for reasons such as a hardware refresh. 

For more information on the administrators, see Manage administrator accounts


When an administrator adds a backup mount to a Phoenix Backup Store, the administrator provides retention settings. When a Database Administrator runs a backup job, RMAN creates an Oracle RMAN backup and stores it on the backup mount. The Phoenix Backup Store that hosts the backup mount creates a snapshot of the Oracle RMAN backup and uploads it to the Druva Cloud.

Retention defines the rules for retaining your backups (snapshot or recovery point)  within the storage. Use the retention period to define the duration for which you want to retain your historical backups.

The objective of retention is to keep important data for future access, depending on how critical it is. Retention also ensures that backups that are no longer required are cleaned from your storage periodically, resulting in less storage utilization and costs.

Retention should consider the value of your data and the compliance requirements. The different types of data will be retained for different durations. For example, a bank's retention period for customers' financial records is different from facilities inventory records.

The main factors to consider while defining a retention period are:

  • Compliance requirements
  • Storage costs
  • Type of data

Retention period settings

Druva follows the Grandfather-Father-Son (GFS) retention model wherein, in case of an overlap, the retention setting of the longer period (Son-Father-Grandfather relation) is considered. The snapshot is expired as per the settings of the higher period.  For example, in case there is an overlap between the daily and weekly retention period, the weekly retention period is considered. So daily is the smallest unit and weekly overrides daily > monthly overrides weekly  > yearly overrides monthly. 

Also, Druva follows the Gregorian calendar for tracking days.

While backup schedules are configured on an hourly, daily, or weekly basis the last snapshot created by the backups on that particular day will be retained as per the retention setting.   

You can define the following durations to retain snapshots.

Retention Period Description
Daily snapshots

Druva retains all the snapshots that are created for the number of days specified in Daily snapshots.  

Druva considers midnight as the end of a day.

If you have configured Druva to back up your server multiple times within a day, Druva retains all the snapshots for the days specified.
Weekly snapshots (Son)

The number of weekly snapshots that Druva should retain. Druva treats the latest snapshot in the week as the weekly snapshot.

Druva considers midnight on Sunday as the end of the week.

Monthly snapshots (Father)

The number of monthly snapshots that Druva should retain. Druva treats the latest snapshot in the month as the monthly snapshot.

Druva considers midnight of the last day of a month as the end of the month.

Yearly snapshots (Grandfather)

The number of yearly snapshots that Druva should retain. Druva treats the latest snapshot in the year as the yearly snapshot.

Druva considers the midnight of the last day of the year as the end of the year.

The snapshot name displayed on the Management Console is snapshot creation time as per the server time zone, on which the backup occurred. Druva considers the time zone of the server for retaining the snapshots as per the retention setting.

Default retention period settings 

If you are registering the server under default organization, Druva provides a default backup policy with the following retention settings:

  • Daily snapshots: 14 days
  • Weekly revisions: 4 weeks
  • Monthly revisions: 3  months
  • Yearly revisions: 3  years

The following diagram illustrates the snapshots that will be available on a given day ( Feb 9 in this example) based on the retention settings you have configured. In this example the policy is created and backups start on Dec 30 of the previous year.

Retention example.png

On 9 Feb you will have 17 recovery points or snapshots to restore as described in the table. 

Note: Daily is the smallest unit and weekly overrides daily and monthly overrides weekly and yearly overrides monthly.

Recovery points resulting from


Daily retention setting You will have 11 ( 14 daily less 2 weekly less 1 monthly)  recovery points (starting from 27 Jan) created due to the daily retention settings.
Weekly retention setting You will have 4 recovery points for 14 Jan, 21 Jan, 28 Jan and 4 Feb created due to the weekly settings.

The weekly recovery points that coincide with the daily recovery points (28 Jan and 4 Feb) will be considered and retained as per the weekly setting. So, even though the daily retention period expires for these dates the recovery points will be retained as per the weekly settings (4 weeks).
Monthly retention setting You will have 1 monthly recovery point of 31 Jan. This recovery point will be available for the next 3 months as it is a monthly retention point. So even though the 14 days daily retention period expires after 9 Feb, the recovery point will be available for the next 3  months.
Yearly retention setting You will have one recovery point for 31 Dec due to the yearly retention setting. This recovery point will be available for 3 years.

Impact of retention period settings on recovery point objective (RPO)

In continuation with the example above, so let us say malware was detected on 9 Feb evening.  After investigation, it was discovered that the data till 7 Feb is corrupted.  In that case, the recovery point available to you will be of 6 Feb which is available due to the daily snapshot.  However, there could be a data loss of data backed between 7 Feb and 9 Feb.

Retention Setting and RPO.png


  • Any changes that you make to the existing retention policies will be applied to all the new as well as the existing snapshots.
  • Retention periods are applicable for snapshots that reside on CloudCache and Druva Cloud.
  • Druva runs a retention expiration algorithm to delete the snapshots that have crossed the expiration period. This algorithm does not delete thawed snapshots. For more information, see Snapshots.