Idea ID: 1652408

full HANA integration for database backups (e.g. schedules, backup types)

Status : Under Consideration
Under Consideration
See status update history
over 3 years ago

Brief Description:

Enhance HANA integration so that it is possible for database backups to define schedules and backup types (full, incremental, delta) from within Data Protector GUI/backup specification - sort of give it the same functionality as the Oracle integration (in terms of database backup only, log backup and restore is obviously completely different)



By using the Data Protector scheduler you eliminate the need to synchronize with external schedulers (cron, UC4 etc.) during initial configuration and/or DP maintenance - and get a consistent view of the backup environment as with all other integrations (next scheduled backups, restart missed backups etc.).

By using the normal integration approach of an Data Protector agent running on the server you also eliminate the need for custom external scripts to adjust the HANA backint parameter file prior to each backup to get the normal functionality of a Data Protector-initiated backup session (e.g. like Oracle integration):

  • choosing backup type  (full, incremental, delta) depending on schedule/weekdays (e.g. incr/delta for daily, full for weekly/monthly backups)
  • having different protection times depending on weekdays (e.g. short protection for daily, longer protection for weekly/monthly backups)
  • having different target devices (e.g long-term backups going to tape, short-term to StoreOnce)


Design details

You would need to

  • complete the already partly existing HANA integration agent (,,
  • enhance GUI to be able to configure the new settings (e.g. HANA instance number, hdbuserstore entry, schedule and backup type)

The integration backup agent ( running on the HANA server would have to (just like the Oracle integration prepares the RMAN script before invoking RMAN):

  1. change the "data backup" backint parameter file to point to the correct specification (do this safely, so that several backups for multitenant databases started in parallel don't cause a conflict)
  2. initiate the appropriate backup type by running hdbsql with the "BACKUP DATA" SQL statement (asynchronously); you could also encode the session number, specification name etc. into a dedicated backup label to make the backup easily identifiable from within HANA Studio)
  3. wait for backup to complete (e.g. by querying M_BACKUP_PROGRESS view)



  • don't use a synchronous BACKUP DATA statement, since this forces you to keep the "don't-change-the-backint-parameter-file-lock" for the whole backup; when called asynchronously as suggested hdbsql will come back as soon as the (small) topology data has been backed up and the backint parameter file will not be used anymore (and it is hence safe to be changed for another backup waiting to start)
  • this enhancement request is only for database backup functionality - log backups are only/always triggered by HANA itself and re-implementing the whole HANA Studio restore wizard within the Data Protector GUI would be a waste of time