You can either manually configure virtual machines for backup or create autoconfig rules for automatically configuring virtual machines for backup. For more information about how the backups are taken, see Azure VM backup workflow.

The following sections provide details of manual and automatic configuration of virtual machines for backup.

To protect your virtual machines, you must first set up your virtual machines for backup.

As a part of the configuration, you must do the following:

Backup policies are rules that define a schedule, bandwidth for scheduled backups, and retention period for recovery points. By defining backup policies, you can define the rules for backing up Azure virtual machines.

A backup policy defines the following:

Druva provides a default backup policy. You can use this default backup policy or create a new one. Druva backs up the virtual machines based on the backup schedule defined in a backup policy.

You can create a backup policy using three easy steps as shown in the following diagram:

You can either retain the default schedule or add your own schedule to back up virtual machines. You can add more than one schedule to backup your virtual machines. To add a new schedule:

You can retain the default retention settings or provide custom values to determine the duration for which you want to retain your backups.

On the New Backup Policy > Retention tab, provide the following details and click Finish:

You can edit an existing backup policy. When you change the backup policy settings, then from that time onwards, the backups will be taken as per the new schedule and retention settings. You can edit the following information in a backup policy:

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.

📝 Note
​The retention period would not be honored for the most recent recovery point when a 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:

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.