ADSM-L

Re: HELP! Faster Restore than Backups over Gigabit?

2002-10-31 13:27:35
Subject: Re: HELP! Faster Restore than Backups over Gigabit?
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 30 Oct 2002 22:36:31 -0500
You have lots of RAM, but what is your bufferpool size.  For this size of
machine memory, I would use at least 256MB for the bufferpool size.  Also
beef up the logpool size as well.  Your TSM DB and log are very small.  Do a
Q DB F=D command and see what your database hit percentage is.  If it is
less than 98 percent you need to increase the bufferpool.

Did you TSM mirror the Database and Log?  If so, it is probably useless
because you are already running protected disk.  Remember, on RAID 1 you
still have to write all data twice and on read back both drives can be used
as a source if the RAID card is smart enough to do that.

I am betting that you are overrunning the RAID card during the backup.  Are
the RAID 1 mirror volumes on the same physical SCSI bus as the primaries?
That could be the issue as well.

Hope this helps.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Vin Yam [mailto:vyam AT QBCT DOT COM]
Sent: Wednesday, October 30, 2002 11:14 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: HELP! Faster Restore than Backups over Gigabit?


Hi,

Our backups are set for an absolute serialization.  We backup and restore
the same number of files and the same amount of data 42 GB.  The TSM server
is configured in a RAID 1E0 with a ServeRAID 4Mx adapter.  The client is
using a RAID 1.  We are going straight to disk since our diskpool is 150 GB.
We've tried formatting the partition that the diskpool is on in 64k blocks,
but it hasn't proved much help.

Is there a case where the TSM DB can be TOO large?  Our TSM DB volume is 1
GB in size and our recovery log is 250 MB in size.  We have 4 GB of RAM on
the TSM server, so we didn't consider this to be a problem.  Thanks for any
help.  Please email me if you need more information.

-Vin
vyam AT qbct DOT com


-----Original Message-----
Forum:   ADSM.ORG - ADSM / TSM Mailing List Archive
Date:      Oct 30, 00:08
From:      Seay, Paul <seay_pd AT NAPTHEON DOT COM>

Actually, the 2048 TCPWINDOWSIZE is not supported in NT to my knowledge.  It
is supported in W2K at SP1 or 2, cannot remember, with a registry hack.
Someone else will have to give the particulars on that.

Be careful comparing restores to backups.  Depending on what numbers you are
using, you may get the wrong conclusions.  Make sure it is the same files
backed up that were restored.  Also, look at where your backup is going to
on your server.  If it is going to RAID-5 storage pools, that is it.  The
write penalty on the RAID-5 Array is the cause of the backup delay.  If you
are going directly to tape, I do not know what the issue is without a lot
more information.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Vin Yam [mailto:vyam AT QBCT DOT COM]
Sent: Tuesday, October 29, 2002 7:16 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: HELP! Faster Restore than Backups over Gigabit?


Hi,

We just installed Gigabit fiber NICs and an isolated gigabit fiber switch.
Our restores have increased dramatically from 31.81 GB/hr (8.84 MB/s) to 56
GB/hr (15.6 MB/s).  The backups are still around 35.5 GB/hr (9.8 MB/s).  The
TSM server is very powerful (NT 4.0 SP6a Dual 1.8 Ghz P4 w/ 4GB RAM, 150 GB
RAID array) and the clients are (Netware 4.2 Quad XEON P3 w/ 4 GB RAM).
(We've tried changing the TCPWindow Size in our dsmserv.opt from 63 to 2048
with no effect) We're running TSM 5.1.1.4 server and TSM 4.2.3 netware
client.   Any
ideas?  Please email me direct if you have any suggestions or need more
information.  Thanks.

DSM.OPT settings

** TSM TWEAKS **
COMPRESSION NO
LARGECOMMBUFFERS YES
MEMORYEFFICIENTBACKUP NO
PROCESSOR 20
RESOURCEUTILIZATION 10

TXNB 2097152

TCPB 32
TCPNodelay YES
TCPWindowsize 64
** TSM TWEAKS **

managedservices schedule webclient
schedmode prompted

-Vin
vyam AT qbct DOT com