Enterprise Workloads Editions: ✅ Business | ✅ Enterprise | ✅ Elite

A backup policy is a set of rules that defines the schedule for automatic backups which occur on virtual machines configured for backup. You can create a backup policy and assign it to one or more virtual machines. After you assign backup policy to a virtual machine, the virtual machine is backed up according to the schedule defined in the associated backup policy.

Configuring a backup policy helps administrators simplify management of data backups across multiple virtual machines.

📝 Note
​Backup operations follow the time zone of the server.

Backup policy defines parameters such as,

In this section

Best practices provide you an idea on how you can design or create a backup policy that shall fulfill your requirement.

Follow these best practices when creating a new backup policy to backup virtual machines in your environment.

Retention defines the rules for retaining your backups (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.

❗ Important

The retention period would not be honored for the most recent recovery point when a server or VM or backup set is disabled. This allows you to restore the latest recovery point later if required.

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:

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 recovery point 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 recovery point created by the backups on that particular day will be retained as per the retention setting.

You can define the following durations to retain recovery points.

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

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

📝 Note
​The above default retention settings are applicable for Warm storage and Long Term Retention (LTR) tiers.

The following diagram illustrates the recovery points 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.

On 9 Feb you will have 17 recovery points or recovery points 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.

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 recovery point. However, there could be a data loss of data backed between 7 Feb and 9 Feb.

Add or create a new Hyper-V backup policy based on your Organization needs to backup virtual machines based on different schedules.
You can also copy an existing Hyper-V backup policy and modify it to suit your needs. For more information, see Copy a Hyper-V backup policy.

Procedure

You can copy the existing backup policies to create multiple copies of backup policies. When you copy a backup policy, the newly-created backup policy is identical to the policy that it was copied from. You can modify the settings of this policy according to your requirements.

Prerequisites

There must be at least one existing Hyper-V backup policy defined in your Druva environment.

To copy a VMware backup policy

Backup policy is created with settings similar to the original backup policy and listed on Manage Backup Policies page. Click the name of the backup policy to view its details. You can edit the settings as per your requirement and save it. You can then assign the backup policy to a virtual machine, which defines the backup schedule.

You can update an existing Hyper-V backup policy anytime as per your requirements. You can update details such as the name, description, backup schedule, retention settings, and Hyper-V settings.

To update a backup policy:

To view list of virtual machines associated to a backup policy:

Only a cloud administrator and a cloud-derived administrator can remove or delete a backup policy from the Druva environment based on the following criteria,

Prerequisites

📝 Note

Procedure

If the prerequisites mentioned earlier are satisfied, the backup policy is removed from Druva. Otherwise, you must take appropriate steps to satisfy the criteria and then try again.