NetBackup™ Web UI Cloud Administrator's Guide

NetBackup deployments in Flex Appliance and Flex Scale do not support PaaS workloads.

Supports only default the ports for all the databases across providers. Workload instances configured with custom ports are not supported.

Database names containing the characters '#' and '/' are not supported for backup and restore operations. Also, the database name should adhere to naming conventions suggested by the cloud vendors.

";" is not supported in server or database password.

Backup and restore of a database with non-7 bit ASCII characters are not supported for a primary server running Windows, and having a media server version prior to 10.1.1.

You can duplicate the PaaS backup image to a supported storage server. But before you start a restore, you need to duplicate the image back to an MSDP server with universal share enabled. See Recovering duplicate images from AdvancedDisk.

With NetBackup 10.3, you can perform backup and restore of supported Azure PaaS databases with Managed Identity based database authentication. This is not supported for Azure Database for MariaDB server. This feature requires at least one media server of version 10.2 or higher.

For authentication of Azure database, It is recommended to use User Assigned managed identity to work across all media servers. A database user with a system-assigned managed identity, which is associated with the media server or vm-scale-set (AKS/EKS), does not work with any other media server or media in any other vm-scale set (AKS/EKS).

Azure Managed Identity is not supported across subscriptions of different tenants.

Restore of security privileges is not supported.

During restore you can use - no-owner and - no-privileges option. After restore, the metadata captured at the time of backup are shown as owner/ACL in the progress log restore activity on the web UI.

Restore does not fail if the owner or role does not exist on the destination.

Post restore, the database has the role associated according to the credentials provided in NetBackup against the destination instance.

Users need to modify the ownership of databases post restore.

Backup and restore are not supported if the only SSL (Secure Sockets Layer) connection is enforced at the server level for GCP PostgreSQL workload.

Azure Postgres database restore from single to flexible server or vice versa is not supported because of the cloud provider limitations.

