#3 - Scheduling

Once you setup vaulting correctly, everything happens automatically.
But it is you who must decide when things are supposed to happen. Select on which days of the week and at which times you want the two main functions to be performed.

The first (called 1+2) is the time when you have finished copying your primary pools to the copypools and you have done a database backup. This is the time when volumes should be checked out and moved to the vault according to the generated list. At the same time another list is generated, showing which volumes to return from the vault.

The second time (called 3) is the time when you are certain the operator has retrieved the volumes from the vault and placed them back into the library, either in the I/O door or directly into the library. At this time, TSMManager will perform a checkin of these volumes and delete them from the "tapes to be returned" list.

#2 - Library handling
In order to make the best use of the facilities of your library, TSMManager needs some information about how to handle it. So, for EACH library that you use, select it in the list and set the appropriate settings for that particular library.

Number of I/O slots in library
If the library has an I/O door (bulk), indicate here how many slots are available in this door. When TSMManager starts checking out volumes, it will assume that the I/O door is empty.

How to handle checkout of volumes
These are self explanatory, select the one which suits you best.

How to handle checkin of volumes
You can select any combination of these options. The selection depends on several factors : 

  • Do you have an I/O door ?
  • Are you vaulting private volumes or just volumes acquired from the scratch pool ?
  • Does your library have a barcode reader?

The vault status window :

Vaulting Details

The vault setup window :

(Consists of 4 parts)

#1 - What to vault:

Vaulting is active for this server

  • You may not want to perform vaulting on all your servers, so you have the option of en/disabling it on a per server basis.

Vault all copypools

  • If this is checked, the manual selection is overridden and all present and future copypools are automatically vaulted. If it is unchecked, you must manually select which copypools you want to include in vaulting, using the "add" and "remove" buttons.

Primary pools to vault

  • Select the primary pools you wish to vault (if any) by using the "add" and "remove" buttons.

Database backups/Backupsets

  • In the bottom part you decide which database and backupset volumes you wish to vault.

Days to retain

  • Database volumes must be deleted from the volhistory after a number of days. This is the only way to release them for reuse. With this setting you in fact decide how many versions of your database backups you want to keep.
  • If you set the setting to zero, then TSMManager will NOT delete your database backups, you must do it manually or by an administrative schedule.

This window is really not needed !

 
When vaulting has been setup correctly, TSMManager will generate the lists and the recovery plan and perform all needed actions without intervention. BUT, it is nice to be able to see what happens and which volumes are located where.

This is the purpose of the vault status window.


With the buttons on this window you can .

  • Show/print which volumes are inside the library and are eligible to be checked out.
  • Show/print the current list of volumes to be removed from the library and moved to the vault. The list you see here will cover today and several days backwards. The list that gets generated automatically only shows the volumes of the day. In case a removal day is bypassed (sickness, holiday, server down...), you can use this list to catch up on which volumes should be removed.
  • Show/print the list of volumes currently located in the vault.
  • Show/print the list of volumes that should be removed from the vault and placed back in the library.
  • Show/print the vaulting log. Everything done by the vaulting mechanism is logged in a log file.
  • Manually initiate the actions which constitute the vaulting mechanism. These actions are normally done automatically by the vaulting scheduler, but you can do them manually if you wish.


All the lists are maintained by TSMManager and should NEVER be edited directly by you.

#4 - Reporting
Generate recovery plan
Decide whether you want to generate the plan or not.

Access to input files...
It is VITAL that the following files are saved as part of the recovery plan :

  • DSMSERV.OPT which is the server option file.
  • VOLHIST.OUT which contains information about the last database backups.
  • DEVCNFG.OUT which describes your hardware environment.


All 3 files are located in the server installation directory and you must provide the information necessary to access them.


VOLHIST.OUT and DEVCNFG.OUT are generated by the TSM server if you have the appropriate statements in your DSMSERV.OPT.

You must have two statements as follows :

  • devconfig devcnfg.out
  • volumehistory volhist.out


After entering the required information, use the "Test access" button to verify that the collector part of TSMManager is able to access the files.

Where to put report and ...
The daily report, telling the operator which volumes to remove from the library and which volumes to retrieve from the vault, can be e-mailed to a receiver and/or printed.

  • The same goes for the recovery plan.


A note on printing :
Printing is performed by the collector part of TSMManager. The collector runs as a Windows service, by default under the system account. The system account does not have a printer defined and is also not able to have it, so it cannot print.
In order for the printing to work, you must run the collector service under a userid that has a default printer assigned to it.

What should be vaulted ?

  • Database backup volumes, full and incremental.
  • Database snapshots.

Whether you use regular DB backups or snapshots backups or both, it is essential to have a copy of the database in the vault. Without the database to describe the contents of the rest of the volumes are worthless.


  • Copypool volumes.

Of course !


  • Optionally volumes from primary storage pools.

In some situations it makes sense to vault primary volumes. It could be an archive pool with data kept for many months. It could also be volumes from a storage pool containing large backups from databases that are to be kept for a long time. In both cases vaulting could be a good idea, either to free space in the library or simply because volumes are safer in a vault.


  • Optionally backup-set volumes.

Backup-sets are typically kept for a long period, and like primary pools containing archive data, it could be sensible to keep them in the vault.

How often should vaulting occur ?

Whether you vault 7 days a week, only Monday to Friday or maybe only once a week, is up to you. The more often you do it, the more up-to-date data you have in case of a disaster.
TSMManager provides the scheduling mechanism you need to implement this.

When should vaulting occur ?

You will have to decide on two points of time during the day.
The first is the time when you have finished copying your primary pools to the copypools and you have done a database backup. This is the time when volumes should be checked out and moved to the vault. At the same time a list is generated, showing which volumes to return from the vault.

The second time is the time when you are certain the operator has fetched the volumes from the vault and placed them back into the library, either in the I/O door or directly into the library. At this time, TSMManager will perform a checkin of these volumes and delete them from the "get from vault" list.

How is vaulting implemented in TSMManager ?


The best way of describing this is to go through the various Windows of TSMManager and refer to the information above.

Select for additional details:



Click Here for a FREE 30 day 'Full Function' Trial