TSM is IBM's backup solution. It is a really nice setup when you have a large mixed network whose workstations and server you want to backup. As in many backup packages, we have two parts: server and client. All the important configuration details -- when to backup and what -- is stored in the server; the client does not know much about besides how to authenticate and such stuff. The best way to have it working is when the server contacts each client at the scheduled time and start pulling the files out. This way the server can keep a grip on the load while there is not much work to be done in the client.
In this installment we will talk about the client, which in TSMese is known as a node.
Client setup and install
First thing we need to do is to install the TSM client in the machine we want to backup. The client is freely available at the IBM website. You probably want to get the latest version. Also do notice they have clients for OSX, Linux, Windows, and Solaris, just to name a few operating systems. Installation varies with the client OS. In the case of Linux, you would download and install a few rpms, so you may want to make sure you know how to install an rpm. The proper thing to do is to read up on it, say, its manpage. The quick-and dirty way is to try something like this:
# rpm -i package.rpm
and hope it will work. YMMV. The ones you really really need to install are the ones for the TSM B/A client and the API. During install they may ask for a library they depend on; just go and get it and make it happy. If you install it in a Linux or Solaris box, the packages will be placed in /opt/tivoli/tsm/client/.
Once you have the packages installed, you need to configure the client. Before we continue, we are assuming that we are back in our favorite kitcar company, Cannelloni LLC, and want to backup the fileserver, obelix. The TSM server is assurancetourix.cannelloni.com. So, we should by now have told the TSM server that obelix is a new node and associated a schedule with this node. The client configuration file is called dsm.sys and is usually found in /opt/tivoli/tsm/client/ba/bin. A typical dsm.sys file looks like something like this:
************************************************************************ * IBM Tivoli Storage Manager * * * * Sample Client System Options file for UNIX (dsm.sys.smp) * ************************************************************************ * This file contains the minimum options required to get started * using ITSM. Copy dsm.sys.smp to dsm.sys. In the dsm.sys file, * enter the appropriate values for each option listed below and * remove the leading asterisk (*) for each one. * If your client node communicates with multiple ITSM servers, be * sure to add a stanza, beginning with the SERVERNAME option, for * each additional server. ************************************************************************ SErvername tsm COMMmethod TCPip TCPPort 1609 TCPServeraddress backup.cannelloni.com passwordaccess generate nodename obelix managedservices schedule memoryefficientbackup yes
where:
- SErvername Name of the TSM server
- TCPServeraddress FQDN (or IP) for the TSM server. We would think that is a bit important so the client knows where to find the TSM server (and probably to know which servers it should accept commands from).
- nodename The name of this node as defined in the TSM server. You can call it anything you want. It can be the FQDN of this machine or some silly name. TSM does not care while you use the right one. That also means you can backup to one machine and restore to another machine and TSM will not be any wiser; it only cares about authentication. Note: In this example, the true name of this machine is assurancetourix.cannelloni.com. backup.cannelloni.com is a CNAME we created to make it easier to find it. Also, it sounds very official and functional.
- COMMmethod Which protocols we will use to talk to the TSM server.
- TCPPort This is the port the TSM client will open in obelix so the server can connect and talk to it. We may have to be sure the firewall in obelix has that port open (per COMMmethod, for tcp traffic only, not udp).
- managedservices
can be used to tell the client which tasks it should run. If you leave it blank, it will run a webserver that will allow others to connect to this machine to run the TSM client. By saying schedule we tell it only to run the scheduler.
Running the client
If this is the first time the tsm client is run in this machine, obelix, we need to do a full backup. That is done by issuing the command
# dsmc incr
and waiting for a while. A long while depending on how much stuff you have. To give you an idea, backing up some 300GB took about 8h in a connection that was supposed to be gigabit all the way between TSM client and server. So, either run this in the background and go dome something fun in the outside or use the time to read up on stuff you have been avoiding.
Once that is finished and there are no errors or funny business, we then start the normal incremental backup, which is done by typing
# dsmc sched &
Of course the next step would be to write a startup script to run that command whenever the node boots up.
