cancel
Showing results for 
Search instead for 
Did you mean: 

HANA System Copy with Inkremental Backups

andreas_zigann
Active Participant
0 Kudos

Hello Community,

we want to transfer a HANA Database from one data center to another one minimizing downtime. Due to a large database and limited network ressorces we want to proceed as follows:

Preparation:

Full backup to file

Transfer via HDD

Recover to target

n-times until reaching planned downtime:

{Inkremental Backup, Transfer via Network, Recover inkremental}

Downtime

Stop Source

Inkremental Backup, Transfer via Network, Recover inkremental

We are using this procedure sucessfully with MaxDB and Oracle but I cannot find the way with HANA.

I have found a threat of 2016 with the information, that backup catalog is required to start the recovery. But at the time of the recovery of the full backup, the catalog can not have the information of the last inkremental backup.

When I use HANA Studio the database will be started after recovery of a full backup without catalog. I can not start the recovery of the inkremental recovery after that.

I have tried to find a recover command with sql, but did not find a usable.

I need this procedure urgently to reduce downtime from around 24 hours (backup to disc, transfer, recovery in downtime) to nearly one hour by described way.

Can anyone give me a hint, where to find the right tool or command?

Best Regards

Andreas

Accepted Solutions (0)

Answers (2)

Answers (2)

sumitjais
Active Contributor
0 Kudos

Hi Andreas,

For every data, delta (incremental & differential) and log backup , the nameserver of the database writes backup catalog (log_backup_0_0_0_0.<BackupID> at location : global.ini/[persistence]/basepath_catalogbackup). This is true even in situations when log mode overwrite is set.

The purpose of incremental and log backups is to recover the database to most possible recent point. Thus, the delta and log backups support the full backup to achieve the recent state.

HANA gives only two option

- Recover the database with full backup : without catalog.

- Recover the database with full backup + delta backup (if available) + log backup : With source backup catalog (and delta/log files).

In your case, you may proceed with recovery using backup catalog only. Ensure that you don't miss any backup files or required catalog file.

andreas_zigann
Active Participant
0 Kudos

Hello,

the fastes way is then:

  1. Data Center of actual provider back up the database and transfer this via mail.
  2. Do some inkremental backups through a timeline of two days and copy them via ftp or http to our data center.
  3. Stop the System
  4. Do a last inkremental backup of source system
  5. Copy this backup and the backup history to our data center
  6. Start the recover in our datacenter with the full backup, several inkremental backups and perhaps a last logbackup.

I think for comfort SAP should develop the possibility to recover the database the same way she did with MaxDB This would reduce downtime of system copies and transfers alot. I do not get why she did not.

A last question, can I use replication of hana without direct network connection? Perhaps with full backup and logshipping via file transfer?

The point is:

  • I have a 2 TB HANA database,
  • log volume more than 100 GB / day and
  • a low performance network connection (reliable bandwith of 100 MBit/s only few ours a day and the rest of the day only 25 to 40 MBit/s) This way I can only copy asynchronous and maximum 40 GB / hour at best times and 10 GB / hour at the rest.

And I have a productive system with material managent and sales working 7x24. So I have to minimize downtime.

Best Regards

Andreas

sumitjais
Active Contributor
0 Kudos

Hi Andreas,

Instead of recovering multiple incremental backups until your planned schedule, you can set-up HANA system replication(HSR) between the two systems to perform the copy and take-over at your planned schedule. The continuous log replay will ensure that the target is ready at any time.

andreas_zigann
Active Participant
0 Kudos

Hello Sumit,

we thought about it, but this would use the same weak network. Further, this would force us to open the communication between foreign data center and our data center. Due to security reasons this is not the prefered way.

Best Regards

Andreas