Backint for SAP HANA "Veeam-Features" like BackupCopy

[DaStivi]

Hello there,
i'm in an POC or better said FeatureMatrix/usability fight with Dataprotector on how Veeam SAP Hana BackInt Plugin works…

As HannesK statet here: post313444.html#p313444 the Backint Backup Files from SAP Hana are Veeam proprietary files (VAB) i also see that there must be some compression or whatsoever gooing on, fine on that so far…

what i miss, i don't see easily where These files reside, i mean: i've got an SOBR with 8 extents, and the vab files are somewhere… i've to search them via the filebrowser… i'm not able to view them via normal Backups/disk view under the home tab!

i understand that Veeam hosts really the backup repository only, not exactly as we still see a backup Job Status at least...
what brings me to my 2nd fight with Dataprotector, the Backup Admin told me with dataprotector its possible to determine the Retention Period on what backups are retained! i'm not sure on this, because backint (as rman for Oracle) is: "let the DB Admins do the backupjobs" from this Approach i full understand that Veeam can't bother the Retention period… ?!

3rd thing whats left (also some Dataprotector feature), it Looks like its not possible todo a backupcopy of the saphana backint files, i guess its like the Retention Thing, when Veeam does some backupcopy, SAP Hana Studio won't know that in theyr own managed Catalog, i'm not sure if it would be possible for the Veeam Plugin to parse the backupcopy files also through the Plugin into hana Studio... at least it would propably be possible to Import them manually when requierd…

another possibilty would simply be that it's a Policy to have all Backup Sets at least double retained somewhere in different datacenters (not really needed that sap Studio is Aware of the 2nd copy in the first place)

Besides these small Questions the sap hana admins are quite happy on how the Veeam SAP Hana backint Plugin works!

[Gostev]

Hi, Stephan - thanks for your feedback. I know we're already working on #3, and I will let the PM behind this offering comment on the rest. Thanks!

[p.sartorius]

Hello, we want to leave our TSM backup solution for SAP HANA and see the same issues. Without a backupcopy, tapeintegration or cloudcopy we can't go to production.

[Andreas Neufert]

Backup file. We pack the SAP and RMAN backup files into our format to apply compression dedup and additional metadata to them.

For example you can later import them to another veeam server and the import will add the metadata back to our database.

That said you can copy them arround as any other veeam backup file with storage replication, file 2 tape jobs and any other copy method. As Anton said we are looking into a better copy method for upcoming version.
Regarding naming. We create a job object per server with hostname and repository name. The folder in the repository or sobr extend has same name. By nature of SOBR we spread the backup file across extends, so you need to copy the folder with the jobname from all extends to have a complete copy. As I said we will make this more useful in next version.

[Andreas Neufert]

Regarding retention, as the goal of first version was to give the DBA full control of the backup process, he can delete old restore points as needed. You can find examples in our documentation. https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

[rurouni]

Hi,
Let me join the discussion, i'm interested in it.

We invested heavily in Veeam backup to replace our Legacy Dataprotector too.

We didn't proceed with Backint integration with veeam since it supports only Hana 2 databases. All our databases are Hana 1 SPS 12.
Meanwhile we performed successfull Tests with Backint integration directly on the Storeonce we bought with the Veeam Project.

However these questions come to my mind:
- How do you perform 3-2-1 when backup operations and catalog are operated at SAP Hana Level and since it only sees the primary backup repository.
- Would it be possible to perform copy jobs on SAP Hana DBs backed up with Veeam Backint Plugin on veeam Repositories?
- How do you proceed with Non Productive System Refresh when you use Backint integration? we're used to do it with File Backups we move on the target database prior to restore. Here, the Files don't seem to be available.

Regards.

[clemens.zerbe]

Hi,

let me comment on your questions and remarks.

HANA 1.0 -> see my post here.->veeam-backup-replication-f2/feature-req ... 60691.html

HANA 3-2-1 rule & copy jobs. -> The best workaround for 9.5U4 (as backup copy jobs are not supported) is to create an agent job which will backup the Repo/SAPHANA Job folders into a different repository. From there you can move this data to cloud tier/tape etc. We are aware that this is not optimal and will include 2 steps to recover the data. We are actually reviewing this feature to improve this in one of our future releases.

Non productive system refresh -> AKA SAP HANA SYSTEM copy. This if fully supported by our plugin. There is a command line switch to enable restores from other HANA systems:

Code: Select all

/opt/veeam/VeeamPluginforSAPHANA # SapBackintConfigTool --help
  --help                Show help
  --show-config         Show configuration parameters
  --wizard              Start configuration wizard
  --set-credentials arg Set credentials
  --set-host arg        Set backup server
  --set-port arg        Set backup server port
  --set-repository      Set backup respository
  --set-restore-server  Set source restore server for system copy processing
  --map-backup          Map backup

After setting this restore only parameter you can easily follow the SAP procedure to create a SAP HANA system copy. Just keep in mind that the source system will noted as <tenantname>@<sid>.

Thanks
Clemens

