See in line answers below See Ya' Howard
> -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of steve sorenson > Sent: Tuesday, September 30, 2008 11:44 PM > To: [email protected] > 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.
