NOexpire prevents the expiration of images, and not media ; media will still 
expire. Touching that will cause inconsistencies in your database and give you 
a slew of other problems down the road. it causes more problems than anything. 

The best option to not expire images is to either freeze the media that they're 
on, or use bpexpdate -recalculate to recalculate a new expiration date of 
infinity, or for however long you wish for the images to hang around. 

----- Original Message ----- 
From: "Karl Rossing" <Karl.Rossing at federated.ca> 
To: Veritas-bu at mailman.eng.auburn.edu 
Sent: Thursday, April 5, 2007 10:26:22 AM (GMT-0600) America/Chicago 
Subject: Re: [Veritas-bu] Preventing Media Expiration when doing a Catalog 


I think i ran into a bug with /usr/openv/netbackup/bin/NOexpire or the catalog 
restore. 

I tried to re-import the catalog tape of that were expired but the images did 
not show up. The images and catalog i'm looking for are 3 weeks old while the 
retention is 2 weeks. 

So NOexpire either doesn't work or I think the netbackupDB was possibly 
re-applying the transaction logs after the restore. 

I restored a 1 week old catalog/images and i can see them fine. I'll find out 
in about 1 week if NOexpire works. 

I'm not sure if i'm going to place a service call with Symantec about this or 
not, it depends on how much time i have to log everything they need. 

Karl 


veritas-bu-bounces at mailman.eng.auburn.edu wrote on 04/04/2007 10:37:20 AM: 

> > We are restoring a catalog tape to our dv environment(same server name). 
> > The catalog db seems to be expiring the images we are testing with since 
> > time has progressed past the expiry time. 
> > 
> > Is there a way to tell the catalog db to not expire any images? 
> 
> I came across this information in the past and wrote it down, but I am 
> not sure how well it works. But reportedly touching 
> 
> /usr/openv/netbackup/bin/NOexpire 
> 
> will tell netbackup to not perform any expiration. I figure it's good 
> for a decommissioned or DR server that is not actually performing any 
> active backups and doesn't need the space. 
> 
> -- 
> Darren Dunham ddunham at taos.com 
> Senior Technical Consultant TAOS http://www.taos.com/ 
> Got some Dr Pepper? San Francisco, CA bay area 
> < This line left intentionally blank to confuse you. > 
> _______________________________________________ 
> Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20070405/725f0cdf/attachment.html