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
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE
-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Daniel Sparrman
Sent: Thursday, March 15, 2012 4:51 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE
-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
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: Christian.Svensson AT cristie DOT se
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: Christian.Svensson AT cristie DOT se
CPU2TSM Support: http://www.cristie.se/cpu2tsm-supported-platforms
________________________________________
Från: Prather, Wanda [wPrather AT ICFI DOT COM]
Skickat: den 13 mars 2012 21:36
Till: ADSM-L AT VM.MARIST DOT EDU
Ä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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
amit jain
Sent: Sunday, March 11, 2012 12:09 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
|
