Well, this is a lot to respond to. I'll respond where
I can and give you as much info as I possibly can.
First
> their new "feature" Multistreaming which uses MPX!!!
Not true. Multistreaming supports multiple datastreams
from one class (whether MPX'd or not) through the use
of File List Directives. What the Support Engineer was
probably trying to tell you was that if you used
Multistreaming it would 'break up' your backup image
across multiple tape drives giving you increased
aggregate thru-put as well as a level of check-point
restart that wasn't available in previous versions.
EX.
File List would look something like this (i'm not sure
of the Novell syntax, but you'll get my meaning)
NEW_STREAM
SYS:
NEW_STREAM
DATA1:
NEW_STREAM
DATA2:
What this would effectively produce for you (given your
environment 2- DLT7000 drives)is a backup stream going
to drive one, backing up SYS: and backup stream going
to drive two, backing up DATA1:, the last one would
wait in queue until another drive is available. One
thing you will have to configure is the global
configuration parameter for number of backup
jobs/client, the default is one. If this number is
greater than one, then this above example will do just
as I described.
hard to answer you first question, because the
situations will vary.
As far as question 2, its done by importing the tapes,
at least that's the way I've always done it.
Here's a question on your environment.
Do you have any duplication process in place for
disaster recovery and offsite storage?
My point being, this process basically is two-fold, it
dupes the images for you, but it also provides a level
of verification for you as well.
David
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David A. Chapa 847 413 1144 p
Director of Technology 847 413 1168 f
DataStaff, Inc. http://www.datastaff.com
nbu-lserv AT datastaff DOT com majordomo AT datastaff DOT com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quoting "McMurphy, Tim" <Tim.McMurphy AT cdcgy DOT com>:
> I have just encountered a serious problem with
Netbackup that they couldn't
> fix so I thought I would ask about it. I would be
curious to see how other
> backup systems handle this type of problem. If this
is the wrong group to
> post to please forgive me but I can't find any
*.backup groups.
>
> Background:
> We have several Netware, WinNT, Solaris and HPUX
systems backing up to 3
> slaves and one master (total of 4 backups servers).
There are 2 DLT 35/70
> drives attached to each system.
>
> Problem:
> One of our Netware servers' backups didn't register
in the database. When
> we went to do a restore the image was not listed as
one we could choose
> from. The other servers were fine. The backup had run
without any errors
> and
> had backed up 9 DLTs worth of files. The server in
question had 110
> gigabytes and 1 million files on it. It was spread
across 2 DLT tapes.
>
> When we did the phase 1 import there were no
problems. When we did the
> phase 2 import (where it reads the tape and re-
creates the database file)
> it
> would run for 15 hours (about 8 hours a tape) and
then fail with a
> "Unexpected EOF" media error. Ok tapes do go bad and
when we looked at the
> file it had created up to that point (160 meg
uncompressed) it listed more
> than 960,000 files. Well 96% is acceptable but when
we went into the
> Xwindow
> GUI to do a restore there was still nothing showing.
>
> After getting bounced around Veritas support for
more than a week we were
> finally told "sorry but that is the way the system is
designed". I was also
> told that there may be a way to re-create the index
files but that "you
> would have to pay Veritas Consulting" to do it. This
when we have a support
> contract!!! If a fix exists then I feel as a paying
customer with a support
> contract that I am entitled to it!
>
> The Good, the bad & the ugly:
>
> The only good thing was that I had not used
multiplexing! As such I could
> TAR off the files I needed when I discovered this
problem. Had I used MPX
> it
> would have been game over. Now TARing files off is
very time consuming and
> tedious and this is not what we pay Veritas for (and
yes they are
> expensive).
>
> The bad thing is that half our classes use MPX and
if this happens to them
> we are in trouble.
>
> The ugly thing is that when I asked Veritas tech
support how I could
> minimize the damage caused by bad media I got a
response devoid of thought!
> I know if I make more classes and do one 10 or 20 gig
volume per class then
> I will only lose those files in case of a bad tape.
Their advice was to use
> their new "feature" Multistreaming which uses MPX!!!
They also said that
> this wasn't a "support issue" but rather
a "configuration issue" and I
> would
> have to pay Veritas Consulting for any other info!
>
> Final Rant:
> If these are limitations of the Netbackup system
where in their sales
> brochures does it say "if one part of the tape goes
bad, you are had"? I
> would also suggest not using multiplexing at all if
you can help it as it
> will destroy your last hope in a situation like this
(TARing files off).
>
> Questions:
>
> 1) How do other tape backup systems handle importing
information off of
> media that have bad spots? I don't expect to get the
info back after the
> point in a tape where the media is bad but the stuff
before it should be
> available for restore.
>
> 2) Does anyone know how to recreate the index files
under Veritas Netbackup
> so it will see the files that are listed in its re-
created data file?
>
> In Netbackup there are 2 files created when you scan
a tape or do a backup.
> They are put in a directory:
> /usr/openv/netbackup/db/images/<servername>/xxxxxxxxx
x
> The files are <class_name_xxxxxxxxxx> and
<class_name_xxxxxxxxxx.f> (the .f
> file being the big one). In the
<class_name_xxxxxxxxxx> file there is a
> NUM_FILES which shows 0 but changing it to 960,000
doesn't work because you
> also need to update the files in the directory
> /usr/openv/netbackup/db/images/<servername>/INDEX
> That is where I need the help.
>
>
> Thanks
> _______________________________________________
> Veritas-bu maillist - Veritas-
bu AT mailman.eng.auburn DOT edu
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
bu
>
|
