NetBackup™ Web UI Cloud Administrator's Guide
- Managing and protecting cloud assets
- About protecting cloud assets
- Limitations and considerations
- AWS and Azure government cloud support
- Configure Snapshot Manager in NetBackup
- Managing intelligent groups for cloud assets
- Protecting cloud assets or intelligent groups for cloud assets
- About storage lifecycle policies
- Managing policies for cloud assets
- Limitations and considerations
- Planning for policies
- Creating policies for cloud assets
- Setting up attributes for PaaS assets
- Setting up attributes for IaaS assets
- Creating schedules
- About backup frequency
- About assigning retention periods
- Configuring the Start window
- Configuring the include dates
- Configuring the exclude dates
- Configuring the cloud assets for PaaS
- Configuring the cloud assets for IaaS
- Configuring backup options for IaaS
- Managing cloud policies
- Scan for malware
- Protecting Microsoft Azure resources using resource groups
- NetBackup Accelerator for cloud workloads
- Configuring backup schedules for cloud workloads using protection plan
- Backup options for cloud workloads
- AWS Snapshot replication
- Protect applications in-cloud with application-consistent snapshots
- Protecting AWS or Azure VMs for recovering to VMware
- Cloud asset cleanup
- Cloud asset filtering
- Protecting PaaS assets
- Protecting PaaS assets
- Prerequisites for protecting PaaS assets
- Enabling binary logging for MySQL and MariaDB databases
- Enabling backup and restore in Kubernetes
- Prerequisites for protecting Amazon RDS SQL Server database assets
- Protecting RDS Custom instances
- Protecting Azure Managed Instance databases
- Limitation and considerations
- For all databases
- For PostgreSQL
- For incremental backups for Azure PostgreSQL
- For AWS RDS PostgreSQL and AWS Aurora PostgreSQL
- For AWS DynamoDB
- For AWS DocumentDB
- For AWS Neptune
- For AWS RDS SQL
- For Azure, AWS RDS, and Aurora MySQL
- For incremental backups using Azure MySQL server
- For incremental backups using the GCP SQL Server
- For Azure SQL and SQL Managed Instance
- For Azure SQL and SQL Managed Instance (without temp. database)
- For Azure SQL Server and SQL Managed Instance incremental backup
- For Azure Cosmos DB for MongoDB
- For Azure Cosmos DB for NoSQL
- For Amazon RDS for Oracle
- For Amazon Redshift databases
- For Amazon Redshift clusters
- For GCP SQL Server
- For GCP BigQuery
- Installing the native client utilities
- Configuring storage for different deployments
- Configuring the storage server for instant access
- About incremental backup for PaaS workloads
- Configuring incremental backups for Azure MySQL server
- About archive redo log backup for PaaS workloads
- About Auto Image Replication for PaaS workloads
- Discovering PaaS assets
- Viewing PaaS assets
- Managing PaaS credentials
- Add protection to PaaS assets
- Recovering cloud assets
- Recovering cloud assets
- About the pre-recovery check for VMs
- Supported parameters for restoring cloud assets
- Recovering virtual machines
- Recovering applications and volumes to their original location
- Recovering applications and volumes to an alternate location
- Recovery scenarios for GCP VMs with read-only volumes
- (GCP only) Restoring virtual machines and volumes using the autoDelete disk support
- Perform rollback recovery of cloud assets
- Recovering AWS or Azure VMs to VMware
- Recovering PaaS assets
- Recovering cloud assets
- Performing granular restore
- Troubleshooting protection and recovery of cloud assets
- Troubleshoot cloud workload protection issues
- Error Code 9855: Error occurred while exporting snapshot for the asset: <asset_name>
- VMs and other OCI assets with CMK-encrypted disks are marked as deleted in NetBackup UI.
- Backup from snapshot jobs take longer time than expected
- Backup from snapshot job fails due to connectivity issues when Snapshot Manager is deployed on an Ubuntu host
- Error disambiguation in NetBackup UI
- Status Code 150: Termination requested by administrator
- Troubleshoot PaaS workload protection and recovery issues
About backup frequency
To determine backup frequency, consider how often data changes. For example, determine if files change several times a day, once a day, weekly, or monthly.
Typically, sites perform daily backups to preserve daily work. Daily backups ensure that only one day's work is lost in case of a disk failure. More frequent backups are necessary when important data changes many times during the day and the changes would be difficult to reconstruct.
Daily backups are usually the differential incremental backups that record the changes since the last differential incremental or full backup. Differential incremental backups conserve resources because they use less storage and take less time to perform than full backups.
Full backups usually occur less frequently than differential incremental backups but should occur often enough to avoid accumulating consecutive differential incremental backups. A large number of differential incremental backups between full backups increases the time it takes to restore a file. The time increases because of the effort that is required to merge the differential incremental backups when files and directories upon restore.
Consider the following when setting the frequency for full backups:
Extend the time between full backups for the files that seldom change. A longer frequency uses fewer system resources. It also does not significantly increase recovery time because the differential incremental backups between full backups are smaller.
Decrease the time between full backups for the files that change frequently. A shorter frequency decreases restore time. A shorter time between full backups can also use fewer resources. It reduces the cumulative effect of the longer differential incremental backups that are necessary to keep up with frequent changes in the files.
To achieve the most efficient use of resources, ensure that most of the files in a given policy change at about the same rate. For example, assume that half of the files in a policy selection list change frequently enough to require a full backup every week. However, the remaining files seldom change and require monthly full backups only. If all the files are in the same policy, full backups are performed weekly on all the files. This wastes system resources because half the files need full backups only once a month. A better approach is to divide the backups into two policies, each with the appropriate backup schedule, or to use synthetic backups.
If more than one automatic schedule is due for a client within a policy, the backup frequency determines the schedule that NetBackup uses as follows:
Jobs from the schedule with the lower frequency (longer period between backups) always have higher priority. For example, a schedule that has a backup frequency of one month takes priority over a schedule with a backup frequency of 2 weeks.
When two schedules are each due to run, the schedule with the schedule name that is first in alphabetical order runs first. Alphabetical priority occurs if both of the following are true:
Each schedule is within the defined time window.
Each schedule is configured with the same frequency value.
NetBackup prioritizes the example schedules in the following order:
Table: Examples of schedule frequency and priority
Schedule Name | Frequency | Priority |
|---|---|---|
|
monthly_full |
One month |
First |
|
weekly_full |
One week |
Second |
|
daily_differential_incremental |
One day |
Third |