Friday, March 6, 2009

Keeping Your TSM Database Safe

Today's post is going to be along the lines of the new movie Watchmen. The movie looks at who is watching the watchers. that while the super-heroes are watching over the world and taking care of keeping it safe, who is watching over them? We are going to look at who is watching the data. While Tivoli Storage Manager does a great job of backing up your data and keeping it safe, what keeps TSM safe.


The answer to that is the TSM admin. It is the responsibility of the admin to make sure that the data gathered by Tivoli Storage Manager and the meta data for that data is kept safe until it is needed. Of course in a perfect world it would never be needed because nothing would get lost or destroyed. In the real world, this does not happen. So the admin for the TSM system had better be sure the backup data and the information to access that data is available when people need it. Because not only can the servers and workstations in the domain suffer lost or destroyed data, so can the TSM system.


There are many different portions of the TSM system that need to be protected and can be very easily. The storage pools can be backed up to copy storage pools to create offsite copies of the domains data, the database information can be mirrored to multiple disk locations to lower the risk od database loss, and, as we are going to talk about today, the database can be backed up to flat files. These files can be stored offsite to keep your meta data about the other files stored in TSM as safe as possible.


The first step toward keeping the Tivoli Storage Manager database safe is to create regular Full backups and periodic Incremental backups. This type of process can be scheduled inside of TSM so that it occurs at regularly scheduled intervals. To get started we will need to create a disk device class that defines where the backup files will be stored and how large each file in the bakup set. This device class should poit to a disk separate from the disk where the TSM database volumes are stored. Putting your backups to the same disk as the database itself resides on is a very bad idea. Do this and lose a disk and you lose both the database and it's backups. So keep these separate is the first step in safety. To create the device class for this process, execute the following in the command line interface. (Remember my preference for command line from the previous post?)


define devclass backupdevclass devtype=file maxcapacity=1G directory=f:\BackupFiles


or it can be abbreviated as

def dev backupdevclass devt=file maxcap=1G dir=f:\BackupFiles


The abbreviated verbage can be determined in the help text by typing just the characters that are capitolized. As we go through this, we will be referring to more of the abbreviated versions of the commands.


So with the command entered from above, it is now possible to execute the command to backup the database itself. But before doing that, another reference back to the command above:


maxcap - The value I entered of 1G should be altered to go along with the size of your database. If you datagase is less than 2 or 3 G in size, this value is fine. If it is larger, then this value should be larger. Basically, divide the size of all your database volumes by this vlaue and keep the number ov volumes to 10 or less. Other wise the volumes for a restore will get out of control. I have one I am working on where they had this volume WAY two small so that each backup of the database is creating over 700 backup volumes. Not real good for a database restore.


So, we now have the device class created with the directory to a location away from the database and the capacity set to a reasonable level. Next step is the actual TSM backup command:

backup db devclass=backupdevclass type=full wait=yes
or

ba db dev=backupdevclass t=f w=y


So, what does this do? It backups up the database to the directory defined in the file device class backupdevclass doing a full backup and it will lock the command line until it is complete causing us to wait. NOTE: All parameters that require a value with an =, never put spaces around the = sign.


Next step is to execute this at the command line, wait for it to complete, and we have a backup of the database that can then be restored to the system. Nothing to it!


Just to mention a couple of the other parameters before we wait for the next post. If we had used Wait=No then the backup would have executed as a separate process allowing use of the command line window for other things. The status of the backup could be traced with the query process (q proc) command and the results in the query activity (q act) commands. The type of backup can not only be full, but also incremental or snapshot. I have personally never used a snapshot bakcup but do use the incremental to go with a full. I will run a full at night and incremental during the day. Of course the full is needed along with the incremtnals to get a complete inage of the database restored.


Next posts:


What other files are needed with the backup to do an easy db restore?
How to set up the schedule(s) to automate the db backup?
How do you do a restore?

No comments:

Post a Comment