Managing MPDL Servers

Mgmt,Admin

This page talks about certain features of MPDL administered machines provided by GWDG.

Like mentioned on other pages, the concepts shown on this page can and must be applied to physical or virtual machines, using identical installation and configuration files. Necessary differences can be kept at a minimum, relating very few files or entries therein.

TSM
TSM, which is short for Tivoli Storage Manager, is a well-known IBM client/server product for, as they would say, data protection, i.e. backup and recovery.

GWDG has licensed TSM and offers some very basic TSM based backup services to their customers. Just plain backup, no archiving or other features like HSM.

So, means to customize MPDL backup using TSM are limited, but still there. First, we can install and configure TSM client backup software by ourselves to have it run closer fitted to our needs.

Installation
Although TSM version 6 has been out now for a while, GWDG is still stuck to the last available version 5, which is 5.5.1.100 - and will be until version 5 will be withdrawn and no longer supported by IBM.

Staying with server version 5.5 allows to use a TSM version no later than version 6.2 on the client side.

TSM software - server or client, maintenance or patch, any platform - may be downloaded from IBM. Select the platform and version, then download the appropriate package.

For a working TSM client all you need to install is the BA (backup/archive) client, which will also pull the API and some crypto packages as its prerequisites. If you put the downloaded stuff into a temporary software repository, tools like zypper will do the right things automatically, when you have them installed the BA client package.

A standard installation done that way is en_US based, there is no need to install further language packages.

Configuration
Like with other old-fashioned software, TSM doesn't really separate its configuration from installation. To do better one should maintain a TSM configuration folder kept apart from the installation directories.

For example create a directory structure /usr/local/dsm/{etc,sbin} and put your main TSM configuration files dsm.sys and dsm.opt into /usr/local/dsm/etc. Next to etc more sub-directories like sbin may follow.

Because TSM will look for its main configuration files in its installation directory - e.g. under /opt/tivoli/tsm/client/ba/bin some symbolic links will help pointing to the right files:


 * 1) mkdir -p /usr/local/dsm/etc
 * 2) cd /opt/tivoli/tsm/client/ba/bin
 * 3) ln -s /usr/local/dsm/etc .cfg
 * 4) mv dsm.{sys,opt} .cfg
 * 5) ln -s .cfg/dsm.sys
 * 6) ln -s .cfg/dsm.opt

Note: It's possible to replace dsm.opt with an global environmental variable. For the sake of simplicity symbolic links will be used for both files.

Then the contents of the main configuration files may look like this:

* settings to backup local systems (i.e. local partitions or parts thereof) servername         local tcpserveraddress   tsm.server.com tcpport            1234 * if nodename is not like hostname -f, then set nodename: * nodename           a.host.your.company.org passwordaccess     generate inclexcl           /usr/local/dsm/etc/dsm.excl schedlogretention  10 schedmode          polling schedlogname       /var/log/dsmsched.log
 * 1) cat dsm.sys

This servername stanza shall be the first one to reflect the default setting. More stanzas, e.g. for common virtual nodes, may be appended in the same manner.

quiet dateformat         3
 * 1) cat dsm.opt

To exclude certain data g a TSM include/exclude file dsm.excl is set up:

exclude.dir        /.../tmp exclude.dir        /.../temp exclude.dir        /.../cache* exclude.dir        /.../*cache
 * 1) cat dsm.excl

Passwordless Access
To access a TSM from a TSM client, an appropriate account, called a TSM node, has to be created on the TSM server. Like other account information, an TSM node account consists of a TSM node name and a TSM node password.

The configuration shown above will use stored account information to make any TSM access, apart from the initial setup, passwordless.

Background
The TSM client configuration option passwordaccess generate will write some password information to the local file /etc/adsm/TSM.PWD</tt> when the TSM client is called the first time on a specific servername stanza entry, so that subsequent calls to dsmc will not ask for a password any more.

The following data will make up an password entry in this file:
 * servername
 * nodename
 * password

That's one reason why servernames should be chosen carefully. If the servername value is be changed, the stored password entry will not work any more. To make the change work, the password entry will be recreated automatically, if the known password is supplied.

Initial Setting
Unfortunately TSM server administration choose to set up a new TSM node entry such, that the initial password has to be changed, when the TSM client contacts the server for the first time. This server behaviour, together with the passwordaccess generate client setting, will produce an automatically chosen and set unknown password, which makes it impossible to access any data backed up from this nodes from remote, e.g. for disaster recovery.

To overcome this behavior, the passwordaccess generate client setting has to be disabled (eg. by decommenting or deleting this line) before the first contact is made. Then, the client is prompted for a new password, which, after re-enabling the passwordaccess generate option, will be stored locally like described above. But now, the newly choosen password will not be changed any more and therefore is known and available e.g. for remote access.

Especially o-called virtual shared TSM node have to be handled that way, because this type of nodes are intended to be accessed by any node. The trick shown here will allow to access these virtual nodes from anywhere passwordless also using the passwordaccess generate option.

Automated Backups
For having automated backups establish passwordless access first.

Using the TSM scheduler
If scheduled backups are provided at the TSM server, this service may be used by running the famous mdsm script as /etc/init.d/mdsm</tt>, which can be found [[media:initd.mdsm.txt|here]].

It has just to be set up like this:

mdsm: start: started scheduler (pid 1234)
 * 1) chkconfig mdsm on
 * 2) /etc/init.d/mdsm start

Using cron
Otherwise or as an alternative use a custom backup script found [[media:dsmbackup.txt|here]] as /usr/local/dsm/sbin/dsmbackup</tt> and have it run by regularly using a crontab entry like /etc/cron.d/dsmbackup</tt>:

00 01 * * * root /usr/local/dsm/sbin/dsmbackup
 * 1) perform regular backups

Afterwards have a look at the log files created as /var/log/dsmsched.???</tt> resp. /var/log/dsmbackup.???</tt>. Also, in both cases errors might be written to /var/log/dsmerror.log</tt>.