Backup Script

OK, we had been talkign about database backups before I rambled off on a couple of other topics. This post is going to talk about using the Tivoli Storage Mnager admin client scripting tool to gather all the parts of the database backup into a single scheduled set of commands.



First you may ask, why the script and why not seperate schedules. The reson is that some of the steps need to occur inthe correct sequence and this makes sure that they do. For example: You do not want to take a backup of your volume history before the database backup completes or you will not have the volumes of that backup defined in it. Se here goes:



Start the script with a deletion of old database backup volumes from the volume history. This keeps the volhist file from becoming too cumbersome over time.

def script backup "del volhist todate=today-5 type=dbb" line=001

This line starts the definition of a script call backup and adds line 1 to that script. Next we will add line 2 which will do tha actual database backup.

upd script backup "ba db dev=backups t=f w=y" line=002

Line 2 to backup the database has now been added to the script. Note that to add an additional line we used the update rather than the define command. Since the script now exists, the rest o the lines must be added with this option. Also the backup is a full backup to allow it to be used on it's own for a restore. Finally not the w=y or wait=yes option on the backup commnad. This causes the script to wait and not process subsequent commands tillt he backup is complete. This is important as we do not want to backup the volume history until th evolues from the database backup have been created.

The next line will cover this exact item.

upd script backup "backup volhistory filenames=F:\TSM_Backup_Files\volhist.out" line=003

So line 3 is added to the script which creates a volume history file of all volumes in the TSM system including the ones just added by the backup. And finally line 4.

upd script backup "backup devconfig filenames=F:\TSM_Backup_Files\devconfig.out" line=004

This line will create a backup of the Tivoli Storage Manager configured devices. This is needed in case the entire database is corrupted and needs to be restored. Part of the command to restore a database is the device class parameter telling the system what device to use in accessing the backup volumes defined in the volume history. Since this info is in the database, it may not be available for a database restore. That is when this file comes in. TSM uses the information in this file to recreate the device configuration before attempting to restore the database volumes.

So now that the script is all ready, only one step remins. Putting it into the administrative schedules so that it runs on a scheduled basis to keep database backups available for a restore.

def sch BACKUPDB t=a cmd="run backup" t=a ACTIVE=y startd=04/02/2009 startt=23:00:00 dur=1 duru=h per=1 peru=D day=ANY exp=N

This will schedule the backup script to run each night at 11:00 P.M. until the system breaks down or someone tells it to stop. There are quite a few parameters on this command, and most of them are default values. I just added them to ensure you knew what was going to happen to the script.

That is enough for today. Again I am sorry I have not been adding posts as I wanted, but hope to improve in the near future. I have left the company I was affiliated with and have started to work as an independent contractor. Hopefully this works out and also leave me more time for items such as this.

Backup Client - Incremental (inc) versus Selective (sel)

Both Incremental or inc and Selective or sel backups are available from the Tivoli Storage Manage backup client. These two backup methods are considerabley different.

Incremental does mainly what it says - it backs up all files that have been added or changed on the file system since the last backup. This is affected by the exclude/include information in the configuration file. In addition, specific files can be backed up by selection from the command in the command line client. In addition the frequency and mode on the managmement class's Copy Group can affect if the file is included. The frequency affects how often the file can be backed up. The mode can cause it to be backed up whether it has changed or not.

Selective is meant to be used for exactly what the name indicates. Selecting individual files for backup. It is to be used mainly if the backup of a file or set of files is know to be damaged. By doing a selective backup, the file can be put into the TSM server again. Care must be taken with the use of Selective backups as more files than intended can be backed up and will affect the number of inactive files being retained. If the policy is for 5 inactive copies to be retained, and a selective backup is made before the file changes then 2 of the copies are identical.

So, unless there is a specific need, use the incremental backup rather than the selective.

Progressive Incremental Backup

First, I apologize for the delay in getting a post on here. I will try to be a little quicker on updates. I have had a hard week with long hours. Haven't even been on TSM stuff. It has been all DB2/400 and Oracle related. But enough of that....

When TSM says it is doing an incremental backup it does not do a normal incremental. Most incremental backups store any file that has changed since the last full backup. Then each incremental that follows backs up that file again. With this method, each incremental backup gets a little larger than the previous and takes a little longer to complete. As an example, take four files file1, file2, file3, file4.

