[Veritas-bu] SDLT restore problem

> Subject: RE: [Veritas-bu] SDLT restore problem
> 
> 
> Ken,
> 
> I think you just found your problem.  Specifically the 
> SIZE_DATA_BUFFERS
> parameter.  That parameter is the block size that the tape 
> drive uses to
> write with.  If you changed this at any time and continued to 
> use the same
> tape (if you did not change the retention) then you will not 
> be able to read
> any data on that tape prior to the change.
> 
> Try going back to the previous value(s) used for the SIZE_DATA_BUFFERS
> parameter and eventually you will be able to read the data.
> 
> If you cannot read the data you just wrote, forget what I said...
>

I hope this is not the case.  We have backups that have 5-7 year
retention periods for legal reasons.  It would not be fair to
expect that we will never upgrade our equipment and want to be
able to tune the system for better performance making use of this
new and faster equipment.  Hey what about these people that are
switching master/media servers?

It would make more since to read the size when reading the data
back off the tape and therefore be able to sync with any prior
values.

However, I should be able to test this by using a new tape and
writing with the current settings.  Then try to restore from
this tape.  If what you say is true then I should be able to
complete this restore.  Right?

Ken
 
> 
> Bill Wiessner
> VERITAS Software
> Staff Systems Engineer
> DoD/Intelligence
> Office:  410-877-7689 
> Cell:     410-804-3321 
> 
>  -----Original Message-----
> From:         SIBLEY, Ken R. - ACCOREL 
> [mailto:sibley_ken AT accorel DOT com] 
> Sent: Wednesday, January 23, 2002 1:17 AM
> To:   'NetBackup List'
> Subject:      RE: [Veritas-bu] SDLT restore problem
> 
> 
> 
> > -----Original Message-----
> > From: BAHNMILLER,BRYAN (A-ColSprings,ex1)
> > [mailto:bryan_bahnmiller AT agilent DOT com]
> > Sent: Tuesday, January 22, 2002 5:39 PM
> > To: SIBLEY, Ken R. - ACCOREL
> > Subject: RE: [Veritas-bu] SDLT restore problem
> > 
> > 
> > Ken,
> > 
> >   Have you tuned NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS? 
> > 
> >   When we started working with LTO drives we followed our 
> SE's tuning
> > process. This was basically increase the size and number 
> > until backups fail,
> > then try restoring. Back the sizes and number down until 
> > restores work.
> > 
> >   And it seems tuning for optimal performance will be 
> > different for every
> > OS. We are running HP/UX and NT here. The tuning between 
> > HP/UX and NT are
> > way different. I'm pretty sure it will differ between 
> HP/UX, Solaris,
> > AIX,,,,.
> >
> 
> I have tuned the size and number a little.  We have increased
> them some, but had to back them off a little.  The master/media
> server (Sun E450) has 4GB RAM and we run so many jobs via 
> 10 DLT7000 drives in 2 libraries (SDLT library to replace 1)
> that we started running out of memory and had to back them
> down some.  If we drop the parameters more then we are going
> to definately be in trouble for performance.
> 
> Since I have already installed SSO I might try working on
> the restore from the SAN media server where I can tune the
> parameters seperate from the normal jobs on the master.
> Didn't I read in another message that you can tune these
> differently on each media server?
> 
> Thanks,
> Ken
> 
> 
> Ken Sibley
> Sr. Unix Administrator
> Accor Economy Lodging
> ksibley AT accorel DOT com
> 469-737-3370
>  
> >   Just a thought.
> > 
> >     Bryan
> > 
> > Bryan Bahnmiller
> > Enterprise Hosting 
> > Storage Engineer  - development team
> > IT | Information Technology
> > 
> > Agilent Technologies, Inc.
> > 1900 Garden of the Gods Road, M/S C103G
> > Colorado Springs, CO 80907
> > 
> > (719) 590-3262 Tele
> > www.agilent.com
> > 
> > 
> > > -----Original Message-----
> > > From: SIBLEY, Ken R. - ACCOREL [mailto:sibley_ken AT accorel DOT com]
> > > Sent: Tuesday, January 22, 2002 4:02 PM
> > > To: 'veritas-bu AT mailman.eng.auburn DOT edu'
> > > Subject: RE: [Veritas-bu] SDLT restore problem
> > > 
> > > 
> > > This is an section of the restore progress log for a test
> > > that was performed today.  All of our other tests were with
> > > multiplexed backups and restore while this test was with
> > > multiplexing turned to 1.
> > > 
> > > As you can see below the error is a media read error.
> > > We have tried different clients and backups from different
> > > days so a tape error is pretty unlikely.  I am not sure
> > > how to check that the label is "exactly" the same on both
> > > lines of the st.conf other than visually with vi.  sgscan
> > > only shows the label for the drives "QUANTUM SuperDLT1".
> > > 
> > > 10:52:13 (81536.xxx) Restore job id 81536 will require 1 image.
> > > 10:52:13 (81536.xxx) Media id SD0234 is needed for the restore.
> > > 
> > > 10:52:17 (81536.001) Restoring from image created Tue Jan 22 
> > > 10:35:27 2002
> > > 10:52:19 (81536.001) INF - Waiting for mount of media id 
> > > SD0234 on server
> > > udal003app.
> > > 10:53:16 (81536.001) INF - Waiting for positioning of media 
> > > id SD0234 on
> > > server udal003app.
> > > 10:53:32 (81536.001) INF - Beginning restore from server 
> > udal003app to
> > > client u23tst1.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/ was not restored.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/addpr.ksh was not 
> > > restored.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/addusr.ksh was 
> > > not restored.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/delpr.ksh was not 
> > > restored.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/delusr.ksh was 
> > > not restored.
> > > 11:08:36 (81536.001) /usr/local/admin/opdir/menu.ksh was 
> > not restored.
> > > 11:08:37 (81536.001) /usr/local/admin/opdir/altwrap.exe was 
> > > not restored.
> > > 11:08:39 (81536.001) Status of restore from image created 
> Tue Jan 22
> > > 10:35:27 2002 = media read error
> > > 
> > > 11:08:40 (81536.xxx) INF - Status = the restore failed to 
> > recover the
> > > requested files.
> > > 
> > > 
> > > 
> > > Ken Sibley
> > > Sr. Unix Administrator
> > > Accor Economy Lodging
> > > ksibley AT accorel DOT com
> > > 469-737-3370
> > > 
> > > > -----Original Message-----
> > > > From: Larry Kingery [mailto:larry.kingery AT veritas DOT com]
> > > > Sent: Tuesday, January 22, 2002 4:34 PM
> > > > To: SIBLEY, Ken R. - ACCOREL
> > > > Subject: RE: [Veritas-bu] SDLT restore problem
> > > > 
> > > > 
> > > > Looks like the variable mode is set correctly, which is 
> what I was
> > > > concerned about.  Now the question is if the st.conf 
> > entry is being
> > > > recognized correctly.
> > > > 
> > > > Earlier in the file, there's a line which ends in 
> "SDLT220".  The
> > > > first string in in this line must match EXACTLY with what 
> > the drive
> > > > returns.  If it does, the second entry should show up 
> > when you do an
> > > > mt status on a loaded drive.
> > > > 
> > > > That's the error you're receiving?  
> > > > 
> > > > SIBLEY, Ken R. - ACCOREL writes:
> > > > > The platform is Sun, Solaris 2.6
> > > > > w/ NBU 3.4.1.  I believe the st.conf
> > > > > entry is correct.
> > > > > 
> > > > > SDLT220 =       1,0x38,0,0x29639,4,0x90,0x91,0x90,0x91,3;
> > > > >                               
> > > > > The 2 in 0x29639 is because we are also implementing
> > > > > SSO for this library which has been installed, but
> > > > > waiting for restore testing before implementation.
> > > > > 
> > > > > We are backing up and restoring a Solaris 2.6 client
> > > > > accross the network for this test, but we also have
> > > > > HP-UX, Linux and NT clients as well.
> > > > > 
> > > > > Ken
> > > > > 
> > > > > Ken Sibley
> > > > > Sr. Unix Administrator
> > > > > Accor Economy Lodging
> > > > > ksibley AT accorel DOT com
> > > > > 469-737-3370
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Larry Kingery [mailto:larry.kingery AT veritas DOT com]
> > > > > > Sent: Tuesday, January 22, 2002 3:51 PM
> > > > > > To: SIBLEY, Ken R. - ACCOREL
> > > > > > Subject: Re: [Veritas-bu] SDLT restore problem
> > > > > > 
> > > > > > 
> > > > > > What platform?
> > > > > > 
> > > > > > If Sun, do you have the proper st.conf configured?
> > > > > > 
> > > > > > SIBLEY, Ken R. - ACCOREL writes:
> > > > > > > We have installed a STK L180 tape library with
> > > > > > > 4 SDLT drives.  We finally have the drives writing
> > > > > > > to tape with a minimum of problems.  Unfortunately
> > > > > > > now we are trying to run test restores, both
> > > > > > > filesystem and Informix DB's.  Neither work.
> > > > > > > Has anyone had a problem with restores and resolved
> > > > > > > them?  We are working with Veritas, but no 
> > > > > > > results so far so I was hoping someone here could
> > > > > > > help.  This is our last step before putting the
> > > > > > > unit into production.
> > > > > > > 
> > > > > > > Ken Sibley
> > > > > > > Sr. Unix Administrator
> > > > > > > Accor Economy Lodging
> > > > > > > ksibley AT accorel DOT com
> > > > > > > 469-737-3370
> > > > > > > _______________________________________________
> > > > > > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > > > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > > > > > 
> > > > > > -- 
> > > > > > Larry Kingery 
> > > > > >       ...from the home office in Grand Rapids, Michigan
> > > > > > 
> > > > > _______________________________________________
> > > > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > > > 
> > > > -- 
> > > > Larry Kingery 
> > > >                      Of couse, I could be wrong.
> > > > 
> > > _______________________________________________
> > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > > 
> > 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>