For incremental backups using the GCP SQL Server
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 with binary or image data are not supported. Bulk inserts on the 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 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 back up, 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 the 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.