| Part 1 — 3 steps to protect your SAP HANA database Part 2 — How to optimize and backup your SAP HANA environment Part 3 — SAP HANA tenant database system copy and recovery Part 4 — How to recover SAP HANA tenant database |
I’ve been very fortunate to speak with customers as they implement the Veeam Plug-in for SAP HANA. During a recent customer pilot project, the following question was asked: “Why doesn’t the plug-in restore newer SAP HANA data after a full VM restore operation is executed?” Upon further investigation, I was inspired to expand upon existing Veeam documentation and share the results as you may find them helpful.
Important note: The following example applies to all SAP HANA backint-certified products as this reflects expected SAP HANA behavior.
My first reaction upon hearing this question was to reflect on what problem the customer was attempting to solve and why this would not work. I confirmed Veeam recommended practices were implemented and suggested a few tips from this blog series, including using the Veeam Plug-in for SAP HANA for database backups (a daily full and log files). I confirmed this implementation was virtualized, hence a backup of the complete VM including all disk was performed on a weekly basis.
The test plan consisted of restoring the complete VM and obtaining the most recent SAP HANA data via our plug-in. This seemed straight forward but after restoring the VM, the customer could only restore to the point in time of the full VM backup despite having additional logs and full backups available.
I quickly setup a test environment consisting of the following elements:
1. Create an SAP HANA full back up of tenant C01 at 7:45 p.m. via the Veeam plug-in
2. Enable the SAP HANA system to create additional log backups
3. Create a VM backup with Veeam snapshot integration at 9:28 p.m.
4. Add data (create additional tables) and perform another full backup via the Veeam Plug-in for SAP HANA at 9:35 p.m.
5. Power off and delete the VM around 9:45 p.m. — as my “disaster case.”
My expectations, which mirrored those of the customer, were that after performing an Instant VM Recovery of the VM with the 9:29 p.m. timestamp, I could then restore the SAP HANA database to the latest point in time (specifically the time of the last backed up log file at 9:42 p.m.).
I started an Instant VM Recovery task from 9:29 p.m.
I must highlight that restoring a 250 GB VM in under 45 seconds is amazing!
But the next step is recovering the last SAP HANA state to bring the system back online.
To recover the tenant to the latest state, select Backup and Recovery, and then Recover Tenant Database.
This seems straight forward, but I noticed my complete (full) back up from 9:30 p.m. was missing.
I doubted that I had discovered a bug or that my eyes deceived me.
I decided on another cup of coffee and pressed on to analyze what could have gone wrong. Recalling that an SAP HANA restore will leverage the last available catalog, I checked the SAP HANA catalog entries.
You’ll notice there is a gap between 9:20 p.m. and 9:47 p.m.
By parsing through the last logs, I discovered what was wrong. After the database starts, a log backup is instantly created along with a new SAP HANA catalog written to the Veeam plug-in. This one is more recent than the one created prior to the Instant VM Recovery task but has the content of everything prior to the VM backup only. I contemplated how to prevent this behavior, and if I should have another cup of coffee.
Disabling specific host’s backup job before initiating SAP HANA restore
I reattempted this test again:
- Create an SAP HANA full backup of tenant C01 at 11:45 a.m. with the Veeam plug-in
- Enable the SAP HANA system to create additional log backups
- This time I used the last VM backup from the day before
- Power off and then delete the VM around 11:48 a.m. — as my “disaster case.”
With the knowledge from above, I disabled the SAP HANA job of my to-be restored HANA system and awaited for the confirmation it was successfully stopped.
Then, I began an Instant VM Recovery task from my backup yesterday evening at 9:29 p.m.
The next step is to recover the SAP HANA system to the most recent state, and we see that the system is back online, restarted at 11:54 a.m. Upon selecting the recovery to the latest state we finally see the result we were expecting.
Now all my previous Veeam Plug-in for SAP HANA complete database backups are available and I’m able to recover the database to the most recent state in the Veeam repository.
One last detail I should mention — after the full restore, SAP HANA will write additional logs. Do not forget to enable the Veeam backup SAP HANA job again for continuing your backint backup with logs. Also keep in mind if you have initialized the log area, you must do a complete data backup run. The wait will offer you a chance to enjoy your coffee. After all, as a wise person once said, “Humanity runs on coffee.”
