That's also correct. The hugely negative impact from running migration while performing backups is due to the heavy load migration puts on the database (aswell as stealing valuable I/O from your disks which should be used for backups).
Regards Daniel Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 [email protected] http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -----"ADSM: Dist Stor Manager" <[email protected]> skrev: ----- Till: [email protected] Från: Rick Adamson Sänt av: "ADSM: Dist Stor Manager" Datum: 03/15/2012 16:57 Ärende: Re: SV: migration threads for random access pool and backups issue Also, using a random access disk pool that is undersized will result in migration potentially kicking off while the backup/archive process is still running. It has been my experience, and I have often read, this situation has an enormous negative impact to the TSM server performance. ~Rick -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Daniel Sparrman Sent: Thursday, March 15, 2012 4:51 AM To: [email protected] Subject: [ADSM-L] SV: migration threads for random access pool and backups issue Hi A migration process will always only use 1 process per node, independent on the storage media. So if you migrate disk > tape, it's 1 process per node, and if you do tape > tape it's only 1 process per node. As for the original poster, you claim that you need to backup 300TB of data. I'm guessing this is your entire environment and not a single server. However, you describe the process of backing up a fileserver. How large is this server? Generally speaking, I'd say that a 500GB diskpool is way to small to handle a 300TB environment. Originally, you're supposed to size your diskpool to hold 1 day of incremental backups. Since change is usually around 5-10%, that would be 15-30TB of disk to hold 1 day. However, I recommend sending your database/mail/application backups (actually, all large chunks of data) straight to tape since there is no performance benefit in sending it to a random pool (as long as you can stream the data continously, the tape drive performance should be good enough). Sending all of these large chunks straight to tape should reduce the amount of disk you need to hold 1 day of incremental backups from your fileservers. 500GB is still gonna be to small though, I would expect a couple of TB's of disk to handle the 1 day incremental. Other options to reduce the disk storage needed on your TSM server is to introduce client-side deduplication or compression. That will, except for reducing the amount of actual TB stored in your disk storage, also reduce the amount of data you send over your network. Regards Daniel Sparrman Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 [email protected] http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -----"ADSM: Dist Stor Manager" <[email protected]> skrev: ----- Till: [email protected] Från: Christian Svensson Sänt av: "ADSM: Dist Stor Manager" Datum: 03/15/2012 09:40 Ärende: SV: migration threads for random access pool and backups issue Hi Amit, After some investigation I found that TSM can only use one Process (1 drive) per node or one process per collocation group. This is only when you are using Random disk. If you want to use multiple drives you need to change from random disk to sequeneal disk. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: [email protected] CPU2TSM Support: http://www.cristie.se/cpu2tsm-supported-platforms ________________________________________ Från: Christian Svensson Skickat: den 14 mars 2012 07:07 Till: ADSM: Dist Stor Manager Ämne: SV: migration threads for random access pool and backups issue Hi Wanda, Glad to see you at Pulse, but I got a similar problem here in Sweden where the migration only use one process during migration. I was thinking of to open a PMR to understand why it only use one drive. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: [email protected] CPU2TSM Support: http://www.cristie.se/cpu2tsm-supported-platforms ________________________________________ Från: Prather, Wanda [[email protected]] Skickat: den 13 mars 2012 21:36 Till: [email protected] Ämne: Re: migration threads for random access pool and backups issue Since your disk pool is much smaller than what you are backing up, plus you have plenty of tape drives, it doesn't make much sense to send those 3 large filespaces to the diskpool. Create a new management class, send each of those 3 filespaces directly to the tape drives, bypassing the disk pool. W -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of amit jain Sent: Sunday, March 11, 2012 12:09 AM To: [email protected] Subject: [ADSM-L] migration threads for random access pool and backups issue Hi, I have to backup large data ~ 300TB and have small DISK POOL SIZE 500GB. I have 3 filespaces, backing up on single node. I am triggering multiple dsmc, dividing the filespace on directories. I have 15 E06 Tape drives and can allocate 5 drives for this backup. If I run multiple dsmc sessions the, server starts only one migration process and one tape mount. As per ADMIN GUIDE the Migration for Random Access is "Performed by node. Migration from random-access pools can use multiple processes." My Question: 1. On Random Access pools multiple migration sessions can be generated, only if we backup on multiple nodes ? Is my understanding correct or there is any way to increase the number of tape mounts ? 2. The only way to speed up with current resources is to backup to File device class, so that I can have multiple tape mounts? 3. Any inputs to speed up this backup? Server and client both are on Linux, running TSM version 6.2.2 Any suggestions are welcome. Thanks Amit
