See in line answers below
See Ya'
Howard
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of steve sorenson
> Sent: Tuesday, September 30, 2008 11:44 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] NBU user considering switch to TSM
>
> Thanks so much for all the responses. I'd like to reply to just a few
> responses for clarification.
You're welcome.
> Regarding simultaneous copies, Howard Coles said:
> I'm not talking about migration and backups happening at the same
time,
> or even multiple migrations happening at the same time.
>
> First, let me verify what I was told TSM _could_ do. I was told that
> during
> the initial backup (if you went straight to tape, such as with a large
> dataset), TSM could write to two tape drives simultaneously, making
two
> copies in the time it takes to make one. Is that part true?
Yes.
> I was told that, while it could do that during backups, it couldn't do
> it during migration/copies. I'm talking about one process reading
from
> the disk pool, simultaneously putting a copy of each file in the
dataset
> into the primary tape pool and in the copy pool.
False. It can.
> When used in NBU and disk staging, it means you can back up once to
> disk,
> then copy once to tape, but when that copy is done, you have an onsite
> copy
> and an offsite copy, but you only had to do one operation. It would
> seem
> that doing it twice would take longer.
Not sure about NBU, but with TSM you can either send a client straight
to tape and make a simultaneous copy to a copy pool, OR if they go to
disk you can then backup to a copy pool, while migrating the data to a
primary (onsite) tape pool. You can also simultaneously copy the data
to an active data pool, while sending it to the primary disk pool, etc.
etc. (or, at least I think you can I have not tried this last part).
The combinations here are numerous.
> Regarding the TSM server having to do all migrations/copies, Howard
> Coles
> said:
> >Why would you want the client to be worried about that?
> >The server is the box that you want
> >handling the data once its handed off so that the client can go about
> >its main purpose.
>
> NBU has the concept of media servers, which are subordinate to the
> master
> server. The master server _controls_ and creates database entries for
> all
> operations, but the I/O of these operations can be done on these
> subordinate
> servers, allowing you to scale a single NBU environment to beyond the
> capabilities of a single NBU instance beyond that of a physical
server.
>
> TSM seems to be the opposite, as you sometimes have multiple instances
> of
> TSM in a single physical server. Why is that?
Well, TSM has master and client servers when it comes to sharing a
database, but it never puts that load on clients. And, I still wonder
why you would want to.
IMHO - NBU obviously has the data handling focused on the wrong box. You
do not have to have multiple instances of TSM, and especially not on the
same box (if you are talking Server side here). On the client you can
do some very interesting things by using multiple node names for a
client. And, having a second instance of a TSM server is always handy,
for storing retired nodes, or nodes with legal holds on data in a
certain range, for example. (which is how we're going to be setup in
the near future).
The issue here is where do you want your data handling, and how much
Network/SAN traffic do you really want? TSM's principle is, "get the
data from the client, tell the client you have it, and then let the
client go on about its business". The client doesn't know where its
data is, and doesn't need to know, all it needs to know is that TSM has
it. As a matter of fact as a TSM admin I have to do some interesting
queries to find out what tapes a particular node's data is on.
There are reasons, and times when you'll need a second instance of TSM,
but in that large of an environment you'll need TSM not NBU anyway.
Just my Not so humble opinion. :-D.
> Howard Coles said:
> >You use the TSM GUI and/or command line to
> >do all the restores whether it be a backup set, or a backup from the
> TSM
> >server.
>
> But the contents of the backup set aren't in the TSM database, right?
> Isn't
> that the point of the backup set, to make an archive of a bunch of
> files
> that aren't tracked in the database, and that can be read outside of
> TSM?
> So if the contents of the backup set aren't in the database, how could
> you
> do restores the same way as you do with regular backups?
Well, partially. The purpose of a backup set is to make a client's
backups portable. You are correct in that the contents of the Backup
Set are not in the database (because they were intended to be removed
from TSM and handed off to a client). However, you will need the TSM
client, preferably the version that did the backup or newer, to import
the backup set at the client, and hardware to read the tape/media used
to create the backup set.
> Thanks again for my overlooking my ignorance. I'm just trying to
> understand
> how I would architect a new system based on TSM. How do you recommend
> someone mostly new to TSM moving forward with such a thing?
Take a class. There is so much to TSM and so many possibilities that
you'd get weary doing it all over this medium. There are some great
Redbooks, even though some are a little dated, that will help you with
the principles and practices of setting up TSM and architecting a good
environment. I still refer to them, and often.
Finding someone that's somewhat local to you who can help you implement
TSM is very helpful as well. Just make sure they really know TSM,
unlike a consultant we had help us once. He didn't know you had to run
reclamation on offsite (copy) storage pools.
|
