|
Home > Archive > Data Storage > May 2005 > netbackup volume groups - what _defines_ them.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
netbackup volume groups - what _defines_ them.
|
|
|
| I can see that netbackup volume pools are for pooling of tapes based on
a requirement (unix backups, wintel backups, sybase backups etc etc
etc), and I can see that volume pools are allegedly for geographical
grouping.
Where in netbackup are these groups actually defined though?
For example, in the NBU configuration I have inherited ( :-/ ) I throw
tapes in the silo and they enter a scratch pool. I also see they enter
a volume group of 00_000_TLD at the same time. These tapes then get
used as required and get assigned by the policy that "grabs" them to an
appropriate volume pool. But what configuration assigns them to a pool
called scratch in the first place? And what config assigns them to the
group 00_000_TLD in the first place?
I then notice that certain scratch tapes end up in some pools and their
group name doesn't alter. But other scratch tapes end up in pools that
have their group name altered too - typically pools that have
"duplicate" in their name. This I think (?) has something to do with
vault management, but it doesn't explain why some of the tapes in these
duplicate pools have had their group altered and some not (retaining
the 00_000_TLD group assignment)!
I have tried to make sense of the pdf manuals from veritas but I'm not
finding it very intuitive :-(
Any easy pointers as to what may be happening? (You will by now have
realised there is no local doicumentation handy as to this particular
config.... *sigh* )
cheers
ian
| |
| AdrianC 2005-05-30, 8:45 pm |
| Ian,
Simply groups are the tapes controlled by a particular robot - in this case
robot no 000. So if they get spotted by the barcode reader in robot 000 they
go into 00_000_TLD. (Cant remember what the 00 is for).
The thing that moves new tapes into the scratch pool is a barcode rule.
Otherwise new tapes sit in the netbackup pool.
You can also have offsite groups - where the tapes are not in the library
but in the catalog - yes this is vaulting.
Eg: All oracle backup policies pick tapes from the Oracle Pool, (which if
empty moves one to it from the scratch pool), if you then want to duplicate
this tape by vault you need another pool for the duplicate tapes to go in -
say OracleDuplicates. When you then do a vaulteject of the duplicated
backups the tapes in the OracleDuplicates pool will move group from
00_000_TLD to offsitename group.
Read the vaulting admin guide
Adrian
"didds" <didds2@excite.com> wrote in message
news:1117203070.112603.88850@o13g2000cwo.googlegroups.com...
>I can see that netbackup volume pools are for pooling of tapes based on
> a requirement (unix backups, wintel backups, sybase backups etc etc
> etc), and I can see that volume pools are allegedly for geographical
> grouping.
>
> Where in netbackup are these groups actually defined though?
>
> For example, in the NBU configuration I have inherited ( :-/ ) I throw
> tapes in the silo and they enter a scratch pool. I also see they enter
> a volume group of 00_000_TLD at the same time. These tapes then get
> used as required and get assigned by the policy that "grabs" them to an
> appropriate volume pool. But what configuration assigns them to a pool
> called scratch in the first place? And what config assigns them to the
> group 00_000_TLD in the first place?
>
> I then notice that certain scratch tapes end up in some pools and their
> group name doesn't alter. But other scratch tapes end up in pools that
> have their group name altered too - typically pools that have
> "duplicate" in their name. This I think (?) has something to do with
> vault management, but it doesn't explain why some of the tapes in these
> duplicate pools have had their group altered and some not (retaining
> the 00_000_TLD group assignment)!
>
> I have tried to make sense of the pdf manuals from veritas but I'm not
> finding it very intuitive :-(
>
> Any easy pointers as to what may be happening? (You will by now have
> realised there is no local doicumentation handy as to this particular
> config.... *sigh* )
>
> cheers
>
> ian
>
|
|
|
|
|