Vaulting

WHAT IS VAULTING
WHAT SHOULD BE VAULTED
HOW OFTEN SHOULD VAULTING OCCUR
WHEN SHOULD VAULTING OCCUR
HOW IS VAULTING IMPLEMENTED IN TSMMANAGER
THE VAULT STATUS WINDOW
THE VAULT SETUP WINDOW
WHAT TO VAULT
LIBRARY HANDLING
SCHEDULING
REPORTING
DISASTER RECOVERY

What is vaulting ?

Vaulting is the process of removing volumes from libraries, moving them to a safe place (vault), waiting for them to become empty and then return them to the libraries for renewed use.

This requires several functions :

Identify which library volumes are eligible for movement to the vault.
Checkout these volumes from the libraries.
Inform the operator about these volumes so he/she can remove them from the library and physically move them to the vault.
Identify which volumes, that are currently in the vault, have become empty and should be returned for other use.
Inform the operator about these volumes so he/she can retrieve them from the vault and bring them back onsite.
Check the returned volumes into the libraries.

Below is an illustration of this process :

The above functions are needed for the daily movement of volumes, but it is not enough.

In case of a disaster wiping out your TSM server and library, you need certain information to enable you to rebuild your TSM server.
Information like :

The placement and size of database volumes.
The placement and size of log volumes.
Which volume contains your last database backup.
Which licenses where enabled.
How where your libaries and drives defined.
And a lot more...

TSMManager collects all this information automatically and will print and/or e-mail this information for you.

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, they 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 contaning 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 backupset volumes.
Backupsets are typically kept for a long period, and like primary pools contaning 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 uptodate data you have in case of a disaster.
TSMManager provides the sceduling 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 chapter above.

The vault status window :

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.

The vault setup window :

This window consists of 4 parts and we will have a look at all of them :

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.

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 aquired from the scratch pool ?
* Does your library have a barcode reader ?

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.

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.

WEB reporting

In some cases it may be convenient to let the operator look at live info, without letting him log into the program itself.
This is solved by the web-access. If you point your browser to "http://mycollectorpc:1950", you will be able to see the vaulting reports and the daily status report.

Disaster recovery

The recovery plan consists of some simple instructions and some supporting files.
These files can always be found on the server where the collector is installed. If the collector is installed in the "c:\program files\jamodat\tsmmgr_server" directory and your TSM server is called "production", then you will find all recovery files in the directory "c:\program files\jamodat\tsmmgr_server\production\vault"

These files are ESSENTIAL to your disaster recovery, so you may want to keep a copy elsewhere. It could be a printed copy, but this is not practical as it takes quite a few pages and will be generated daily.
We recommend using the e-mail function. You receive a daily e-mail with the basic instructions as text and the needed support files as attachments. You should send this e-mail to somewhere outside your own organization. Sending it to your own mail server that is located inside your own computing center is a bad idea.

Below you see a sample of how the instructions for a windows TSM server looks :

RECOVERY PLAN FOR Mette BUILT 24-04-2002 15:20:22
----------------------------------------------------------------------------
TSM was installed in : \\mette\c$\progra~1\tivoli\tsm\server1
Install TSM normally in the same directory and initialize it
----------------------------------------------------------------------------
Copy all saved recovery files to : \\mette\c$\progra~1\tivoli\tsm\server1
----------------------------------------------------------------------------
Change directory to : \\mette\c$\progra~1\tivoli\tsm\server1
Issue command : "..\server\dsmserv format 1 file:logvol.txt 1 file:dbvol.txt"
----------------------------------------------------------------------------
Update devcnfg.out with new devices if hardware environment differs from
the old environment
Issue command : "..\server\dsmserv restore db todate=today"
----------------------------------------------------------------------------
Start the TSM server
----------------------------------------------------------------------------
Edit the file "mark_destroyed.mac" and make sure it reflects the volumes that
were actually destroyed
From a TSM command prompt issue : "macro mark_destroyed.mac"
----------------------------------------------------------------------------
Edit the file "mark_readonly.mac" and make sure it reflects the volumes that
were retrieved from the vault
From a TSM command prompt issue : "macro mark_readonly.mac"
----------------------------------------------------------------------------
Edit the file "build_diskvol.mac" and make sure it reflects the disk volumes
that you want to rebuild
From a TSM command prompt issue : "macro build_diskvol.mac"
----------------------------------------------------------------------------
Edit the file "restore_stg.mac" and make sure it reflects the storage pools
that you want to rebuild
From a TSM command prompt issue : "macro restore_stg.mac"
----------------------------------------------------------------------------
Reregister your licenses :

Last License Audit: 04/14/2002 20:50:18
Number of Managed System for LAN in use: 5
Number of Managed System for LAN licensed: 10
Tivoli Data Protection for NDMP in use ?: No
etc. etc.
01-05-2002 The vaulting function of TSMManager page 1 of 9