Backing up MaxDB with TSM and ADINT

[Former Member]

Hi all

At the moment we are backing up MAXDB with TSM and ADINT straight to tape

With the price of ADINT agent being so high we are looking at other solutions

What is the implications of using TSM to backup to Disk as a flat file and then Backing up to tape, therby not using the ADINT agent.

What are the risks of this approach

What other suggestions do you guys have

Thank you very much.

[lbreddemann · Accepted solution]

>

> What is the implications of using TSM to backup to Disk as a flat file and then Backing up to tape, therby not using the ADINT agent.

Sorry, I don't get it.

What do you use TSM here for at all?

MaxDB is able to create backups to the filesystem or to tape directly. There's no need to use TSM or any other 3rd party backup tooll for any of that.

> What are the risks of this approach

Well, If you make it look to MaxDB as if you're using a 3rd party backup tool it will keep record of the backups just with this information.

Therefore, if you have to do something in the 'background' to make this work, your recovery processes may get more complicated by this.

And complicated recovery processes are the last thing you want for your database.

> What other suggestions do you guys have

Backup directly to tape/disk or accept that keeping backups costs money.

regards,

Lars

[Former Member · Accepted solution]

Thank you for your reply Lars

The main reason for using TSM is the ease of management of the Tape library and the scheduling of backups.

We have 4 MaxDB databases that we backup, the biggest being 250GB.

We have the TSM license but not the license for ADINT.

Currently our sister company is backing up our databases using TSM and ADINT.

That is why i am looking at using TSM without using ADINT.

[lbreddemann · Accepted solution]

> The main reason for using TSM is the ease of management of the Tape library and the scheduling of backups.

Have your cake and eat it too? Won't work.

> We have the TSM license but not the license for ADINT.

> Currently our sister company is backing up our databases using TSM and ADINT.

> That is why i am looking at using TSM without using ADINT.

As I wrote: of course you can perform a disk backup with MaxDB and backup this to tape with your TSM.

E.g. you may schedule the disk backups via DB13(C) in NetWeaver and backup these file backups to TSM afterwards.

But obviously this makes everything much more complex.

You've two chains of control then (DB13 and TSM scheduler).

You've multiple log/error facilities that all need to be checked everytime to ensure the backup process worked as expected.

You've to either manually remove the file backups from the file system after TSM has correctly backed them up or you've to allow MaxDB to overwrite them (you don't want that. never !).

When you've perhaps already have a license for Backint for Oracle, then you can use the adapter program from MaxDB to use this interface.

Based on the far too large experience of customer systems that had no good backups I'd defitively vote for the simplest and most robust solution you can get.

Always think about the recovery situation - how complex can your recovery process become until it fails in your organization?

regards,

Lars

[Former Member · Accepted solution]

Andre,

we're doing exactly what you want to do: backing up MaxDB as a data file and move the data file into the TSM library using the TSM client. We do this because the ADINT licenses are so expensive and we're running currently more than 100 databases...

We're scheduling the backups from outside the MaxDB/SAP by running cron jobs and scripts. The MaxDB backup is done by calling a simple dbmcli command and after the command has succeeded we run the TSM command to move the backup file into the TSM library. After finishing the TSM command, the data backup is deleted from the file system.

When adopting this method to your environment you may want to establish a cronjob which is responsible for the backup of all three MaxDB instances step-by-step.

But to be honest: this procedure is fault-prone and nonelastic. Thus I would not recommend it!

André