Configure advanced policy settings

This page lists the advanced policy settings of an application. These settings vary based on the application you select. You can define the advanced policy settings while creating backup policy.

You can also view and change the policy settings by displaying the policy overrides panel from the Manage Backup Plan page. You can override specific policy settings associated with the selected backup template.

Use the following instructions to view policy settings page from the policy overrides.

  1. Click the App Manager tab and select the Applications option from the drop-down list.

    The Applications page opens.

  2. Select the application or VM and then click Manage Backup Plan from the drop-down list at the bottom right corner of the page.

    The Manage Backup Plan page opens.

  3. In the Apply Backup Plan dialog, click Policy Override.

    The policy override settings open.

  4. Update the policy settings using instructions in the table below. To reset policy settings back to its default state, click Reset to Default.

  5. Click Save Changes to update the settings.

The following table lists the advanced policy settings of an application captured by the policy you defined.

               
Advanced setting Description
Application Consistent
(applicable only for VMware Engine VMs and Compute Engine VMs)		 Select one of the following:
  • Take crash consistent backup: Crash consistent backup is a fast backup of application data in storage as if power were lost at that moment. It does not pause application data I/O. All data on disk is saved, and data in memory is lost. The recovery of a crash consistent backup may take longer and introduce exceptions. It may be required to perform some additional manual recovery steps during the recovery, depending on the guest OS, file systems, and applications. Choose crash consistent if the application consistent process causes issues for your applications or workloads due to the quiescing process. Crash consistent might result in a longer RTO due to the need for the file system or application to perform a recovery from the inconsistent snap, and could even result in an unrecoverable snap in extreme cases.
  • Take application consistent backup. Application consistent backup leverages quiesced snapshots, which uses VMware tools or Google's Guest Environment to quiesce the file system of the virtual machine. A quiesce operation leverages Windows operating built-in capabilities to quiesce file systems and applications that support VSS. It also leverages any customer supplied freeze or thaw scripts (on all platforms) to get higher level application consistency. The result is a higher confidence level in the recoverability of the backup, as well as shorter recovery times in most cases. Application consistent backups can sometimes cause a brief pause in I/O, and while uncommon, some busier applications may report I/O errors at the time of the backup. Occasionally, application consistent backups fails if VMware is unable to quiesce the VM within a predetermined timeout during the snapshot operation. Use application consistent backups when recoverability is most important, and the applications in the VM are not sensitive to the brief I/O pause.
    Read the Create a Linux application consistent persistent disk snapshot section for more information.
  • Take crash consistent backup on last try. This option initially takes application consistent backups, but if an application consistent backup fails for any reason, it takes a crash consistent backup.
    •
    Snapshot location
    (applicable only for Compute Engine instances)    		 Select the region where the PD snapshots are to be stored. By default, multi-region is selected (based on the source disk location). You can also change the snapshot storage location to a different region than the source disk region. When storing snapshots in a location that is different from the location of your source disk, the data travels over the network between those locations and may incur network fees. Snapshots incur the same fees as Cloud Storage egress. Learn more about the persistent disk snapshot. To know the pricing details, see disk pricing.
    Snapshot type      
    (applicable only for Compute Engine instances)    		Select the Persistent Disk snapshot type to be used for Compute Engine instance backups. Snapshots incrementally backup data from Persistent disks. During backups, a new snapshot is created to capture the current state of the Persistent disk and later can be used to create a new disk for mounts or restores. Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of your data. Learn more about the persistent disk snapshot. To know the pricing details, see disk pricing.
  • Standard - By default, the Standard snapshot type is selected. It is recommended to use the standard type if you want to retain the backups for less than 90 days.
  • Archive - Select the Archive type if you want to retain the backups for long duration. Note that the minimum billing period for the archive snapshot is 90 days irrespective of the retention period defined in policy and that Archive type also has an additional retrieval charge if used in a mount or restore job. Archive snapshot type can be used only when the management console and backup/recovery appliance is on 11.0.4 or above.      
    • Staging Disk Over-allocation
    (In percentage)    		 Specify the extra space allocated for staging disk (on top of what's actually needed) to accommodate growth of the application. This setting is from zero to 1000 percent.
    Do Not Unmap Specifies if you want temporary staging disks mapped to the host and used during data movement for backup to remain mapped to the host. LUNs are mapped during the first job and all the subsequent jobs reuse the same mapped LUN. Select either:
  • Keep staging disks mapped between jobs. Select this option if you want the temporary staging disks mapped to the host and used during data movement to remain mapped to the host. LUNs are mapped during the first job and all the subsequent jobs reuse the same mapped LUN. By default, this option is selected.
    Note: For applications managed using the Backup and DR agent (such as SQL database) where the application is on an OS running inside a VMware VM, this option is ignored. The staging disk is always be unmapped from the VM after every job.
    •
  • Unmap staging disks after each job. This option both unmounts the staging disk from the operating system at the conclusion of every job (removing mount points or drive letters), and also unmaps it from the host altogether. This option requires the host to perform a scan for SCSI LUNs at the start of the next job, as the re-mapped staging disks must be rediscovered before they can be remounted.
    •
    Truncate (Purge) Log After Backup Specify whether to truncate (purge) the database logs after every backup. When Truncate Log After Backup is enabled, application-related logs are truncated until the recent or current backup. If you truncate logs, you must also back up the transaction log to enable a roll forward recovery.
    The options are:
  • Do not truncate/purge log after backup
    •
  • Truncate/purge log after backup
    •
    Skip Offline Applications in the Consistency Group
    (For Consistency Group management only)    		 Specify whether to ignore unavailable applications that are part of a consistency group. You create a consistency group to back up the data of all member applications together to preserve consistency of data across the member applications. Consistency groups are collections of discovered applications from the same host.
    Options are:
  • Fail backup when offline applications are found
    •
  • Skip offline applications during backup
    •
    Map staging disks to all nodes in an application cluster If your nodes are in an application cluster, you can use this to ensure that the nodes of an application cluster are protected in case of failover during backup.
  • Do not map staging disk to all nodes of application cluster.
    •
  • Map staging disk to all nodes of application cluster
    In the event of an application cluster failure, this option protects failover copies.
    •
    Map Staging Disk to All ESX Hosts in a Cluster
    (For VMware VMs only)     		If your ESX servers are in an appliance, you can use this setting to ensure that the VMs are managed in case of failover during backup. In the event of an ESX host failure, this option manages failover copies of VMware VMs. (Oracle, local file systems, SMB, NFS, SQL Server):
  • Map staging disk to ESX host for VM only
    •
  • Map staging disk to all ESX hosts in the cluster
    •
  • Map staging disk to two ESX hosts in the cluster
    •
    Backup SQL Server User Logins Captures the SQL Server database login credentials. When the database is mounted as a virtual application (app aware mount) the virtual database has all of the login credentials used by the source. The options are Yes or No.
    Enable Database Log Backup The Enable Database Log Backup option allows the backup plan policy to backup a database and all associated transaction log files. The logs are backed up when the log snapshot job runs. Options are Yes or No. When set to Yes, the related options are enabled.
    Note: For details on Log Protection, see Database Log Protection in a backup plan policy.
    RPO When Enable Database Log Backup is set to Yes, RPO defines the frequency for database log backup. Frequency is set in minutes and must not exceed the database backup interval. The smallest value that can be set (in minutes) is 15.
    Log Backup Retention Period
    (In Days)    		 When Enable Database Log Backup is set to Yes, log retention is defined separately from the retention of the snapshot policy. Having a separate retention period allows you to use logs in conjunction with copies of the database stored in the snapshot pool. The log retention period is a mandatory setting.
    Replicate Logs
    (Uses streamsnap Technology)    		 When Enable Database Log Backup is set to Enable, the Replicate Logs advanced setting allows database logs to be replicated to a remote appliance. For a log replication job to run, there must be streamsnap replication policy included in the template along with a resource profile that specifies a remote appliance, and at least one successful replication of the database must first be completed. You can then use the logs at the remote site for any database image within the retention range of the replicated logs. This function is enabled by default.
    Log replication uses streamsnap technology to perform the replication between the local and remote appliances; log replication goes directly from the local snapshot pool to the snapshot pool on the remote appliance.
    Note: Log replication does not occur until database has been protected and the image replicated to the remote appliance.
    Send logs to OnVault Pool Set to Yes, logs are replicated to one or more OnVault storage pools enabling for point-in-time recoveries from OnVault on another site.
    Log Staging Disk Growth Size (In Percent) When Enable Database Log Backup is set to Yes, Log Staging Disk Growth Size defines the growth to use when automatically growing the staging disk on which the logs reside. This setting is from five to 100 percent.
    Estimated Change Rate When Enable Database Log Backup is set to Yes, this setting defines the daily change (in percent), which allows the appliance to better calculate the size of the staging disk needed to hold logs. This setting is from zero to 100.
    Compress Database Log Backup When Enable Database Log Backup is set to Yes, this setting instructs the source database to compress its logs before they are captured by the management console. The database server performs log compression during log backup. The options are Yes or No. When set to Yes, the Compress Database Log Backup option is enabled.
    Enforced Retention Allows the user to configure the desired immutability period between zero and 36525 days. By default, the value is set to zero for all existing policies.
    You can modify a policy that is already used to protect an application by setting a longer enforced retention period. However, you cannot shorten the enforced retention period.
    You cannot set enforced retention for a streamsnap policy whose retention is "Only keep the most recent remote image".
    Note: Enforced Retention cannot be overridden on a per-application basis. The option does not appear on the Policy Overrides page.
    Job Behavior When Target VM Needs snapshot Consolidation Select an action if the VM requires consolidation:
  • Fail the job if VM needs consolidation: Point-in-time jobs fail.
    •
  • Run the job without performing consolidation: All jobs run normally even if consolidation is pending.
    •
  • Perform consolidation at the beginning of the job: Point-in-time jobs try to perform consolidation at the beginning of the job. If consolidation fails, the job fails with an error message.
    •
    Fail On Missing Start Path If one or more start paths are specified, and any of these start paths does not exist, the job fails with the message UDSAgent: Specified start path does not exist. If no start paths are specified, this option has no effect. Options are Yes or No.
    Note: The default state for this option is No (disabled), which is the same behavior of the previous versions of the Backup and DR agent; the job does not fail if a start path does not exist.
    Enable Degraded Capture Mode Degraded capture mode captures incremental data when Change Block Tracking (CBT) service is unavailable. Data capture may take longer. The options are Yes or No.
    Script Timeout
    (applicable only for agent based backups)    		 The Backup and DR agent allows you to create host-side scripts that run on an application's host before or after a policy is run. The four timeouts provided in a policy template map directly into the four stages of a host-side script.
    Note: By default, the script timeout values are per the values stated below. If a script timeout is not specified, the value is blank and the default is used.
  • Script Init Timeout: Defines how long a job should wait for the script that is invoked on the host before any action is taken by the job. If the script does not complete within this timeout, the job fails. The default value is 60 seconds. Allowed range is one to 86400 seconds.
    •
  • Script Freeze Timeout: Defines how long a policy should wait for the script that is invoked in order to freeze an application, before a snapshot is taken. If the script does not complete within this timeout, the job fails. The default value is 60 seconds. Allowed range is one to 86400 seconds.
  • Script Unfreeze Timeout: Defines how long a policy should wait for the script that is invoked in order to freeze an application, after a snapshot is taken. If the script does not complete within this timeout, the job fails. The default value is 60 seconds. Allowed range is one to 86400 seconds.
  • Script Finish Timeout: Defines how long a policy should wait for the script that is invoked at the very end of the job. If the script does not complete within this timeout, the job fails. The default value is 60 seconds. Allowed range is one to 86400 seconds.
    		•

    What's next