> 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: [EMAIL PROTECTED] > [mailto:veritas-bu-> [EMAIL PROTECTED] On Behalf Of bob944 > Sent: Wednesday, April 30, 2008 9:03 PM > To: veritas-bu@mailman.eng.auburn.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@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu