FLB is used to get to the first file you are restoring. It is NOT used
once you start reading that file. The rest of the restore will read
EVERYTHING and throw away the blocks it doesn't need.
While this may not affect the performance of a single file, it will
absolutely affect the potential performance of a large restore.
Multiplexing with VTLs usually hurt less, because usually the resulting
slower speed is still faster than what the client can write at.
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-
> bounces AT mailman.eng.auburn DOT edu] On Behalf Of bob944
> Sent: Thursday, May 01, 2008 12:10 AM
> To: 'Len Boyle'; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Multiplexing on VTL's
>
> > I agree with b and c, but there a can be a little misleading
> > as we learned the hard way this past year.
> > Netbackup records the start of a fragment and not the
> > location of the file on the tape. So it has to read the whole
> > fragment until it finds the file it is looking for.
>
> Sounds as if you had a loooong restore experience, Len. As mentioned,
I
> haven't empirically tested whether F-L-B is used in restoring part of
a
> multiplex set (if it's used in individual-file restore, you'd think it
> would apply to finding the files of one backup in a mux set), but the
> location of every file on the tape definitely is recorded--the block
> numbers are field #5 in the output below:
>
> # /usr/openv/netbackup/bin/cat_convert -dump *443_INCR.f
> num len plen dlen blknum ii raw_sz GB
dev_num
> path
> data
> 0 0 1 50 0 0 0 0
8388728
> /
> 16877 root root 0 1209535204 1209430138 1209430138
> 1 0 5 49 1 1 0 0
8388731
> /usr/
> 16877 root sys 0 1209535162 1208501866 1208501866
> [...]
> 18826 107 41 53 2286045 2 0 0
8388731
> /usr/openv/netbackup/bin/private/nblogcfg
> 33088 root bin 54048 1208506181 1195233073 1209450948
> 18827 80 41 53 2286152 2 0 0
8388731
> /usr/openv/netbackup/bin/private/nbloggen
> 33088 root bin 40024 1208506181 1195233073 1209450948
> 18828 73 41 53 2286232 2 0 0
8388731
> /usr/openv/netbackup/bin/private/nblogmgr
> 33088 root bin 36564 1208506181 1195233074 1209450948
> 18829 111 42 53 2286305 2 0 0
8388731
> /usr/openv/netbackup/bin/private/nblogview
> 33133 root bin 56304 1208506181 1195233074 1209450948
>
>
> > -----Original Message-----
> > From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> > [mailto:veritas-bu-> bounces AT mailman.eng.auburn DOT edu] On Behalf Of
> bob944
> > Sent: Wednesday, April 30, 2008 9:03 PM
> > To: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: Re: [Veritas-bu] Multiplexing on VTL's
> >
> >
> > > My main concern is that when doing restores off a multiplexed
> > > tape, the VTL READ speed off the disk(let's say it's 80MB/s)
> > > is the same whether there's MPX in the stream or not. The
> > > restore will throw away the bytes that doesn't belong to the
> > > client, so out of a 80 MB/s stream coming off the disk, you
> > > will throw away (let's say) 60MB and use only 20. It's this
> > > reduction in effective restore speed that's my main concern.
> >
> > Perhaps you'll have time to test and share here? I'd expect
NetBackup
> > to treat it as multiplexed tape and not read the intervening
> > data. IME,
> > most multiplexed-tape-restore horror stories are no longer
> > valid due to
> > a) fast-locate-block's ability to skip the intervening data (I have
> > never explicitly tested this), b) drives that supply data faster
than
> > the client can write it and c) properly designed multiplexed
> > backups can
> > restore multiple clients significantly faster than non-muxed (I have
> > tested b and c).
> >
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
