ADSM-L

Re: Is there a limit on the amount of data an NT client can backup ?

2003-01-10 10:15:12
Subject: Re: Is there a limit on the amount of data an NT client can backup ?
From: Keith Kwiatek <kkwiatek AT NIST DOT GOV>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 10 Jan 2003 10:12:50 -0500
Thanks Geof,

We bumped up the sessions to 5 with no luck.....  I guess we can try 10!

Keith


----- Original Message -----
From: "Gill, Geoffrey L." <GEOFFREY.L.GILL AT saic DOT com>
To: <kkwiatek AT NIST DOT GOV>
Sent: Friday, January 10, 2003 10:03 AM
Subject: RE: Is there a limit on the amount of data an NT client can backup ?


> Keith,
>
> I have a single server that is in a similar situation, only Win2K. It's SAN
> attached and has almost 1TB of data on it now. It takes 12-16 hours for this
> thing to complete it's backup, and that's using 10 sessions and Journaling.
> Even with no changes to the filesystem it still has to look at all those
> files. Journaling, I thought, was supposed to speed this up since it keeps a
> local db. So far I don't see much of a change, and from what I can tell last
> night's backup never completed. It's been a real pain to say the least. Can
> your server handle more sessions?
>
> Here is a copy of the sched log on this node. Took over 15 hours to check
> out 4+ million files and send 2.5GB.
>
> 01/09/2003 10:04:48 Total number of objects inspected: 4,387,224
> 01/09/2003 10:04:48 Total number of objects backed up:   22,011
> 01/09/2003 10:04:48 Total number of objects updated:          0
> 01/09/2003 10:04:48 Total number of objects rebound:          0
> 01/09/2003 10:04:48 Total number of objects deleted:          0
> 01/09/2003 10:04:48 Total number of objects expired:         44
> 01/09/2003 10:04:48 Total number of objects failed:           0
> 01/09/2003 10:04:48 Total number of bytes transferred: 2.54 GB
> 01/09/2003 10:04:48 Data transfer time:                  176.73 sec
> 01/09/2003 10:04:48 Network data transfer rate:        15,118.04 KB/sec
> 01/09/2003 10:04:48 Aggregate data transfer rate:         48.56 KB/sec
> 01/09/2003 10:04:48 Objects compressed by:                    0%
> 01/09/2003 10:04:48 Elapsed processing time:           15:16:55
>
> Good luck
>
> Geoff Gill
> TSM Administrator
> NT Systems Support Engineer
> SAIC
> E-Mail:   gillg AT saic DOT com
> Phone:  (858) 826-4062
> Pager:   (877) 905-7154
>
>
>
> > -----Original Message-----
> > From: Keith Kwiatek [mailto:kkwiatek AT NIST DOT GOV]
> > Sent: Friday, January 10, 2003 6:46 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Is there a limit on the amount of data an NT
> > client can backup ?
> > Importance: High
> >
> >
> > Hello IBM,
> >
> > We have an sgi client with about 3 filesystems of about 500
> > gig each, and zillions of files. Can't get them to back up.
> > Same situation, scheduler drifts away. No error messages.
> >
> > We are thinking that the scheduler building of the index
> > blows a gasket somewhere, and that maybe using the virtual
> > filespace option would break it up into smaller more
> > manageable indexes? Any thoughts?
> >
> > Keith Kwiatek
> > National Institute of Standards and Technology
> >
> >
> > ----- Original Message -----
> > From: "Andrew Raibeck" <storman AT US.IBM DOT COM>
> > To: <ADSM-L AT VM.MARIST DOT EDU>
> > Sent: Friday, January 10, 2003 7:07 AM
> > Subject: Re: Is there a limit on the amount of data an NT
> > client can backup ?
> >
> >
> > > There are not known limitations on the amount of data to be
> > backed up
> > > that would contribute to a hang. Network problems are one fairly
> > > common cause of hangs, though I would think you would
> > eventually get
> > > some kind of network error. You might consider upgrading to
> > the latest
> > > TSM client patch level (5.1.5.7) to see if the problem may
> > have been
> > > addressed via a bug fix. Beyond that, if the problem
> > persists, I would
> > > recommend that you contact IBM support for assistance.
> > >
> > > Regards,
> > >
> > > Andy
> > >
> > > Andy Raibeck
> > > IBM Software Group
> > > Tivoli Storage Manager Client Development
> > > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet
> > > e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
> > >
> > > The only dumb question is the one that goes unasked.
> > > The command line is your friend.
> > > "Good enough" is the enemy of excellence.
> > >
> > >
> > >
> > >
> > > Nick Rutherford <Nick.Rutherford AT HONDA-EU DOT COM>
> > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > 01/10/2003
> > > 03:15 Please respond to "ADSM: Dist Stor Manager"
> > >
> > >
> > >         To:     ADSM-L AT VM.MARIST DOT EDU
> > >         cc:
> > >         Subject:        Is there a limit on the amount of
> > data an NT client can backup ?
> > >
> > >
> > >
> > > Hello all,
> > >
> > > we have a TSM client installed on an NT server that has
> > about 250gb of
> > > IBM ESS storage attached to it.
> > > Recently we have experienced problems with the scheduler
> > service which
> > > appears
> > > to hang during the backup.
> > > The client schedule and error logs do not contain any information.
> > >
> > > The TSM server is V5.1.1.0
> > > The TSM client level is V5.1.1.0
> > >
> > > The NT server is V4 SP6.
> > > The NT server also runs Notes V5.
> > >
> > > Has anybody seen similar problems when backing up such a
> > large volume
> > > of data ? Any help is appreciated.
> > >
> > > regards,
> > >
> > > Nick Rutherford.
> > >
> > >
> > >
> > *********************************************************************
> > > This e-mail is confidential and intended solely for the use of the
> > > individual to whom it is addressed.  Any views or opinions
> > presented
> > > are solely those of the author and do not necessarily
> > represent those
> > > of Honda of the UK Manufacturing Ltd.
> > >
> > > If you are not the intended recipient please notify the sender
> > > immediately by return e-mail and then delete this message from your
> > > system.  Also be advised that any use, disclosure, forwarding,
> > > printing or copying of this e-mail if sent in error is strictly
> > > prohibited.  Thank you for your co-operation.
> > >
> > *********************************************************************
> >