Expired tapes should automatically go back to scratch.
You probably have some inconsistencies between your volume database
and the NetBackup catalog.
If bpexpdate or bpmedialist say the mediaid is not found or has no
valid data on it, use vmquery -m xxxxxx to check the status of the
tape in the *volume* database. If it has a date in the "assigned"
field, you probably have an inconsistency. You can use vmquery
-deassignbyid to deassign a tape in the *volume* database. It should
then go back to the scratch pool.
Although the issue described in the following technote is different,
it shows you how vmquery -deassignbyid works ....
http://seer.support.veritas.com/docs/274213.htm
Obviously you should be careful that you're not deassigning tapes with
live data on them.
On Thu, 31 Mar 2005 12:01:36 -0500, Jeff McCombs <jeffm AT nicusa DOT com>
wrote:
> Tim & other list readers
>
> Thanks for the advice. It's much appreciated. I think my precise problem
> with the original setup was that I didn't understand the whole pool concept.
> Took me awhile to figure out the best bar coding scheme too (speaking of,
> does anyone have a MacOS X barcode printing app?)
>
> What I managed to come up with is the following;
>
> Weekly full backups duplicated into two sets;
> Set 1 - Pool 'Weekly-Short', kept for 2 weeks
> Set 2 - Pool 'Weekly-Offsite', kept for 1 month
>
> Daily Incrementals:
> Mon, Wed, Fri - Differential Incrementals. 14-day retention
> Sat, Tue, Thur - Cumulative Differentials - 14 day retention
> Set 1 - Pool "Daily-Short" kept for 1 week.
> Set 2 - Pool "Daily-Offsite" kept for 2 weeks.
>
> Monthly Full backups duplicated into two sets:
> Set 1 - Pool 'Monthly-Short' kept for 2 months
> Set 2 - Pool 'Monthly-Offsite' kept for 6 months
>
> Yearly Full backups, one set, sent into the 'Yearly-Offsite' pool.
>
> *short pool tapes are kept onsite at all times.
>
> So my next question becomes, how do you manage expired media? As I
> mentioned, media wasn't shoing up in the media db, yet when I re-inserted
> expired media into the library and re-updated the inventory, the media would
> not be returned into the scratch pool. Bpexpdate would complain that the
> media wasn't in the media db, yet when I tried to use vmmove, I would get
> errors about attempting to move media that was assigned.
>
> So what gives? Shouldn't expired media automatically be returned to the
> scratch pool once it's been re-inserted into the library? Or am I missing a
> step here? If it doesn't do this automatically, is it because it's a Bad
> Idea, or is it because it's just another example of the 'Veritas Way Of
> Doing Things' in action?
>
> -Jeff
>
> On a side note, think Symantec is going to change the NetBackup name to
> 'Norton NetBackup'? :) Betcha it'll come complete with LiveUpdate library
> definition updates, and popup windows that tell you your license is expired
> every year. :)
>
> On 3/30/05 1:25 AM, "Tim Berger" <tim.berger AT gmail DOT com> wrote:
>
> > On Mon, 21 Mar 2005 12:14:34 -0500, Jeff McCombs <jeffm AT nicusa DOT com>
> > wrote:
> >> Gurus,
> >>
> >> I'm a little new to NB, and I'm hoping that some of you can offer some
> >> advice.
> >>
> >> I'm currently attempting to backup approximately 25 Solaris 9 systems,
> >> most of which use a Veritas-HA NFS server as the primary storage for non-OS
> >> related data.
> >>
> >> Additionally, there's a clustered (again, with Veritas-HA) system
> >> providing Oracle and MySQL database services, and another for providing
> >> mail
> >> services.
> >>
> >> Total, there's about 280 gig of data currently that's needing to be
> >> sent
> >> to tape, though I anticipate growth into the 500G range within the next
> >> year
> >> or so.
> >>
> >> Backups are to be done by a NB Enterprise 5.0 MP4 system with a
> >> Overland
> >> Neo 2k 26-slot DLT library. I'll be bringing in a second library of the
> >> same
> >> type, and an additional 500G of RAID-5 storage to add to the backup server
> >> for disk-staging. I'm also adding a Vault license to the mix for managing
> >> tapes to be sent off-site.
> >>
> >> My problem is, is that I can't seem to wrap my head around these darn
> >> policies & pools. This is going to be my second attempt at getting a
> >> workable system in place, and I think my first attempt failed because I'm
> >> either not accustomed to thinking about things in a scheduled fashion, or
> >> because I'm just to dense to absorb the concepts required to make it all
> >> work.
> >
> > This is probably because the netbackup policy/volume pool paradigm
> > doesn't map terribly well to real-world needs. ;-)
> >
> > Pardon me if I'm stating the obvious. I'll just try to answer your
> > questions.
> >
> > In my mind, pools are a useful way to tag tapes that have the same
> > retention. Schedules point to particular volume pools. This is a
> > convenient way to identify by visual inspection the volume use. For
> > example, LXXXXX tapes could be level0's and IXXXXX could be
> > incrementals. If you ever want to duplicate tapes, I believe you need
> > to specify a different pool to avoid contention problems.
> >
> > Policies are used to group hosts that will have idential schedules and
> > require the same directory paths. Schedules are defined within each
> > policy. Every schedule specifies a retention and volume pool.
> >
> >> Schedule wise, I'd like to come up with a way to provide daily backups
> >> with a short retention period for those "oh crap" moments. I'd also like
> >> Weekly, monthly and Yearly backups that will get rotated off-site for
> >> storage.
> >>
> >> daily tapes rotated every 14 days
> >> weekly tapes rotated out every 6 months
> >> monthly, same deal but a 1-yr rotation period
> >> Yearly backups are kept for 7 years
> >>
> >> So I guess what I'm asking, is how would you folks configure pools and
> >> barcodes and such? I just can't seem to wrap my mind around this darn
> >> thing.
> >> My original scheme was to do the following;
> >>
> >> Full backups on Sundays, sent to the 'Full' pool
> >> Cumulatives on Monday, Wed, Fri, sent to the 'Cumulative' pool
> >> Differentials on Tue, Thur, Sat, sent to the 'Differential' pool.
> >
> > Ideally, you'd have a separate volume pool for every retention level
> > and a separate schedule specifying each of those pools. Yes, this
> > becomes messy. Netbackup has no native way of stating that level 0's
> > on the first sunday of the month should have their retention extended
> > by 6 more months or that the first level0 of the year should have a
> > retetion of 7 years.
> >
> > The netbackup way would be to have multiple schedules using the same
> > volume pool, which will end up running more scheduled backups than you
> > need and would use more tapes than is necessary.
> >
> > Instead, use bpexpdate to tweak the expirations with a script. There
> > was a small thread on this ~ Feb 10. Check the archives.
> >
> > I'd recommend keeping pools simple. Unless you have a library with
> > hundreds of free slots that you don't need, managing multiple pools is
> > a pain because you need to make sure every pool is always well
> > stocked. This isn't necessary.
> >
> > I believe the most practical apprach is to keep the number of pools to
> > a minimum. One for level 0's, one for incrementals, and one for tape
> > duplications, if you choose to do that.
> >
> >> That doesn't seem to be a very good policy, since managing it all turns
> >> into this giant mess, and for some reason expired tapes never seemed to
> >> expire properly - they'd just stop showing up in the media db and never get
> >
> > They'll stop showing up with bpmedialist, but they'll show up with
> > vmquery -b -a. That's how you can detect an expired tape.
> >
> >> overwritten.. figuring out which ones needed to go off-site was a pain
> >> too..
> >
> > bpduplicate can be used to determine which tapes need to go offsite.
> > There are options to prevent duplication and will only show which
> > volumes would need to be copied. See the netbackup command line
> > documentation.
> >
> > For example, to find out which level 0, sched type FULL, sched label
> > Level0 volumes were written in that last 24 hours, do:
> > % bpduplicate -hoursago 24 -PD -st FULL -sl Level0
> >
> > Hope this helps.
> >
> >>
> >> I'm obviously missing something, and I'm hoping someone can provide me
> >> with some info so I can have a 'Eureka!' moment where it all clicks..
> >>
> >> Any help would be appreciated, even if it's just pointing me in the
> >> right direction to some good reading..
> >>
> >> -Jeff
> >> --
> >> Aoccdrnig to rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht
> >> oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist
> >> and lsat ltteer be at the rghit pclae. The rset can be a tatol mses and you
> >> can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not
> >> raed ervey lteter by istlef, but the wrod as a wlohe.
> >>
> >> _______________________________________________
> >> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >>
> >
>
> --
> Jeff McCombs | NIC, Inc
> Systems Administrator | http://www.nicusa.com
> jeffm AT nicusa DOT com | NASDAQ:
> EGOV
> Phone: (703) 909-3277 | "NIC - the People Behind eGovernment"
> --
> Aoccdrnig to rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht
> oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist
> and lsat ltteer be at the rghit pclae. The rset can be a tatol mses and you
> can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not
> raed ervey lteter by istlef, but the wrod as a wlohe.
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
|
