OK, after the last post, you have a backup image of your Tivoli Storage Manager database by doing a Full backup. Then, during the night the databse on your enterprise TSM systems becomes corrupted. It is 5:00 A.M. and your CIO is breathing down your neck to get it restored. So you just need to take the volumes form the database backup and restore them, correct? Well, close. In this situation, you could, but you would have to manually create a device configuration file and specify each volume of the backup in the restore command. That will slow you down and could be next to impossible. Remember the system where they were not watching the size of the backup volumes in the device class as compared to the size of the database and had over 700 volumes in each backup? Try typing all those into a custom volume history file.
No, rather than put yourself in this position, there are two simple commands that can be scheduled to run in parallel with the backups or can be scripted to run right after the backup. These two commands will backup the device configuration and volume history tables in your TSM database to flat text files on the file system. These are (in their shorthand form):
ba devconfig f=F:\backups\devconfig.out
ba volhist f=F:\backups\volhist.out
The first line will backup the the device configuration file. Now you ask, why do you need that? The device configuration information is in the database. Won't you get it back when you restore the database? Yes you will, but you need a device to tell TSM where to get the volumes for the restore. And if the device information is in the database and you are trying to restore the database.... Noe you get the picture. So the TSM server, when started up from the command line and told to do a restore will look for a devconfig.out file. Very handy.
The second line backs up the volume history. This is a listing of all the volumes created for sequential disk volumes by the TSM server. These volumes can include copy storage pool sequential disk volumes as wll as the databae backup volumes. But as long as you have this file, you have the info needed to restore the database.
And of course, the only parameter this command really has other than the type of info to backup is the F or File location where you want the information stored. The location is not just the directory, but the file in that directory. And you can designate the same file each time this runs as both of the backup commands will overwrite existing files.
So now we have the database backup, the devcnfig backup and the volhist backup. Next time - how do we schedule or scipt these commands so that a full backup of the database with the acompanying configuration files is created?