The following characters are not supported in the database name in the restore workflow: `, @, \, [, ], !, #, %, ^, ., ,, &, *, (, ), <, >, ?, /, |, }, {, ~, :, ', ", ;, +, = and -.

Uppercase username is not supported for new users added after PostgreSQL server creation.

Alternate restore for region and account is not supported.

Restore from imported images from a different primary server is only supported using NetBackup REST API.

Only Express and Web editions for AWS RDS SQL are supported.

For credential validation, IAM is not supported for AWS RDS SQL. You can use the username and password method.

Only Amazon RDS data management type is supported. The data management type RDS Custom is not supported for AWS RDS SQL instance editions.

Databases using Transparent Data Encryption (TDE) are backed up without TDE, but using MSDP encryption. This allows for restoring your database in more scenarios like loss of the TDE encryption key, cloud region outage, disaster recovery to another cloud and so on.

Restore operation require superuser privileges if the dump file contains the CREATE DEFINER statement for backups taken on version lower than 10.2.

Backup taken on version 10.3 or higher cannot be restored using version lower than 10.2.

Backup and restore are not supported if the only SSL connection is enforced at the server level for GCP MySQL workload.

You can restore MySQL database to an alternate instance with another MySQL version than the backup instance, depending on MySQL's version compatibility.

Backup and restore of read-only databases are not supported.

Provider credentials are validated for full backup and restore and not as database credentials.

Backup and restore of single-user-mode databases are not supported.

If one operation is in progress, the subsequent jobs wait in the queue. If the job in progress takes time to complete, the jobs in the queue may get timed out, and fail.

Incremental backups after any DML changes, might fail when a table is renamed after CDC is enabled on the table. As a workaround, you must manually modify any objects that reference the renamed table. For example, if you rename a table that is referenced in a trigger, you must modify the trigger to contain the new table name. Refer to this Azure documentation link to list dependencies on the table before renaming it.

Backup and restore of databases having binary or image data are not supported. Bulk insert on Cloud SQL Server requires sysadmin permission that GCP does not allow.

While duplicating incremental backups on the different storage servers, NetBackup generates different copy numbers for the same recovery point. If you try to restore an incremental copy where no earlier full and other incremental backups are present, the restore may fail.

If you have multiple media servers, the incremental backups can run only on version 10.3 or later. 

System databases and CDC schema are backed up and restored on the target database.

You must the set the CDC retention period greater than the period used to schedule incremental backup frequency.

Incremental backups for databases with multiple tables can take longer to backup as CDC enablement for multiple tables takes longer time.

Incremental backups are not supported for database editions Web and Express.

Any attempts to enable CDC fail if a custom schema or a user named CDC already exists in the database.

To ensure application consistency, NetBackup relies on previous full backup and all the subsequent incremental backups. If a random backup image is expired, it may cause application inconsistency due to data loss.

CDC requires SQL Server Standard or Enterprise editions. If a database is attached or restored with the KEEP_CDC option to any edition other than Standard or Enterprise backup fails. The error message 932 is displayed.

The Azure VM which is used as a media server, should be in the same Vnet as that of an Azure-managed instance. Alternatively, if the media server and SQL managed instance are in different Vnet, then both the Vnets must be peered to access the database instance.

Backup fails when Readlock is placed on the database or resource group.

Backup is partially successful when Delete lock is placed on the database or resource group. The tempdb stale entry does not get deleted from the Azure cloud portal. You need to manually delete it.

To restore a database on an Azure SQL server or Azure Managed Instance, you must assign AAD admin privilege on the target server. Before the restore, do the following, as required:

You can enable Change Data Capture (CDC) only on databases tiers S3 and above. Sub-core (Basic, S0, S1, S2) Azure SQL Server and SQL Managed Instance databases are not supported for CDC.

You may encounter backup or restore issues for databases having encrypted columns in the table. As a workaround, Microsoft suggests using Publish/Extract commands to tackle this issue.

Restore may fail for a database having blob data in the table.

To duplicate incremental backups on different storage servers; NetBackup generates different copy numbers for the same recovery point. If you try to restore an incremental copy where no earlier reference of full and other incremental backup is present, the restore fails.

The user ID used for the cloud service must have permission to enable and disable CDC. Without this permission, you can see errors such as follows:

3842: "Failed to enable CDC" 
and
3844: "Failed to disable CDC"

Any attempt to enable CDC fails if a custom schema or a user with the name cdc exists in the database. The term cdc is reserved for system use.

In a database with the CDC schema created before taking the first full backup, the schema does not get backed up or restored.

If you restore to any edition other than Standard or Enterprise, the operation is blocked because CDC requires SQL Server Standard or Enterprise editions. Error message 932 is displayed.

Avoid backing up databases with BLOB data tables. If a table contains BLOB data, then the backup might be successful, but the restore fails.

Encryption setting of an Azure SQL Server or Azure SQL Managed Instance database may not be preserved (Is_encryption=0) during a restore.

Discovery, protection, and restore are not supported if the account is configured using the vCore cluster.

Backup and restore are not supported if the account is configured with a customize key.

NetBackup does not support Azure cosmos DB for MongoDB version 3.2.

Overwrite existing database option is not supported.

Rules for naming databases:

Backup and restore are not supported if the account is configured with a customize key.

Protection of Azure Cosmos DB for MongoDB version 3.2 is not supported.

Overwrite existing database option is not supported.

Rules for naming databases:

Backup and restore are only supported for EFS-supported Oracle instances.

Standard and Enterprise Edition are supported.

Multi-tenant container databases and read replicas are not supported.

Backup and restore are not supported for TDE enabled RDS Oracle instances.

Only Amazon RDS data management type is supported. The data management type RDS Custom is not supported.

Option group attached to RDS Oracle should have the same database engine version and same database engine name.

Restore is supported using the EFS staging path only, including the manual restore from the Instant access database tab.

Restores to alternate region or alternate account are not supported.

NetBackup protects the individual AWS Redshift cluster databases. Protection of the entire AWS Redshfit cluster is not supported.

Only user databases are protected. System databases are not displayed or protected.

Restore from imported images from a different primary server is supported only using NetBackup REST API.

Only Redshift clusters are supported. Serverless Redshift is not supported.

All clusters whose databases you are taking backup must be in the available state.

Table names having double quotes and case-sensitive names are not restored.

File count during restore may show one file less than the total number of backed up files.

It is not recommended take backup of databases having empty tables.

NetBackup provides crash-consistent Redshift data protection. Consider the type of activity and application requirements before taking backups to determine if an application needs to checkpoint or quiesce for backup operations.