For PostgreSQL
Restoring security privileges is not supported.
During restore, you can use the - no-owner and - no-privileges options. After restore, the metadata captured at the time of backup is shown as the 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 with it, according to the credentials provided in NetBackup against the destination instance.
Users need to modify the ownership of databases post-restore.
Azure Postgres database restore from a single to a flexible server or vice versa is not supported because of the cloud provider's 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.
(RDS and Azure PostgreSQL only) SCRAM authentication configured on a database instance is not supported.
If full or differential incremental backups fail with temporary objects, then delete the temporary objects manually and run backup again.
If the database has RLS (Row-Level Security), you must grant the backup user the permission to bypass all RLS policies, using the following command:
ALTER USER <backup_user> WITH BYPASSRLS;