[mfirewalker]

Just wanted to leave a comment here voting for integration of HANA backups with Backup Copy and Tape Jobs

[clemens.zerbe]

Check the latest beta build. There might be some nice features.
If you do not have access to any beta builts....send me a personal message and we find a way for a short demo.

[rurouni]

Hi Clemens,
Thanks for the information and answers to previous posts.
I read your Blog with articles about backuping hana with backint through Veeam. Very interesting.
We are trying to implement a liable backup strategy with backint and Veeam Integration for short onsite backup retentions and long term (weekly, monthly) offsite retentions.
We observed that there are some limitations with the actual Hana backint Plugin. Correct me if i'm wrong.
- It seems not possible to manipulate backups stored on Veeam Repository through backint. That puts a limitation if we want to plan a copy job to perform GFS retention. So the workaround we are trying to deal with is to perform Short term retention on an onsite backup repository, and to Weekly/Monthly switch backint configuration to perform weekly and monthly backups on an offsite Repository.
- The other thing is that we cannot perform replication of onsite backup with veeam to get those restore points safe on an offsite repo too. Here the workaround we are considering is to perform Storage Replication from Onsite Reposirtory to Offsite Repository.
- Last but not least, it seems the backup retention is not set through veeam configuration but through Hana Housekeeping strategy. So we are going to have to deal with backup and catalog maintenance through scripts.
- Logbackups do not seem to be maintained to a specific amount by the way, so this seems to need to be scripted too.

So would you consider an other way to implement 3-2-1 backup strategy on hana backups?
Thank you for your time.

[clemens.zerbe]

Hi Rurouni,

thanks for reading my blogs and it always helps to get some positive feedback.
Send me a personal message with your contact details and let´s find some time for a quick webex session especially with the new V10 features. This will answer some of your questions and will give you more choice and integration.
Keep in mind that we rely (as everyone else) on the SAP HANA backint interface. There is today not any easy way to get GFS retention enabled with backint. The main challenge is how to handle log entries...as there is no way to delete them individually. They will only be deleted by HANA if ALL fulls are gone at a specific point in time. Or the other way around if you keep one full in your HANA backup catalog history - which needs to maintain e.g. a year - no logs will be deleted between the your yearly full and actual backups.
Therefore you need to combine some of the methods i described in my blog + some HANA cleanup scripts or you can also use the retention functionality in HANA Cockpit.

But once again...send me a PN and lets work on a best fit strategy for you and your company.

Clemens

[clemens.zerbe]

Just as an update to the discussion above as the V10 RTM was released some days ago:

Within V10 you can now:
- create BackupCopyJobs for application backups to a secondery repository with a different retention time than your primary repository.
- create retentions - independed of the SAP HANA retention - within Veeam (Please read the warning accordingly as the SAP HANA backup catalog will not know about this deletion).

These two features will allow much more freedom in following the 3-2-1 rule without any "workarounds".

In addition to the GFS rotation - which is just impossible inside SAP HANA backint - we recommend creating VM or agent jobs with SAP HANA application consistency instead. These full backups have everything (OS + HANA revision actual + SAP HANA data) in one backup and in most cases there is no need to have any additional logs backups for monthly or yearly backups/restores. Within this standard jobs set your own retention needs and they can easily moved to tape or S3 if needed. Do not forget to add SAP CI (or ASCS) and your primary application server -> this enables you directly to logon to the SAP system after a restore.

Clemens

[rurouni]

HI Clemens,
Thanks for the good news.
Where can we find informations about How to perform hana backup copy? Because at this moment it's quite hard to handle and maintain. It it possible with Veeam 9 also or only in Veeam 10?

We consider to plan:
- Snapshot backups for non productive Hana databases vms.
- Backint integration for Productive Hana Vms or Hana instances residing on Physical hosts. So in this case we will Need backup, backup copy, Logbackup retention, Catalog backup also.
- Do you know if Veeam can handle the Housekeeping on Hana instances?

Regards

[clemens.zerbe]

Hi,

documentation for BCJ for Enterprise Plug-ins can be found here: https://helpcenter.veeam.com/docs/backu ... ml?ver=100
It´s a V10 feature.

Some comments on your plan:
- Snapshot backups for non productive Hana databases vms -> fine for me...but let run a backint backup once a week or so. This will do a consistency check on the DB.
- Backint integration for Productive Hana Vms or Hana instances residing on Physical hosts. So in this case we will Need backup, backup copy, Logbackup retention, Catalog backup also. -> with V10 not really a challenge. Use either the SAP backint cleaner script -> https://blogs.sap.com/2018/10/29/hana-h ... nacleaner/ or better SAP HANA Cockpit to do SAP HANA Catalog retention.
- Do you know if Veeam can handle the Housekeeping on Hana instances? -> we do not connect to the SAP HANA instance. So we do not clean up any SAP HANA catalog. In V10 you can do a garbage collection for Repository data. Means Veeam own retention can be set with a command line parameter per host:
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Hope this helps.

Clemens

[rurouni]

