Re: Best Backup Blocksize for 110SDLT Tape?

From: John Santos (JOHN_at_egh.com)
Date: 03/05/04 

Date: Thu, 4 Mar 2004 21:37:11 -0500

On 4 Mar 2004, Daryl Jones wrote:

> Dear John Santos:
>
> The issue is not that it may pertain to 9 track tapes only. The issue
> raised was that is or was a problem with tape backup and restores
> using block size greater than 32256 and nobody had a solution or
> understanding of the problem. That by itself is worry some.

No one else has ever experienced or heard of any such problem, AFAIK.

I certainly haven't, and I've been doing VMS backups (and restores)
since VMS backup was released (V3.0?)

The *only* problem with blocksize > 32256 is the documented restriction
that the resulting ANSI tape files can't be copied to disk. Restore
from tape has *always* (AFAICR) worked fine.

>
> What you are sugggesting is the problem doesn't exist because of the
> hardware performance is much better. On small sites where multiple
> savesets can be stored on one tape. I'll buy in to it. However, what
> about multi-volume savesets with a large block size? I don't know many
> System Managers or DBAs using VMS and Backup that had to rebuild their
> site from tape except for maybe the WTC? Maybe the problem isn't or
> wasn't cause by Multi-volume saveset?

Are you claiming that multi-volume tape savesets with blocksizes
larger than 32256 won't restore? I've never had any problems.

>
> Regards,
> Daryl Jones
>
>
>
> John Santos <JOHN@egh.com> wrote in message news:<1040303234647.15727A-100000@Ives.egh.com>...
> > On Thu, 4 Mar 2004, Tom Simpson wrote:
> >
> > > One factor (especially with older tape drives and lower bit densities) that
> > > could be a problem is the physical length of tape it takes to write a large
> > > block of data. Last time I checked, the standard distance from the EOT
> > > marker to the physical end-of-tape is roughly 15-20 feet. If 20 feet is not
> > > enough space to fit a data block, then the backup could fail. The typical
> > > symptom would be the tape runs off the end of the reel (on 9 track tapes for
> > > example).
> > >
> > > The way a tape drive works (at least the way they used to work...I'm going
> > > way back here...) is that they attempt to finish writing the block they are
> > > currently on, even if it is past the EOT marker. If there is not enough
> > > physical tape left to complete the block, the party's over.
> > >
> > > With the MUCH higher bit densities of today's tape drives, I think the
> > > likelihood of that happening is very small, if it could happen at all...
> > > This is, of course, speculation on my part triggered by first-hand (and
> > > out-of-date) tape drive technology knowledge... Even at 6250BPI, a 64K
> > > block of data would take a lot of tape to write.
> > > That would be roughly ((64000blocks * 512 bytes per block) / 6250 bpi) / 12
> > > = 436 ft. ??
> >
> > A 64K block contains 64000 (or 65536 bytes, if "K" means 1024). You
> > are multiplying by 512 unnecessarily. So on a 6250bpi tape, this is
> > 10.24 inches. Should easily fit before the physical end-of-tape.
> > (It also requires a tape mark, some EOV labels, and a couple more
> > tape marks. IIRC, 9-track tape marks are 1/2 inch, irrespective of
> > density.)
> >
> > At 800bpi, the record is 80 inches, (6'8"), so this is getting really
> > iffy.
> >
> > In either case, if there is a bad spot on the tape, the drive will
> > space forward looking for good tape and with records this long, you
> > could be in "reel" trouble :-) Everyone should have the fun of
> > reloading a 9-track tape from the end by hand, at some time in their
> > life!
> >
> > But this thread was about SDLT, not 9-track, and 32256 is only
> > relevent to disk save-sets, not tape save-sets, so we're really
> > getting off-track here.
> >
> >
> > >
> > > Regards,
> > > Tom
> > >
> > > "Daryl Jones" <jones.computer.srv@worldnet.att.net> wrote in message
> > > news:8a646952.0403022253.69a3161@posting.google.com...
> > > > Dear David J. Dachtera:
> > > >
> > > > I have been told by more than a couple System Manager that the maximum
> > > > backup block size should be the same as the default backup blocksize
> > > > when you are backing up from disk to disk which is 32256. Any block
> > > > size other greater than 32256 will cause the backup restore to fail.
> > > > Thus makeing the backup useless. This isn't theory because those
> > > > System Managers actually tested the backup and restores with different
> > > > blocksize for proof.
> > > >
> > > > Could you further explain to me or provide a reference on your
> > > > recommendation that you have provided.
> > > >
> > > > Thanks,
> > > > Daryl Jones
> > > >
> > > >
> > > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in
> > message news:<40453492.27B758CE@NeOaSrPtAhMlNiOnWk.net>...
> > > > > Hal Kuff wrote:
> > > > > >
> > > > > > In search of best blocksize for SDLT tape at 110GB.... using
> > MSL5026
> > > > > > tape library over 1gb Fibre Channel to OpenVMS ES40 type systems on
> > 1gb
> > > > > > Fibre Channel...... Have not seen the 50-60% improvement in
> > performance we
> > > > > > expected over DLT8000/DLTIV Tape....
> > > > > >
> > > > > > Can anyone reccomend an init, mount, and backup command that works
> > for
> > > > > > your site...
> > > > >
> > > > > Before you go digging that deep, check that your NSRs are configured
> > > > > correctly. Make sure that the SCSI cards are in the high-numbered slots,
> > > > > not the low. That will approximately double your throughput if they were
> > > > > wrong before.
> > > > >
> > > > > Otherwise, the usual rules still apply: us ethe largest blocksize you
> > > > > can live with: 65024 if you don't need to read the savesets with RMS,
> > > > > less than 32767 if you do.
> > >
> > >
> > >
> > >
>
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

Relevant Pages

  • Re: Best Backup Blocksize for 110SDLT Tape?
    ... >> raised was that is or was a problem with tape backup and restores ... and I've been doing VMS backups (and restores) ... > that the resulting ANSI tape files can't be copied to disk. ... In that case you should also check that your network setup can ...
    (comp.os.vms)
  • Re: SBS Backup/Restore- Best Practice
    ... tapes but I'm not able to fit the whole server on the tape. ... That's way too small a tape medium. ... Do practice restores periodically. ... you have identcal, spare hardware, you won't be able to restore your SBS ...
    (microsoft.public.windows.server.sbs)
  • =?iso-8859-1?Q?problems_with_multi_volume,_restore_using_FDR?=
    ... And all the restores were running very ... Until we ran into a tape that was multi-volume. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: Mailbox Restore Policy
    ... As you know, restoring e-mail data from tape is very time consuming, it is ... These restores also require a lot of available ... Users will need to use recover deleted items if they lose a message. ...
    (microsoft.public.exchange.admin)
  • Re: (mirroring &) ZFS: 9=no-ZFS; 10=yes?; 11=open=ZFS (improved)?
    ... restores in that case? ... With 'ufsrestore -i', tagging the files or directories you need. ... a lot of tape to get what you want, but you don't need enough spare ... ufsrestore (and presumably also ufsdump) directly access the tape. ...
    (comp.unix.solaris)