If you are using the mode=ifincr parameter, it might be the same problem we had
a while ago.
We started using ifincr as soon as it was added, but found our restores were
horribly slow if we did not perform a periodic full backup. We added in a
weekly mode=iffull backup which addressed our pro
Hello Marcel,
thank you very much. I will test it.
Marcel Anthonijsz
Gesendet von: "ADSM: Dist Stor Manager"
26.04.2014 11:37
Bitte antworten an "ADSM: Dist Stor Manager"
An: ADSM-L@VM.MARIST.EDU
Kopie:
Thema: Re: slow restore performan
Stefan,
Make sure your VMCTL data is on a diskpool. TSM needs the metadata for
backups and restores.
Next, I have found after extensive testing (and a PMR with IBM) that the
transport method NBD is much quiker than hotadd for restore.
If you have a physical data mover, you can use SAN as transport
question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" wrote on 03/13/2009
10:18:27 AM:
> [image removed]
>
> Re: slow restore
>
> Rainer Wolf
>
> to:
>
> ADSM-L
>
thanks - one question I have on that flash:
We have several win2000 Clients stil running with 5.3.6.4
and some WinNT Systems running possibly 5.1.8.2.
Reading this flash I interpret those clients not affected by that problem
-- aren't they ?
If not -- those win2000 and NT Klients are affected but
> okay - you could change the COMPRESSALWAYS to 'NO', the default is at
'YES'
> Otherwise already compressed files normally grow with the tsm compression
> and so 'COMPRESSALWAYS NO' can disable compression for those files.
Using EXCLUDE.COMPRESSION is better performance-wise for known file
specif
ssed
Rick
Rainer Wolf
To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor cc
Manager"
Re: slow
Rainer Wolf
To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor cc
Manager"
Re: slow res
Rainer Wolf
To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor cc
Manager"
Re: slow res
How many inactive versions exist??? (what are your retention characteristics
and how frequently do the files change)
Also, what is the total number of files stored for that file system???
If you have 7 million files in that file system, that can have ugly
results...
Also, do you have any looping li
Hi,
you may try instead
dsmc restore "/oracle/backup/fedwp1/bkup.hpdw1p.200903081920.fedwp1.hot/?*"
/oracle/backup/paul/ -inactive -subdir=yes -replace=no
This would deactivate the nqr -feature and we use it often when restoreing
quite small
number of files out of bigger file-spaces.
regards
R
Thank you Andy.
That looks like the same problem we are having. Time for an upgrade.
Larry
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Raibeck
Sent: Thursday, October 11, 2007 10:25 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Slow restore
Have a look at APAR IC49469 (follow the link in my sig and enter the APAR
number); this might be the problem you are seeing.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTE
Sona,
The TDPs do not support backup sets.
In fact, any application that uses the TSM API
(like the TDPs) does not support backup sets.
The only way you can restore a backup that was
taken with TDP for SQL, is with TDP for SQL.
You can not restore it using the BA client interface.
If you took th
Hi,
> We lost a server volume over the weekend - Netware 5.1 server
> - 20 GB or so
> to restore from tape. The process is going extremely slowly;
> it seems that
> most of the time is being spent retrieving tapes, and we have
> only 3.5 GB
> restored so far (started late yesterday afternoon).
D
Is your storage pool you are restoring from collocated? Do you have an automated tape
library or manual tape drives?
-Original Message-
From: Nancy Ames [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 3:25 PM
To: [EMAIL PROTECTED]
Subject: Slow restore of entire server volume
W
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Nancy Ames
> We lost a server volume over the weekend - Netware 5.1 server -
> 20 GB or so
> to restore from tape. The process is going extremely slowly; it seems that
> most of the time is being spent retrieving tapes, and we ha
lto:[EMAIL PROTECTED]>
Office: + 27 21 7629702<http://www.faritec.co.za/>
-Original Message-
From: Richard Sims [mailto:[EMAIL PROTECTED]]
Sent: 16 July 2001 03:11
To: [EMAIL PROTECTED]
Subject: Re: Slow restore times when using GUI (X windows) interface on
Solari s.
>
>When using the X windows interface to restore data on a solaris system
>(version 2.8) We get very slow restore times approximately 100KB/S however
>when using the command line interface (DSMC) we get restore speeds in excess
>of 5MB/s. Can anyone tell us of there are any problems with the DSM X
n2K!
Regards,
Don
-Original Message-
From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 20, 2000 2:38 PM
To: [EMAIL PROTECTED]
Subject:Re: Slow restore for large NT client outcome.. appeal to
Tivoli
Could someone with experience doing large restores w
-
From: France, Don G (Pace)
Sent: Friday, May 04, 2001 9:50 PM
To: [EMAIL PROTECTED]
Subject:RE: Slow restore for large NT client outcome.. appeal to
Tivoli
I have two fundamental suggestions, I have not seen item 2 mentioned yet:
1. Use Microsoft folder-copy (be sure to run
Hee Hee. Out of the frying pan...
So much for that idea!
> -Original Message-
> From: Jeff Connor [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 22, 2000 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Slow restore for large NT client outcome.. appea
PROTECTED]
www.storsol.com
www.storserver.com
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Jeff Connor
Sent: Friday, September 22, 2000 11:51 AM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
D evelopment/Suppor
ST.EDU> on
09/22/2000 01:07:46 PM
Please respond to "ADSM: Dist Stor Manager"
<[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Slow restore for large NT client outcome.. appeal
e AIX client has to get past
that issue?
Signed,
Yes I know there's a problem but I'm as confused as everyone else
> -Original Message-
> From: Joshua S. Bassi [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, September 20, 2000 6:56 PM
> To: [EMAIL PROTECTED]
>
is connected to the LAN via
Gigabit NIC,
George Yang <[EMAIL PROTECTED]> on 09/21/2000 10:37:32 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: Blair Wickstrand/Poco)
Fax to:
Subject: Re: Slow restore for
t extent.
I live with it. Sadly, but I do.
Mike
> -Original Message-
> From: Purdon, James [SMTP:[EMAIL PROTECTED]]
> Sent: ä ñôèîáø 21 2000 15:55
> To: [EMAIL PROTECTED]
> Subject: Re: Slow restore for large NT client outcome.. appeal to
> Tivoli
>
> When r
So I'd heard, but I don't have the liberty of choice, so I'm stuck with it
on the AS system.
Mike
> -Original Message-
> From: Joshua S. Bassi [SMTP:[EMAIL PROTECTED]]
> Sent: ä ñôèîáø 21 2000 17:33
> To: [EMAIL PROTECTED]
> Subject: Re: Slow resto
[mailto:[EMAIL PROTECTED]]On Behalf Of
Kronstadt, Dan
Sent: Wednesday, September 20, 2000 6:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome
I think we need the answers to Kelly Lipp's question - how fast is Arcserve
really? But IF it is better, then I dont thi
As the person who started this thread I'd like to thank everyone
for their excellent feedback.
I'd also like to hear, as Kelly and a few others requested, about
and TSM'ers like Blair that also use other products or formally
used another product for backing up/restoring Windows NT clients.
It wou
With the new copper chips the AS/400s can hit and
sustain 4000MIPS.
Edward(Ed) J. Finnell, III
Enterprise Systems/Proj. Mgr.
url:www.ua.edu
Jeff,
I'd begin by looking at your Raid array definition. I've found that when you use
more then 4 drives in a single array the performance goes in toilet.
if you can test it try runninthe same restore to a raid 0 configuration.
-
Do You Yahoo!?
Send instan
My experience here has been that Backups fly, Restores snore.
My best rate for a restore of files of mixed length, mainly
small, has been 1.5 GB /hr from tape. (We are using IBM
3590B drives, soon to become 3590E.)
In a test, a restore from the disk pool brought
me way up to 1.66 GB/ hour. Yee ha!
Blair,
We can restore 13GB in one hour for a fairly medium amount of medium size
file by using TSM. But not for a large amount of small files. Can you do
17GB/hr or what ever for a small file systems with ARCserver? What is your
wire--LAN or SCSI?
George
serve.
Blair
Mike Glassman - Admin <[EMAIL PROTECTED]> on 09/21/2000 12:57:47 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: Blair Wickstrand/Poco)
Fax to:
Subject: Re: Slow restore for large NT client outcome.. ap
Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Mike Glassman - Admin
Sent: Wednesday, September 20, 2000 11:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
Kelly,
I don't know regarding Arcserve as you couldn't pay me to go near it, b
day, September 21, 2000 2:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Slow restore for large NT client outcome.. appeal to
> Tivoli
>
> Kelly,
>
> I don't know regarding Arcserve as you couldn't pay me to go near it, but
> BE
> I do know.
>
> Re
From: Matthew Glanville
I have found that many times I overlook a very significant item that is
really the cause of the slow restore/backup on NT.
Make sure that there is NO Virus scanning software running
I have been hit at least 5 times by the NT admin complaining about a slow
backup/rest
>That may be because from what I have seen in TSM 3.7, directories are
>actually kept in the TSM database and not on tape.
Careful, there. It depends upon the file system type and added baggage.
Ordinary Unix file system directory information is like an empty file, and
so its limited info can be
containing several million files, surely some must be more important
than others...
Jim
> --
> From: Mark Bryant[SMTP:[EMAIL PROTECTED]]
> Reply To: ADSM: Dist Stor Manager
> Sent: Thursday, September 21, 2000 7:19 AM
> To: [EMAIL PROTECTED]
> Subj
>My view on the slow restore problem is that it is down to the tape
>technology. ...
Mark - Thanks for that corroboration. Too many customers implement technology
on the basis of popularity, without critical consideration of what it
really does, what its weaknesses are, or how well its c
My view on the slow restore problem is that it is down to the tape
technology. I've done quite a bit of testing with restores on AIX, NetWare
and NT and can say the following:
1. I can rule out the network and server performance as the bottle neck.
Doing a full backup and restore will give compar
PROTECTED]]
> Sent: ã ñôèîáø 20 2000 23:38
> To: [EMAIL PROTECTED]
> Subject: Re: Slow restore for large NT client outcome.. appeal to
> Tivoli
>
> Could someone with experience doing large restores with ArcServe or
> BackupExec provide some performance numbers? I've
: Wednesday, September 20, 2000 12:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome
Jeff - I more than sympathize with your predicament as a storage
administrator dealing with NT systems and their administrators.
But be careful about going after a vendor to fix
2:38 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
Could someone with experience doing large restores with ArcServe or
BackupExec provide some performance numbers? I've been in shops where the
backups were taking a very long time. Longer tha
[mailto:[EMAIL PROTECTED]]On Behalf Of
Arturo Lopez
Sent: Wednesday, September 20, 2000 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
D evelopment/Support
Jeff,
I have the same concerns. My company is in the process of server
consolidation.
[mailto:[EMAIL PROTECTED]]On Behalf Of
Greazel, Alex
Sent: Wednesday, September 20, 2000 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
Development/Support
Can TSM do an image backup on NT? (If it can)That will dramatically
decrease
the
ECTED]
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Farris, Raeana
Sent: Wednesday, September 20, 2000 11:19 AM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
D evelopment/Support
Just a thought - T
Jeff,
I have the same concerns. My company is in the process of server
consolidation. I have concerns that when the time comes to consolidate
these servers into cluster servers I (TSM) will not be able to restore 1.2
TB of data to a cluster server in a timely manner. I am quickly loosing
the
nesday, September 20, 2000 12:03 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo
Jeff, we too have a problem with small files. At first I thought it was a
Netware thing because the servers we have the greatest amount of files on
reside
on the
Jeff, we too have a problem with small files. At first I thought it was a
Netware thing because the servers we have the greatest amount of files on reside
on the Netware servers.
But reading emails from several users I see that I may have a future problem on
the NT side. We store Word and WordPerf
Jeff - I more than sympathize with your predicament as a storage
administrator dealing with NT systems and their administrators.
But be careful about going after a vendor to fix a problem you perceive
to be with their product without first establishing baseline values for
your configuration
How so??
George
We have same problems. It took 6 hrs to restore 220MB with 300,000 small
files without DIRMC, with disk DIRMC it reduce to 3 hrs. However it is
still too slow. I did test for multi-session--multi drive, it dose not
improve much. As long as we use tape, multi session will be limited. Only
thing m
esday, September 20, 2000 10:53 AM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli
Development/Support
Jeff,
One thing to show your NT Admins is just how much overhead NTFS has. The
way I've done this before is to copy a drive, either locally or over t
Just a thought - Take a look at the new TSM Implementation Redbook. They
set up separate storage pools for NT, one for directory info and one for
files. According to the Redbook restoring the directory structure first
allows for faster restore times. I happened to be in a TSM session last
week,
Can TSM do an image backup on NT? (If it can)That will dramatically decrease
the amount of time it takes to do backups/restores for file systems that have
tons of small files.
Jeff,
One thing to show your NT Admins is just how much overhead NTFS has. The
way I've done this before is to copy a drive, either locally or over the
network. If you take one of the drives with a lot of small files, can copy
it, the performance will drop as the copy goes on. The more files y
,
Jeff Connor
Richard Sims <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 09/13/2000 03:34:24
PM
Please respond to "ADSM: Dist Stor Manager"
<[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject
Jeff - Lisa's insightful response made me think of something...
You say you are using 100Mbit Ethernet. A gotcha in that area to
make sure of is that your adapter cards are not set for
Auto Negotiation: it is notorious for not working. Too often,
one ends up with a conflict in duplex settings t
Jeff,
Have you tried pinging with different packet sizes to see what the MSS is set to
on the switches/ atm fabric? How well do ftps perform? How fast does an
nslookup resolve both ways? What does a tracert from the NT client show and
from the os/390 back to the NT client. We've got a weird, co
>When I do a NETSTAT on the TSM Server (3466 with TSM 3.7.2) I get the
>following output.
>
>I wonder what Send-Q means and why the value is that high!
>
>Proto Recv-Q Send-Q Local Address Foreign Address
>tcp4 0 63800 nsm_backbone.ill.1500 node2_backbone.i.3963
The Q(ueue) cou
62 matches
Mail list logo
