REUSEDELAY and DRMDBBACKUPEXPIREDAYS Settings

[sfcc]

The following is an excerpt from Chapter 8 of Redbook "IBM Tivoli Storage Manager and DRM" (p. 197):



8. Now, specify the number of days before expiration is used to expire a

database backup series, using the SET DRMDBBACKUPEXPIREDAYS command.

defines criteria for DB backup series expiration. The value applies to both a

snapshot and a full plus incremental database backup series. The age of the

last volume in the series must exceed the expiration value defined here to be

eligible for expiration. The most recent backup series of either type is never

deleted. In Example 8-11, we specify an expiration value of 14 days. To

ensure that the database can be restored to an earlier level and database

references to files in the storage pool are still valid, the number of days

specified by this command and the number of days specified by the

REUSEDELAY parameter in the copy storage pool definitions should be the

same for the copy storage pools managed by DRM.

Example 8-11 Set the database backup series expiration value



tsm: RADON_SERVER1>set drmdbbackupexpiredays 14

ANR6700I SET DRMDBBACKUPEXPIREDAYS command completed successfully.



~~~



My question is why? Why would you want to keep so many copies of the DB? Only the most recent copy knows what tapes are in the vault, in what copypools, etc.. What good does a DB backup from 14 days ago do? Wouldn't it be okay to have REUSEDELAY for the copypool set to 14 days while having DRMDBBACKUPEXPIREDAYS set to something lower, like 1 or even 0?



Thanks for any input that anyone can provide.

 

[heada]

The theory on multiple DB backups (as I see it, I could be wrong) is if you need to go back in time before something expired (and thus removed from the database).



If during normal expiration a file is expired and then the CEO comes to you 3 days later and says he HAS to have that file back, how are going to get it? The only way I know of is to roll the database back to a point when that file was in the database. If you are only keeping your most current backup, you can't restore the database back to when that file was actually on the tapes.



What I do is keep the database for 3 days past the retention of most of the files I backup. 90% of my backups go to a 35 day(version...whatever) so I keep my DB backups for 38 days. It's more of a CYA then anything else, but wasting 37 tapes is cheaper then not being able to restore that one critical file that wasn't critical until someone deleted it 36 days ago.



-Aaron

 

[sfcc]

I can see how that makes sence. However, think about the process of DRM. If it expires a tape ( the tape that contains your older/expired data that you would use an older DBBackup to access). and you take that tape from VALTRETRIEVE state and check it in as Scratch, your data is gone. The older backup is useless......I thought the whole process of DRM was that it would expire older tapes in your vault at around the same speed as the new ones you insert, thus keeping an uptodate pool at all times....sooo, im kinda confused as to how a DB that refrences to a Volume that isnt there any more would be of any help....



thanks in advance for any advice....

 

[heada]

That is where the resusedelay is key. Expire inv will cause a tape to become empty and set in the vaultr state. Once you move it from vaultr to onsiter, it becomes a scratch tape. If you have reusedelay set, TSM will wait that many days before attempting to use that scratch tape. If I have my DBExpireDays set to 35 and my ReUseDelay set to 5, TSM will wait 40 days before that tape is considered for another write operation.



Realisticly, you should only need to keep as many DB backups as the reusedelay is set to because that is the limit that the data on the tape you will be restoring from is likely to still be there. Tapes go offsite...time exlapses..tapes come back "expired"...5 days later you can write to them again. For those 5 days, the data is physically still there but logicly deleted. If you take your database back 5 days (from a DB backup) then you can still restore from those tapes even though it was expired.



My SLA says I will restore data upto 35 days. If some C*O comes to me a says "I really need that data back." I can fudge and get it back for them, even after it's been expired.

 

[sfcc]

Okay, this is making a bit more sense now. Thanks very much for your input! We'll give it a try and report back on our results at some point.

 

[TaTTiCo]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>That is where the resusedelay is key. Expire inv will cause a tape to become empty and set in the vaultr state. Once you move it from vaultr to onsiter, it becomes a scratch tape. If you have reusedelay set, TSM will wait that many days before attempting to use that scratch tape. If I have my DBExpireDays set to 35 and my ReUseDelay set to 5, TSM will wait 40 days before that tape is considered for another write operation.



Realisticly, you should only need to keep as many DB backups as the reusedelay is set to because that is the limit that the data on the tape you will be restoring from is likely to still be there. Tapes go offsite...time exlapses..tapes come back "expired"...5 days later you can write to them again. For those 5 days, the data is physically still there but logicly deleted. If you take your database back 5 days (from a DB backup) then you can still restore from those tapes even though it was expired.



My SLA says I will restore data upto 35 days. If some C*O comes to me a says "I really need that data back." I can fudge and get it back for them, even after it's been expired.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Sorry... but if you restore yuor DB from -5 you can restore the client data, ok... but what about your current data?



sorry for my bad english... :sad:

 

[heada]

TSM is like a time-machine. When you restore the DB to the past to restore a client's data, the newer data hasn't happened yet so the TSM DB doesn't know about it.



What I do when I have to restore my DB to an old copy is restore it to a test TSM server. That way my current data is still intact and normal operations can continue. If this is not an option (no test server or it isn't big enough) then you have to backup your current DB, restore the old DB, perform whatever operations prompted the need for the old DB and then restore the current DB. If you're lucky, this can all be done in the window that you have between backup windows.



-Aaron

 

[TaTTiCo]

Ok! Right, you restore on test machine...



Sorry, but i consider DRM an utility for disaster recovery, i work on versioning to evade the client request. In some case, isn't possible provide a server machine and library for a test environment...i can't (LOL)



Thanx!