Veritas-bu

[Veritas-bu] Datacenter versus TSM

2003-03-13 06:17:07
Subject: [Veritas-bu] Datacenter versus TSM
From: Colin.Smith AT motorola DOT com (Smith Colin-WCCS07)
Date: Thu, 13 Mar 2003 11:17:07 -0000
>-----Original Message-----
>From: David A. Chapa [mailto:david AT datastaff DOT com] 
>Sent: Wednesday, March 12, 2003 4:19 PM
>To: Dan Chrastil; veritas-bu AT mailman.eng.auburn DOT edu
>Subject: RE: [Veritas-bu] Datacenter versus TSM

>In the past ADSM (pre-TSM) had some very significant problems 
>with scaling after it was installed.

I've had no problems with scalabilty. If you put the I/O into the server, it 
fully utilises it.

>1.  Use of a proprietary Database meant that you had to 
>pre-allocate disk space to be used for your database, if you 
>outgrew this space, it was not an easy task to re-size 2.  

Not the case. It's trivial to resize an ADSM/TSM database, live, online and in 
use. Your OS makes use of a LVM, doesn't it? 

>The other things that I noted was their paradigm for backup 
>was different, Incremental forever.  Their spin is why should 
>you back up the data over and over again if you don't need to. 
> Good point, and I kind of like this idea...however, when I 
>added it all up I became increasingly more concerned about 
>database corruption and recoverability.  What if your backup 

You backup the database after every scheduled session. You can also dump it to 
a portable format. The ADSM database is an RDBMS and has the same benefits. 
It's far more efficient in terms of disk usage than the Netbackup catalog.

>database had problems?  What was the course of action to 
>restore/recover?  While I liked the idea, it was too 
>questionable for client/server technologies, perhaps not as 
>much in the mainframe world, which is where TSM/ADSM 
>originally came from (AD*Star).

In the event of losing your Netbackup server, do you really think it wouldn't 
be fastest to rebuild it and restore the catalog before attempting to restore 
client machines?

>media.  So this is call reclamation.  This reclamation process 
>reclaims all of the space on the tape by moving the data with 
>similar retentions to like media.  Nice process, very cool, 

No. Colocation stops the data from different *clients* from mixing on a tape. 
It makes restores very quick but requires more tape media. Reclamation simply 
moves data off of tapes when they reach a desired level of emptyness, thereby 
freeing the tape for reuse. ADSM makes much better use of tape media than 
Netbackup.

>but if a reclamation process is not finished yet, your backups 
>cannot run, they must wait for the reclamation process to 
>finish before a backup can start.

They can run. With ASDM, you generally have your backups run to disk first and 
migrate to tape later. You aren't nearly as dependant on having tape drives 
free as you are with Netbackup. This actually means you need fewer tape drives. 
200Gb of disk costs what? $1k? An extra LTO drive costs, $3k?

In addition, tape reclamation is a low priority job, backups and even more 
importantly, restores take precedence. If reclamation is running and you want 
to restore something, TSM puts the reclamation on hold and restores the data. 
Try that with Netbackup if it's busy doing something else.

>Before they bought/integrated with Tivoli, there was no way to 
>push out the backup client you had to manually install it on 
>each server.  With the integration of Tivoli you can use 

Rsh, rsync, ssh, scp etc.

>I do not remember their interface, both gui and command line, 
>to be easy. There is a significant learning curve.

No better or worse than Netbackup and the administrative GUI interface is a web 
site, not some massive, bloated and excruciatingly slow Java application.

>The client that had me do this analysis decided to go against 
>my recommendation to stay with NBU and went with TSM.  They 
>spent lots of money and have recently called me up to help 
>them move back to NetBackup not more than 18 months later.

TSM does need someone competent to run it. It's a complex, expensive but 
extremely powerful system. It is an enterprise class product.

-- 
Colin Smith

<Prev in Thread] Current Thread [Next in Thread>