• Full backup - file,1, file2, file3, file4
• File1 changes
• First incremental - File1
• File2 changes
• Second incremental - File1 and File2
• File3 and File4 change
• Third incremental and all subsequent - File1, File2, Fle3, File4
  

So at this point you might as well be doing full backups on each pass. This will conitue until the next full backup. When Tivoli Storage Manager does a backup it goes like this:

• First backup - File1, File2, File3, File4
• File1 changes
• First incremental - File1 (original copy of file1 marked inactive)
• File2 changes
• Second incremental - File2 (original copy of file2 marked inactive)
• File3 and File4 change
• Third incremental - File3, File4 (original copies of file3 and File4 marked inactive)
• File1 changes
• Fourth incremental - File1 (Second copy of File1 is marked inactive)

As you can see, the Progressive Incremental that TSM uses is much more effecient than the than a true incremental. In fact there is never a need for a full backup. You can force one, but the incrementals keep a full set of the current files on the system along with a configurable number of inactive files.

How does TSM keep track of what is new and what has been backed up before? Through it's database. It actually checks every file on the system during an incremental backup and only copies the ones to it's storage pool volumes that have changed. This reduces the amount of traffic on the network while keeping a complete set of the computers data available for restore in the event of loss.

TheTivoli Storage Manager Activity Log

Tivoli Storage Manager keeps track of all of the server's activity in a database table named actlog, or activity log. The question I was asked (which, of course, triggered this post) is whether entries in this log can be deleted. The answer is no. Individual entries cannot be removed and the log as a whole cannot be cleared. With that said, there are ways to restrict either the amount of data stored in the log or the amount of data displayed from the log.



Restricting the Actlog Size:

There are two ways to restrict the size of the activity log or to shit it off entirely. The first of these is by days of retention:

set actlogretention 1 mgmtstyle=date

This command says to keep activity log info for 1 day. The number 1 can be replaced by any value from 0 to 9999 to indicate how many days of log info to keep. If set to 0, then nothing is retained and the log is efectively shut off. This value can be changed as desired. So if something is going to be done that will generate a large number of activity records, just set it to 0 and set it back when done.

The second way to restrict it is by size (I will use the shorthand for this example):

s act 1 m=s

This version of the command is to set the mgmtstyle (m) to size. The example will keep the activity log from exceeding 1 M in size. Again, the valid vlaues are 1 to 9999.



Restricting the Actlog Query:

If restricting the size is not possible then restricting the results from the query is very possible. There are two ways to query the information from the activity log. The most common is the

query actlog (q act)



The second is to use the SQL version to do:

Select * from adsm.actlog

(The biggest drawback of the second format is that the data is returned with 1 column per line)



Both will display the same information in a different structure. And both can be filtered. The Query actlog can be given a date and time filter with the begin and end data and time or by use of the search= parameter. The Select can be filtered the same way as any SQL by designating a Where clause. This can be used if there are a large number of log records that are not really wanted in the returned data. Snad while the select command returns the dater in a bulkier format, it does a better job of filtering the data thatn the seach= of the query option since filters such as Like, In, Not In and others like these are available.



One final thought on querying the TSM Activity Log is that if you will be doing a similar query filter on the log records ona regular basis, this query could be saved as a script and run as needed. For example:



def script QuerySession set sqldisplaymode wide Line=001

upd script QuerySession select date_time, message from adsm.actlog where msgno in (0482, 0407) L=002



After entering the above lines into the command line client (dsmadmc), the query will be saved for future use and can be executed by the command

run QuerySession

which will return all the messages in the activity log with the message numbers ANR0482W and ANR0407I. Various scripts could be saved and executed for various sub-queries in the activity log. (See one more reason I like the command line?) Scripts are very handy in this manner and a future post will be onde on their use.



So, bottom line is that once activity log messages are stored, they are stored for the duration of the retention method definition (size or days) and TSM has no method in place to remove them. But the data returned from an activity log query can be controlled. (And try out the command line interface. While intimidating because there is no point and click, it is not hard to get used to. Makes people think you know what you are doing too.)

Open Invitation for Tivoli Storage Manager Questions

This posting is going to serve as a placeholder for any questions you may have on Tivoli Storage Manager. Just post your question as a comment on this posting. If I can help you out, I will add a post on that comment. Be sure and leave an email address in case I need to ask for any clarification.

