Database Backup and Scratch Volumes

[simbonk]

Hello,

I have just setup a new Tivoli solution over the holidays, but I fear that I have made an error in the configuration... hopefully somebody can let me know that there is an easy fix! (this forum is great by the way)

In my database maintenance plan, I selected a TAPE device class. Now when I view our volumes, in the tape library, there are dozens of volumes that are now marked Private, showing the Last Use as the DatabaseBackup

After doing some research, it would seem that you can only have 1 database backup per volume. I have since moved the database backups to a different device class (on a disk), but I don't seem to be able to reclaim any of these wasted private volumes back into scratch.

Is there an easy or safe way to do this? I have tried an "expire inventory" command, then tried an "update libvolume" command. These volumes do not show up as being reclaimable when I run a query. Would "checkin" / "checkout" of the tape produce the same results?

Thanks for advise / help with this...

 

[moon-buddy]

I would question your decision to move the DB backup to disk as this isn't the recommended way.

What happens, and you are right in observing this, is that TSM WILL USE ONE tape per full database backup and there isn't anything you can you about this. THIS IS NOT WASTED resources. This must be done for DR purposes.

In practice, you need to checkout these DB backup tapes daily for offsite storage. What I do is keep 7 copies of DB backup and let DRM recall older copies automatically. To keep 7 copies or whatever you need:

"Set DRMDBBackupexpiredays days", or do a "help Set DRMDBBackupexpiredays" for details.

If you don't use DRM, you can use 'del volhist" to force DB backup deletion. Again, do a "help delvolhist" for details.

 

[simbonk]

Perfect... thank you very much for the advice, Ed!

Yes, I found that the command Delete Volhistory Todate=Today-n Type=DBBackup should instantly take care of private tapes that I need back as scratch.

But first I shall review what you mentioned about configuring the DRM plan so that the DBBackup process doesn't claim ALL of my available scratch tapes...

-Simon

 

[n9hmg]

If you're doing DR but leaving the tapes in the library - you're not doing DR.
If you have dozens of DR-managed db backups, you have a silly DR retention.

As far as db backups to disk are concerned - Those aren't necessarily bad. While it's not available to me, I have been told that some vaulting services provide FTP access. Shipping your DB securely over the internet means that if (as has happenned) the courier leaves his van doors open and your DR tapes are left scatterred in a competitor's parking lot, somebody can't just restore your database and have easy access to your data. Also, since most people are using recent LTO and most have reasonable database sizes, there is a lot of "wasted space" on a database tape.

For my purposes, I go ahead and send out an 800GB LTO3 db backup tape every day with only 50GB used, for simplicity.

 

[djchopps0013]

As far as db backups to disk are concerned - Those aren't necessarily bad. While it's not available to me, I have been told that some vaulting services provide FTP access. Shipping your DB securely over the internet means that if (as has happenned) the courier leaves his van doors open and your DR tapes are left scatterred in a competitor's parking lot, somebody can't just restore your database and have easy access to your data. Also, since most people are using recent LTO and most have reasonable database sizes, there is a lot of "wasted space" on a database tape.

I would totally agree and if you have necessary disk space and a means to recover then I would highly recommend this method. Not to step on toes moon, so

Let me explain
1) your db doesnt get shipped offisite with your recovery volumes. So if compromised it would be extremely difficult for anyone to recover data. Although we tested and proved that data could be extracted off a copy pool tape that wasnt encrypted or didnt have client encryption enabled. Completly different topic but none the less relavent.
2)If a need would arise to recover your production DB you could do so simply by issuing restore db, if in fact you used devclass=file. No need to identify volumes or recall the media.
3) Recovery, Recovery, Recovery can be simplified tremediously if writing DB backups to disk. Given example is our recovery. We write DB backup to file, tar and zip then scp to our recovery site. Once it lands there a script is kicked off at recovery site and actually untar, unzips and dumps DB files in same directory structure and then runs dsmserv restore DB. This happens once a day.

So are far as recovery is concerned its all automated and if a DR scenario happens I fly to location b insert offsite media and am ready to restore before other admins even get OS's up and running. Thats the benefit. You could never to that with writing DB backups on tape.