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