Summary:

I didn't really do an "upgrade," I loaded up a new system on a
separate set of hard drives and copied files forward. Problem was I
didn't bring ~netbackup/db/media/mediaDB forward.

I've been running on 3.4 for a couple weeks, so I have "other" tapes
no matter which media database I use. I've opted to bring my 3.2
media database forward and import the tapes that I've used since the
cut.

So far so good. I need to do vmquery -deassignbyid on these tapes to
make media manager forget about the tape being assigned (else the
import fails). Then I run bpimport -create_db_info to scan the tape
and resynchronize everything.

Thanks to the respondents to my question.

--- Larry Kingery <lkingery AT veritas DOT com> wrote:
> DBBACKUP is really "other".
> 
> Do you have media servers?  Were they upgraded at the same time?
> 
> DBBACKUP showing in a_m is often due to a lack of abililty to
> connect
> to a media server.  I'd suggest comparing a_m to bpmedialist
> -summary and
> look for a pattern.
> 
> 
> > 
> > Under 3.2 I had, understandably, a lot of FULL media. When I cut
> > 3.4.x into production, the available_media script starting
> listing
> > all the tapes that were FULL under 3.2 as DBBACKUP. Newly FULL
> tapes
> > filled up under 3.4.x show up as FULL.
> > 
> > Digging into this further, I've found out that utilities like
> > bpmedialist are saying that these DBBACKUP tapes are not in its
> > database.  Hmm...
> > 
> > All the tapes show on the management windows and I'm able to
> browse
> > the information stored on the images on the tapes.
> > 
> > I'm running bpcheckdb -checkimages right now and it looks like it
> is
> > identifying the problem, and it looks like I need to import all
> the
> > affected media.
> > 
> > Anyone shared this experience?


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/