Thanks so much for all the responses. I'd like to reply to just a few responses for clarification.
Regarding simultaneous copies, Howard Coles said: >I have had migration happening while >backing up to a copypool, while a client was trying to fill up the disk >pool and TSM handled it just fine. and Paul Zarnowski said: >I don't really see the need to write to two devices simultaneously as the backup >data is coming in over the network from clients 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 TMS _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? 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. 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. 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? 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? 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?
