It is assumed that the basic Tivoli Storage Manager setup has been performed as described in TSM-server-initialization.
- TSM server configuration
- TSM database configuration
- TSM storage pools
- Backup management and policies
- Database backup
- Scheduling backups
- Backup of TSM client nodes
- Server parameters and information
On the TSM server Linux machine, connect to the TSM server using the TSM administrative command line tool dsmadmc:
using the username root and password as defined previously. It is recommended not to use dsmadmc from network clients for reasons of security, please use an SSH connection to log in to the TSM server.
Commands within dsmadmc can be abbreviated to the shortest unique string, for example query can be abbreviated as q. The abbreviation is shown in the HELP manual for each command, for example:
help query volume
where letters in Capitals are the shortest form of the command.
Full details of the query commands are in most cases displayed by the format=detailed (abbreviated as f=d) option, for example:
q vol f=d
TSM uses an internal database for keeping track of stored files and configurations, and preformatted disk files (or tape units) for storing actual client node backup data.
The disks which we use for the TSM server volumes will only contain very few, but large, files. Firstly, the fdisk command is used to write a partition table to the TSM disks. Probably you want to create only one partition spanning the entire disk device.
Secondly, the Linux ext3 filesystems used by TSM should be created with appropriate parameters:
mke2fs -j -v -m 1 -T largefile4 /dev/sdXX
See man mke2fs for explanation of the parameters. The actual disk device should replace /dev/sdXX.
TSM works with preformatted Database, Log, and Data volumes on local disks. These should be placed on separate physical devices for performance reasons, and these volumes should be protected by mirroring or RAID-5 for reliability reasons. For Database and Log volumes it is also possible to have 2 or 3 copies on separate physical disks, but with mirrored disks we do not want to use this feature of TSM.
We have mounted the various separate filesystems used below.
In a Linux/UNIX shell prompt, use the /opt/tivoli/tsm/server/bin/dsmfmt formatting tool. Define a 2 GB Log volume:
# dsmfmt -g -log /u3/log/log1 2
Define an 8 GB Database volume:
# dsmfmt -g -db /u2/db/db1 8
Define a 32 GB Data volume:
# dsmfmt -g /u1/data/data1 32
If necessary you may create additional volumes of each type, and with different sizes as needed. The maximum size of a volume is dictated by the filesystem of the server; on Redhat RHEL4 the file size limit is 64 GB, so you must use number less than 64 GB with dsmfmt (63 GB is the proposed maximum size).
The newly formatted Database, Log, and Data volumes are added to the TSM server within the dsmadmc TSM administration tool:
define logvol /u3/log/log1 define dbvol /u2/db/db1 define volume BACKUPPOOL /u1/data/data1
Check the newly defined volumes by:
query logvol query dbvol query volume
After you see both the newly added volumes as well as the predefined TSM volumes, then you may remove the predefined default ones from the TSM package:
delete logvol /opt/tivoli/tsm/server/bin/log.dsm delete dbvol /opt/tivoli/tsm/server/bin/db.dsm delete volume /opt/tivoli/tsm/server/bin/backup.dsm
When these volumes have been successfully deleted from TSM, the corresponding files can be removed from the filesystem as well.
Once the new and larger Database and Log volumes have been configured as above, the size of the database and log should be increased:
extend db 4000 extend log 1000
The units of extension are Megabytes, and you may want to extend the Database and Log up to the maximum size of the defined volumes. Query the sizes by:
query db query log
TSM uses the concept Storage Pool to describe disk or tape areas where backup client data files are stored. The default TSM installation defines 3 storage pools ARCHIVEPOOL, BACKUPPOOL, and SPACEMGPOOL.
We will only be concerned with using the BACKUPPOOL, which should have some parameters modified:
update stgpool BACKUPPOOL description="Backup storage pool" lowmig=50 maxsize=100m
We use a large, inexpensive RAID disk box as secondary storage pool named RAIDPOOL:
define stgpool RAIDPOOL DISK description="RAID disk storage pool" maxsize=100m
and make it a secondary storage pool to BACKUPPOOL:
update stgpool BACKUPPOOL nextstgpool=RAIDPOOL
We could also define storage pools for tape robots at this stage, but we do not currently use any tape robots.
Some disk (or tape) volumes must be defined to the above storage pools. We use only disk volumes on fast SCSI disks (BACKUPPOOL) and slower RAID devices (RAIDPOOL):
define volume BACKUPPOOL /u1/data/data1 define volume RAIDPOOL /u/raid/raid01
TSM uses a hierarchy of management classes and policy set to define backups of TSM client nodes.
Define domain, policy set, and management classes within the dsmadmc tool:
define domain CAMP_DOMAIN DESCription="CAMP's policy domain" define policyset CAMP_DOMAIN CAMP_POLICY description="CAMP's default policy" define mgmtclass CAMP_DOMAIN CAMP_POLICY MGTCLASS1 description="Management Class No. 1" define mgmtclass CAMP_DOMAIN CAMP_POLICY EXTRA_COPIES description="Extra copies of important files" define mgmtclass CAMP_DOMAIN CAMP_POLICY SHORT_LIVED description="Data files with a short backup life" assign defmgmtclass CAMP_DOMAIN CAMP_POLICY MGTCLASS1
In order to activate the backup policy defined by the policy set and management classes, the policy set should be validated and activated:
validate policyset CAMP_DOMAIN CAMP_POLICY activate policyset CAMP_DOMAIN CAMP_POLICY
The destination storage pool for client node backups is defined by means of a Copy Group for the various management classes:
define copygroup CAMP_DOMAIN CAMP_POLICY MGTCLASS1 destination=BACKUPPOOL verexists=1 verdeleted=1 define copygroup CAMP_DOMAIN CAMP_POLICY SHORT_LIVED destination=BACKUPPOOL verexists=1 verdeleted=1 retextra=2 retonly=8 define copygroup CAMP_DOMAIN CAMP_POLICY EXTRA_COPIES destination=BACKUPPOOL verexists=5 verdeleted=1
Here we have specified how many versions of a given file may reside in the storage pool, both if the files exists on the client or has been deleted. We may also specify how many days to keep a file in the storage pool after it has been deleted on the client.
Backups of the internal TSM database must be made to an area of a remote server, in case the TSM database should ever get lost or corrupted. We assume that a remote NFS filesystem /home/backup/TSM is available to us with root priviledges for writing.
For regular database backups define special device classes:
define devclass DBBACKUP devtype=file directory=/home/backup/TSM maxcapacity=2G define devclass FILE devtype=file directory=/home/backup/TSM maxcapacity=500M
This can be used for manual full or incremental database backups:
backup db devclass=DBBACKUP type=full backup db devclass=DBBACKUP type=incremental
However, these backup tasks should normally be performed by an automatic task (see below).
The TSM internal database must be backed up before the database log becomes full:
set logmode ROLLFORWARD define DBBACKUPTRIGGER devclass=DBBACKUP logfullpct=50
Schedules for client node backups (every midnight, or at noon on weekdays) are defined by:
define schedule CAMP_DOMAIN DAILY_BACKUP description="Backup run every night" starttime=00:00:00 duration=4 period=1 define schedule CAMP_DOMAIN NOON_BACKUP description="Backup at 12:00 (laptops etc.)" starttime=12:00:00 dayofweek=weekday duration=4 period=1
Check the schedules by:
query schedule format=detailed
Internal TSM administrative tasks are scheduled for backups of the internal TSM database:
define schedule ADSM_DB_BACKUP type=Administrative cmd="backup db devclass=dbbackup type=full" active=yes starttime=05:40:00 define schedule ADSM_DB_RESET type=Administrative cmd="delete volhistory todate=today type=all" active=yes starttime=05:30:00 query schedule type=Administrative format=detailed
TSM will only permit backups of clients which have been properly registered within the TSM server.
Client nodes (say, <NODENAME>) for TSM backup are registered in the TSM server by:
register node <NODENAME> <node-password> domain=CAMP_DOMAIN
A client node is associated with a TSM backup schedule:
define association CAMP_DOMAIN DAILY_BACKUP <NODENAME>
For laptops you would choose the schedule name NOON_BACKUP in stead of DAILY_BACKUP.
List the set of registered nodes:
or individual nodes by:
query node <NODENAME> format=detailed
We want to restrict the file directories which the client nodes are permitted to back up, because we do not want to backup the operating system files etc. of the clients, but only user data.
For Microsoft Windows clients we must set this up inside the TSM server, because it is very cumbersome and error prone to do this on the client nodes. For Linux and UNIX clients it is more convenient to use the inclexcl.list file with the TSM client.
Define option sets in the TSM server for client backups:
define cloptset WINDOWSOPT description="Backup options for Windows clients"
Define rules within this option set:
define clientopt WINDOWSOPT domain C: force=yes define clientopt WINDOWSOPT inclexcl "exclude *:\...\*.*" force=yes seqnumber=2 define clientopt WINDOWSOPT inclexcl "exclude *:\...\*" force=yes seqnumber=3 define clientopt WINDOWSOPT inclexcl "exclude *:\*.*" force=yes seqnumber=4 define clientopt WINDOWSOPT inclexcl "exclude *:\*" force=yes seqnumber=5 define clientopt WINDOWSOPT inclexcl "include *:\navi\...\*.*" force=yes seqnumber=16 define clientopt WINDOWSOPT inclexcl "include *:\navi\...\*" force=yes seqnumber=17 define clientopt WINDOWSOPT inclexcl "include *:\manus\...\*" force=yes seqnumber=18 define clientopt WINDOWSOPT inclexcl "include *:\manus\...\*.*" force=yes seqnumber=19 define clientopt WINDOWSOPT inclexcl "include '*:\...\My Documents\*'" force=yes seqnumber=20 define clientopt WINDOWSOPT inclexcl "include '*:\...\My Documents\*.*'" force=yes seqnumber=21 define clientopt WINDOWSOPT inclexcl "include '*:\...\My Documents\...\*'" force=yes seqnumber=22 define clientopt WINDOWSOPT inclexcl "include '*:\...\My Documents\...\*.*'" force=yes seqnumber=23 define clientopt WINDOWSOPT inclexcl "include *:\...\Dokumenter\*" force=yes seqnumber=24 define clientopt WINDOWSOPT inclexcl "include *:\...\Dokumenter\*.*" force=yes seqnumber=25 define clientopt WINDOWSOPT inclexcl "include *:\...\Dokumenter\...\*" force=yes seqnumber=26 define clientopt WINDOWSOPT inclexcl "include *:\...\Dokumenter\...\*.*" force=yes seqnumber=27 define clientopt WINDOWSOPT inclexcl "include *:\...\Mail\...\*.*" force=yes seqnumber=28 define clientopt WINDOWSOPT inclexcl "include *:\...\Mail\...\*" force=yes seqnumber=29 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\...\cache" force=yes seqnumber=102 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\Windows" force=yes seqnumber=103 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\Program Files" force=yes seqnumber=104 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\Programmer" force=yes seqnumber=105 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\Temp" force=yes seqnumber=106 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\SWSetup" force=yes seqnumber=107 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\Drivers" force=yes seqnumber=108 define clientopt WINDOWSOPT inclexcl "exclude.dir *:\IBMtools" force=yes seqnumber=109 define clientopt WINDOWSOPT inclexcl "exclude.dir '*:\...\My Videos'" force=yes seqnumber=110 define clientopt WINDOWSOPT inclexcl "exclude.dir '*:\...\My Pictures'" force=yes seqnumber=111 define clientopt WINDOWSOPT inclexcl "exclude.dir '*:\...\My Music'" force=yes seqnumber=112
Notice the double-quotes (") surrounding strings with embedded blanks, and the single-quotes (') for substrings with blanks.
Associate Windows client nodes with this option set:
update node <NODENAME> cloptset=WINDOWSOPT
A number of parameters may be set or inquired with the TSM server.
Each backed up filesystem becomes a separate Filespace within the TSM server:
The TSM server keeps track of how much TSM backup storage is used by each TSM client in each filespace and in each TSM server storage pool:
The nodes' total storage utilization can also be checked by the TSM license system. Update the TSM license information first and then query the storage utilization:
audit licenses query auditoccupancy
To have a weekly update of this information, set up regular license auditing schedules:
set licenseauditperiod 7
Set the number of days that the activity log is kept:
set actlogretention 2