How can I set SAP TDP Retention Period?

[hassul]

Hello all,

We are using backint for our SAP database back-up to TSM. How can I set an retention period of 20 days? I asked our TSM Administrators but they answer me that tdp backup has to be managed from the client. I treid the initSID.utl file but the parameter RETVER produces syntax erros.

Thanks.
Hass

 

[heada]

In the init(SID).utl file, you set the management classes. These classes are the TSM classes that control backup/archive retention.

You can either have the management classes changed within TSM to meet your needs or change the init(SID).utl file to use different management classes.

-Aaron

 

[hassul]

Allright, I guess when defining the management classes the retention period was not set. How can I define new management classes with a retention period of my choice?

 

[cheffern]

That is where the TSM admins come in on the server side.
They control the mgmt classes...
You just assign it to that mgmt class in the initSID.utl file as Aaron suggests.

~

Another way you can set retention up for this -
Use the option MAX_VERSIONS in your initSID.utl file.

for ex.
If you run backups once a week -
you could set it to 3 to retain for 21 days (if all goes well) -

By a "version" it means the full backup plus any/all log files up until the next backup.

By setting a 20 day retention, you do possibly risk losing some archive logs or even backups that would have belonged to a "version"...

Make sense?
-Chef.

 

[hassul]

Hi,

It is starting to make sense to me now. For production systems we use SAP recommendation; daily full online backups and frequent archive logs from the cron. I would like to retain a full version (backup +log) for only a month... which means I will have 29 good back-ups before the last is removed. I guess I can set the MAX_VERSIONS to 30, right?

 

[cheffern]

Yes - that sounds good.
Curious - how big is this database we are talking about?

 

[hassul]

For now very small 38GB, this is a new production system and the growth is not much... about 1,5GB a month.

 

[cheffern]

For now very small 38GB, this is a new production system and the growth is not much... about 1,5GB a month.

So - just to recap what you are saying -
You have a 38GB DB which you back up FULL each day -
Giving you an average of 1.1TB saved each month -

But the database itself is only changing about 1.5GB a month...

If you have good restore capabilities, can you pitch to run the backups maybe 1 to 2 fulls a week?
The logs are there to help you restore to a point in time -
So full backups every day are not really necessary...
As long as you keep the last full backup and have all the logs up to said point in time to recover *to*.

That - given 2 fulls a week - would reduce your space usage from 1.1TB a month down to about 300GB a month.

It just seems that you are using a *LOT* of space that you don't require to be using at this time.
I understand that this is for production, but what does your SLA state for requirements?

My point is, if the database doesn't change much, you really aren't buying yourself that much time in case of a restore (by backing up full every day).

Just my 2 cents here...
-Chef.

 

[hassul]

You are totally right. I want to correct this situation. You know how SAP projects are managed and carried out. People set-up the system, read SAP recommendation and implement it and don't care about cost. Currently there is a huge waste of tapes.

But first I need to remove some 23TB of old backups before I start implementing this new backup strategy.

 

[BBB]

This makes me laugh. We backup >600GB SAP DB, Full, daily.

So - just to recap what you are saying -
You have a 38GB DB which you back up FULL each day -
Giving you an average of 1.1TB saved each month -

 

[heada]

My production (and production only) SAP DB is 2.5TB...backed up full...every day...in 6 hours.

I have 6 systems just like that one.

-Aaron

 

[hassul]

If your system doesn't produce too many logfile per day, what is the use of making daily full backups?

I know that SAP recommends daily full backups for production, but why?

 

[heada]

I can backup the database in 6 hours and restore it in DR in 8 hours. That is the main reason for doing a full every day. There are other ways to make a DR restore fast, but as this system has been in place since 1997 and changing it takes an act of congress (or so it seems) then it is easier to just leave it in place. I generate about 200GB worth of Oracle redo logs a day. Replying those logs takes almost as long as restoring the database.

-Aaron

 

[cheffern]

What Aaron just said makes perfect sense.

Our testing - if you have very little change in the database like Hassul -
shows there is not a real advantage to fulls every day.
Unless you just like to have lots of space used up...

But if your logs are so much that the restore time would be compromised -
then one of the best alternatives would be fulls every day (if you have the capacity for maintaining something so large).

So BBB - why do you back all yours up full every day?
Same reason as Aaron?
The only reason I made the comment was that Hassul said he has very little change in his database.

From my perspective - if you don't have to make it complicated, then don't.
-Chef.

 

[hassul]

Cheff,

I agree. I notcied that in our system there were many read action to th database but very fewcommits and that is why there were so few logfiles per day. In a case of a restore, I have very few logfiles to apply.

 

[cheffern]

I guess I just have a case of "cost & recovery" mindset...
We have a few very large databases as well - some we back up daily, some twice a week...
But if I don't have to back it up that often, I don't.

It all just depends on balancing the backup/restore window & storage requirements, as well as cost to both us and the customer.

Some people seem to follow that golden SAP rule for full backups every day - others just do fulls all the time because management thinks it's the right thing to do, whether they understand what it takes or not.

The more sensible approach is to evaluate what you actually need to meet your requirements.
SLA may govern, but sometimes you can justify (& prove) that things can be done more efficiently...
Which in the right setting can turn heads & get you far =)
<always act like you know what you are doing!>

Anyway, I hope all these comments have helped!
Cheers -
-Chef.