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
>
--
-Tim
|
