We ran into one performance issue where the NIC and a Fibre Channel card
were sharing an interrupt. When the backups started, the high interrupt
count on both the FC and fast ethernet cards was causing problems.
Once the network traffic was moved to a different card (and consequently a
different interrupt), things started performing as expected.
Thanks, [RC]
|---------+-------------------------------->
| | "Hart, Charles" |
| | <[EMAIL PROTECTED]|
| | IC.COM> |
| | Sent by: "ADSM: Dist |
| | Stor Manager" |
| | <[EMAIL PROTECTED]|
| | > |
| | |
| | |
| | 09/10/2004 06:29 AM |
| | Please respond to |
| | "ADSM: Dist Stor |
| | Manager" |
| | |
| | |-------------------||
| | | [ ] Secure E-mail ||
| | |-------------------||
|---------+-------------------------------->
>--------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Optimizing Exchange backup/recover?
|
>--------------------------------------------------------------------------------------------------------------------------|
We are investigating the use of GigE based backups for Exchange, but
recently we heard from our messaging team that Microsoft was doing GigE on
Exchange and kept running in to degrading performance issues.
Is anyone on the list having any success with GigE backups for MS Exchange?
Regards,
Charles
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
MC Matt Cooper (2838)
Sent: Friday, September 10, 2004 6:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Optimizing Exchange backup/recover?
I really don't think my bottleneck is in the network. I see double the
throughput from other clients. I will double check the clients adapter
settings though. I am thinking that the xchange admin may be doing
backups with default setting on buffers, the the TSM server is running
the backup slow because disk to tape migration is also going on in that
time frame, or I might have to figure out how to start individual group
concurrent backups. If anyone else has any ideas I could use them
Thanks
Matt
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
TSM_User
Sent: Thursday, September 09, 2004 3:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Optimizing Exchange backup/recover?
If this is a 1 GB NIC then you should be getting a lot better speed. I
have seen 90 GB backup through a 10/100 NIC at around 32 GB/hr.
However, that same backup ran at over 90 GB/hr strait to tape through a
1 GB NIC. Is there any chance that the NIC on the TSM server is either
10/100 or is there a lot of other things backing up at the same time as
the Exchange backup.
This may be a case where speeding up the Exchange backup isn't the
issue. You may have a tape, disk or NIC constraint on your TSM server.
The 22 GB/hr your getting is as Mark stated not really that good either.
You did mention that it might be waiting on tape due to disk migration.
Might you also be waiting on availble band width through the NIC on the
TSM server.
Still on the client side we have seen slow downs due to disk access
issues reading the disk that the Exchange DB is on. A long time ago
really old DLT drives slowed things down a bit but now days most drives
are capable of far better than 22 GB/hr.
Just ideas.
"MC Matt Cooper (2838)" <[EMAIL PROTECTED]> wrote:
Hello all,
I have to backup a pair of exchange servers that (windows 2003) that
each have about 200GB of data. It is taking over 9 hours to do a FULL
backup of the servers. I was wondering what can be done to increase my
throughput. I have found /Buffers= and /Buffersize= as performance
options but nothing else. Are there ways to multithread these backups?
Thanks in Advance
Matt
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
==============================================================================
IMPORTANT NOTICE: This communication, including any attachment, contains information
that may be confidential or privileged, and is intended solely for the entity or
individual to whom it is addressed. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure, copying, or
distribution of this message is strictly prohibited. Nothing in this email, including
any attachment, is intended to be a legally binding signature.
==============================================================================
