Hello Michael
Some of your points against TSM are a little off:
Both products have stong and weak points and both products are getting better.
But both have room for growth. With both the mailings list are a required must
read to the best job.
1) It is hard to do a restore from the server with TSM, but you can define a
scheduled tasked to do a restore. But the product is set up more in mind with
the restore being done from the client end of things, This can be via a web
interface to the client. On unix is set up so that one can restore one's own
files without being root.
Redirected restores are easier from the client end with TSM, harder with
netbackup without the need to be root on the server.
2) Yes there can only be one schedule session running on a TSM client name at a
time. Of course this does not mean that you can not have multiple scheduled
events per client just that only one can run at a time.
But that session can be multi-threaded, so you can do multiple filespaces at
once.
Like netbackup sometimes the product takes some work, to work around it's
basics.
On the adsm-l mailing list some folks have reported that one way to work around
this is to have two or more node names pointing to the same client, each with
it's schedule. Like stories that I have heard of netbackup folks creating
multiple
jobs for a very large filespaces.
3) I have found that our TSM restores start faster then our netback restores.
They used to be very slow in the old days when they would send all the restore
info down to the client which would have to sort the data by media and then
request the pieces and parts. Now they do the selection from the server and
start moving the process before it is all finished. Also most TSM sites backup
to disk and then move the data to tape. So the tapes are not required for the
backup. So they are available for restores. With netbackup a restore has to
wait until the tape drive frees up. Which we have found can be a very long time
with a loaded backup server with tape multiplex action. On one server we ended
up setting the number of tape drives in the storage unit to one less then the
number of tape drives to hold one for restores. TSM will stop a housekeeping
task to free up it's tape drives for a restore.
4) I do not understand this statement can you tell us more?
5) I am an old line mode person so I can not speak much of the tsm admin gui
web interface. But I find that I can see from the tsm server which sessions are
running. A little less detail then the netbackup backup jobs, but more then the
netbackup restore jobs.
But I can also see the processes running in TSM with some stats. So with the
catalog backup I can see how many pages it has backed up out of how many. And
the catalog is a database so it's backup can run with other backup server work,
as long as one defines enought database log space.
You can also write sql queries to gather your own reports.
6,7) The schedule reports only summary status, For the completed status they
have been adding a little more detail with the return codes for a little more
detail on how bad things are. But like netbackup it is a little hard to tell
with the status of a few files were not backed up if that is a good error or
bad error. Over the years they are passing more of the detailed error messages
up to the server so that you can fetch them from the server log. But the most
detailed log like netbackup is on the client. The dsmsched.log (you can change
the filename) without the quiet options lists each file processed and what
happened with it. The dsmerror.log file should receive all the errors. Like
netbackup it can sometimes be fun trying to figure out what they mean.
There are also trace flags that can be turned on from the dsm.opt (option file)
to turn on very detailed logs.
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
ida3248b AT post.cybercity DOT dk
Sent: Friday, July 30, 2004 4:40 PM
To: Denton, Kevin M; veritas-bu AT mailman.eng.auburn DOT edu
Cc: veritas-bu-admin AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Veritas Netbackup vs. Tivoli Storage Manager
Hello KD
Here is my points against TSM:
1. You can't do restores from the TSM server, not even from the commandline.
2. You can only have one session running to client scheduler (TSM bpcd)
3. Restores takes very long time to start, because the client have to search
the server database over the network.
4. Restores are slow because the client updates the server database over the
network.
5. There is no job monitor, quick status overview.
6. You only get completed, missed or failed on a schedule and no indication
of the problem.
7. There no logs to speak of on the clients and as far I know no VERBOSE
option.
I probably find some more points next time I have to work on one of our TSM
customers.
Regards
Michael
On Fri, 30 Jul 2004 14:44:33 -0500, Denton, Kevin M wrote
> Is anyone aware of any documentation out there that is pro
> Netbackup versus TSM?
>
> My management seems to have played a few rounds of golf with some
> IBM reps or something. I'd like to find some selling point versus
> TSM. I've done some poking around and came across a couple
> articles but they actually leaned more towards TSM....
>
> Any help would be appreciated.
>
> Thanks,
> KD
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--
Cybercity Webhosting (http://www.cybercity.dk)
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
