Backup multiple computers under same NODE

[christian]

Hi there.. I have a big probleme :-o



I have a client who has 2 computers...



What will the correct way be to backup those 2 computers??



To add them both under one NODE, og adding seperate nodes for each computer..



I have tried installing the client on both computers, with same NODE name and Password, and it works fine.. BUT scheduling is a probleme because the logs are very strange..



WHAT is the correct way of handling 2 computers.. Each in one node? OR..



Please solve my probleme...

 

[fbailey19]

You have the right concepts and that will work however the bigger issue may be the FileSpaces in TSM. Because TSM Might Think the CLients are One in the Same and Combind the Filespaces that might cause an overwrite of a file that is on both systems and backups happen.



This will not be a problem if the Client System has different OSs or different TSM Client Code.



Is this a Cluster? Or just 1 Host name on 2 systems.



If it is a cluster then Read the TSM Client Guild on how to set up the dsm.opt and or dsm.sys files.



If it is two seperate systems then Best practice is to have different TSM Client Names IE: system_a system_b.



If that will not work and you are not using DHCP you can give the Full Host Name in the dsm.sys and or dsm.opt file IE: hostname.conpany.



Or you can use IP Address for the node name.



When these are not options then I would create seperate domains, policy sets, management classes, and copy groups for each (system). If you create different Domains and etc the you will not run the risk for what TSM calls BINDING of Data. IE:



For SYSTEM 1 (system1=client name)

def domain domain1

def po domain1 system1

def mgmtcl domain1 system1 system1

def co domain1 system1 system1 standard t=b vere=num verd=num rete=num reto=num dest=storagepool_name

def co domain1 system1 system1 standard t=a retv=num

val po domain1 system1

act po domain1 system1



Repeat the same step for system 2 just make the domain name (domain2). Then Just create the Schedule.



You can Also

Go to the dsm.sys (for UNIX) or the dsm.opt (windows) or if your using a include.list file and place the Management class name into the top of the file. INCLUDE MANAGEMENT CLASS NAME



I hope this Helps



Let me Know

 

[chad_small]

Never use the same node name for different machines. The problems lies how TSM views the systems and their Data. Since the two systems will have different security and filesystem structures TSM will consistently expire data it sees on one node but it doesn't see when the doing the backup on the other (and vise versa). Will will cause huge headaces and potential loss of data within TSM. Always use different node names for different machines. The customer can still access the other machine from the GUI or command-line so accessing the files between the two is not a problem. Just make sure that if one system is NT and the other Unix you do not access the TSM server from the NT box as the Unix server, it will hose the TSM DB client settings and it takes support giving you undocumented commands to reset the node information.

 

[Sunhillow]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Just make sure that if one system is NT and the other Unix you do not access the TSM server from the NT box as the Unix server, it will hose the TSM DB client settings and it takes support giving you undocumented commands to reset the node information.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



chad_small, this is a very very important point. It once happened to me and took one whole night on the telephone with IBM hotline to repair the node settings.



It is a funny "feature" of TSM to have "unicode clients" and "non-unicode clients". If you access the TSM server from a unicode client with the nodename of a non-unicode client, the server will from this time on only accept unicode clients under this nodename.



This means, the UNIX client is no longer able to access its data.



IBM should make the client versions compatible to avoid such things.



[edit] spelling