The posts up to this one are jsut some items that I thought might help people out. One of the things I am often called in to do is restore damaged databases. Sometimes this is doable. Other times people have not kept good database backups and some of their data is then lost. I am doing this series to give good backup strategies and will include info on the recovery step in case a database is lost.

If other topics are requested, we will leave the backup and recovery for a while and go look into those items.

TSM Device Configuration (Devconfig) and Volume History (Volhist)

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?

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?

Admin Client Options

Before I dive into the backup and restore I did this last weekend I want to give some idea of my preferred working interface. I started working with Tivoli Storage Manager administration through the WebClient that was packaged with version 5.2 and older. I always found this interface easy to work with although also a little cumbersome and out of date (although calling it out of date will seem odd for me in a moment). Then they decided to come out with the new and improved Integrated Solutions Console. And I had thought the WebClient was clumsy. The more I used the ISC the less I liked it. Everything in it seemed to be hard to locate and it took more resources from the machine than I liked. Of course, you can always add the WebClient back in to the new versions, but some of the commands don't work since the parameteres for the commands have changed.

So with both of the available GUI clients hard to use or not truly supported I moved to the only option left - the command line client. This quickly became my admin interface of choice. It is actually much easier to use and easier to work with than wither of the others. It just takes a little time to get used to it. The biggest question that comes up is the format of the commands to enter. This is easily resolved with the great help text that come with the client installation. What I usually do, especially if it is something I am not real familiar with, is open two command prompts. One I use to enter commands while using the other to display help information and the syntax of the command (see picture above).



Of course before you can do this, you need two things. The first is a dsm.opt file that leads to the server. An image of this file with the basic options in it is shown in the second image. The opt file is displaying the three basic options needed to connect:

commmethod TCPIP - How is the client going to communicate with the server. This is the default method and perfectly fine for this method of communication. NamedPipes is a good option when there is close communication and a lot of traffic, but this is best for what we are doing.

tcpport 1500 - If it is going to communicate on tcpip it needs a port. This is the standard default.

tcpserveraddress localhost - Name or IP address of the server. If you are working from the server as I am then localhost is fine.

This is enough to get the admin client connected. But what are you connecting. This is the second of the two items I mentioned you would need. There are two ways to start the admin. Usually when the client is installed, a link is created off the start button for the Administrative Command Line. Another option is to navigate to the baclient under the TSM folder. The name of the executable is dsmadmc. By opening a Windows command line and navigating to this location, you can enter dsmadmc and hit enter. The advantage to doing it this way is that if you mistype the password or exit the client for any other reason, just retype dsmadmc and try again.

Once the dsmadmc is started you will be prompted ro first a user name and then a password. Once those are entered you are ready to go. When you are done, just type quit and the command line will close up.

Intro

Tivoli Storage Manager, or TSM, is in my opinion one fo the finest pieces of sodtware IBM sells. Very reliable, very flexible, very easy to use. It is one of those items that is simple to alter the configuration of on the fly and will keep running for years with only a little simple maintanence.

A little of my background. I have worked with Tivoli Storage Manager for the last 10 years in my position as a Systems Engineer for an IBM business partner. I have used it predominately as a storage repository for the Content Manager suite of document manager software products. In this poition I have had expierence deploying maintaining the TSM Server and the TSM Backup client. I have had expierence moving Tivoli servers from one machine to another, setting up server to server communication for data redundancy, and many other aspect's of TSM. I enjoy working with it and have worked past a lot of the quirks in the product (or more correctly the product documentation) over the years.

On this blog I plan on sharing some of those experiences and answering any question that may arise about Tivoli Storage Manager, the TSM Server or the TSM CLient. As an example, I just finsihed this weekend relocating the TSM server form an aging server to a brand new machine. It took about 4 hours to back up the database, copy it to the new server and restore it. In doing a test run of this backup and restore, I ran into a few of the gotchas that I remembered hitting in the past and had to try and remember how to handle them on this time around. Obviously I did it as the client is up and running very well this morning.

Tomorrow I will detail how that proces was done, step-by-step, and include th eitems that were either potential or real slow downs. Then in future days I will go over the things I am doing on the server to make it ready to work for the client for the next several years.

If you see things in any of my posts that raise questions, please be sure to ask. I want this to be an interchange between myself and you readers. Not just a lecture from me on what I have done.