Hello All,
We just upgraded our plateform to v10 planning to use copy jobs for sap hana to keep oldest retention points. However we have seen that the embedded backup copy feature for SAP Hana does not permit GFS retention. Only a retention based on à number of points to keep.
How would it be possible then to perform Local backups based on Daily Basis, and Weekly/Monthly Backup stored on a remote site?

The only way i see to perform this would be to perform Daily Full Backint Backups on a Dedicated Daily Repository and perform Weekly/Monthly Backups on another dedicated Repository which would be copied with copy Job on Remote Site Repository? That Would mean having to switch Plugin Configuration each time a Weekly/Monthly Job is executed to switch repostories.

Do you know a way to perform this in a more clever way? Or am i missing something?

Thanks.

[Andreas Neufert]

Thanks for the request.
Please allow me to start with explain why there is a separate retention on the Backup Copy Job instead of just replicating all changes from Primary to Secondary backup place.
The separate retention allows you to implement segregation of duty. A DBA could delete what he want on the primary side (or by mistake) without the secondary backup affected.
So it makes sense to set the setting to +1 day (or longer) as your primary retention is (including GFS).

As we are "just" the backup target for the external backup applications (HANA/RMAN) we do not and can not maintain the chains as we do not have any insights into them.
You can create GFS restore points on HANA by creating additional full backups and name them accordingly. Your retention processing can then decide for what names it will apply what retention.
All restore points are replicated with the Backup Copy Jobs.

If Veeam decides later to actually orchestrate the backups from the B&R console as an additional option, then we could implement GFS processing as we would be aware of what backup files belong to what chain.

[crackocain]

Hello

Backup copy to tape and SAP HANA plugin is supported?

[Andreas Neufert]

Currently this is a more manual process. You can use File to Tape jobs in combination with Import Rescans later. Important point is, that you are on v11 on Server and Plugin and use per backup file metadata. Per Backup file you need to backup and restore always the metadata + backup file in pairs to tape.

[rbienvault]

Hello,
The process is a little more complicated with catalyst item as we cannot do a file to tape jobs when we want to put to tape our monthly full.
At the moment we had to do workaround that I do not like much and require a lot of automation :
-> at the backint agent, we change the repository to a nas repository
-> we trigger a full
-> Once completed, we change back to the "normal repository" (that is a catalyst repository)
-> To avoid breach of RPO, we do another full
-> and now we can create a file to tape job

It would be nice to have a way where veeam is aware that the file is apart of a full backup and to be able to do file to tape with catalyst repositories.
In the case where file to tape is available with catalyst, it will remove the full on another repository, we just have to gather the ebid from the full and copy the files (through api or powershell is fine).

I hope that this process will be more easy in the future.

Note :
We only have to put to tape once a month of once a year depending of system and finance rules.

[Andreas Neufert]

Thanks for the feedback an explanation. The tape functionality is a prominent feature request that we consider for one of the next versions.

[crackocain]

I asked about the ability to send SAP HANA backups to tape. Andreas said it could be done by hand. After rbienvault's post I read that this feature is more difficult to do in backup locations using HPE Storeonce Catalyst. A client of mine is in this exact situation right now and is therefore considering not replacing his HPE Catalyst plug in with Veeam. SAP HANA Linux immutability feature or SAP HANA backups to tape job is critical feature. In this way, the problems experienced in a Storeonce or X solution will also be resolved. We can keep the customer's VM data immutable, but we cannot protect the critical Oracle or SAP HANA database.

[wishr]

Hi Mehmet,

Thank you for the feedback. It's noted.

[johannesk]

We are starting with SAP HANA and I'm looking for ways to protect the data on tape. Is this a feature that will be available soon?
And will it be possible to configure GFS for SAP HANA data on copy jobs as can be done on other copy jobs?

[PetrM]

Hi Johannes,

The request to support tapes for plug-in backups appears quite often and we're going to implement it in our future releases but it will not be available soon. Unfortunately, I cannot comment on ETA. As a workaround, you can try file to tape job.

So far, application backup copy jobs do not have GFS-retention but I noted your request.

Thanks!

[lhan]

hello thank a lot for this interesting dialog about tape copy for SAP HANA and Oracle RMAN. also on our site we are very interesting about this feature.

[Pranav Trivedi]

Hi,
We are using Veeam 12 and we are using sap backint to backup sap hana db to catalyst. But not able to copy backup to tape from catalyst repository... this was most awaiting feture from Veeam for sap hana db backup. Any update on this?

Thanks

[Andreas Neufert]

Hello Pranav,
as you shared, this is a very prominent feature request and a strong candidate for next major version.

[Pranav Trivedi]

Any time line for next major release?

[Andreas Neufert]

Not yet. V12a minor release is planned for this year and then I think the next major release is the next one.

[lukklin]

Hi Andreas,

are there any changes on Back-to-Tape for SAP Hana Backups with V12.1?

If not, is there a guide available for File-to-Tape jobs with Import Rescans you mentioned in this thread.

Thanks!