Alex, you'll get a dozen recommendations.  This is the right one.  :-)

> What is "best practice" with regards to Volume Pools ?
> 
> We are thinking of using a single Volume Pool for all of our 
> data tapes.
> Is it good practice to use the "Netbackup" Volume pool for 
> this situation ?

Yes to the first, no to the second.  

Offline catalog backup tapes in NetBackup.  Everything else in
"dsto-mlb".

-  "dsto-mlb" is a made-up name to suggest that you name your primary
pool after your datacenter (and supposing DSTO and Melbourne and that
you have, or may later have, other datacenters).  The intent is to have
a simple way to keep your DC's tapes separate from "dsto-prth"'s tapes
during the inevitable consolidation or other circumstance that
co-mingles your and foreign tapes.

-  Practically, you'll still have a None pool (cleaning tapes, tapes
with errors you don't want used until you test or toss them).  And
probably a scratch pool, a duplicates pool or two, a duplicate catalog
backup pool, the goofy DataStore pool unused.  

-  I always suggest a "test" pool.  Keeps your production pool from
accumulating junk test data, frees you to do any testing and expiring
you need to without risk of filling/tying-up/expiring production tapes.
Test what you want, expire the tapes when done and let them go back to
scratch.

-  There _are_ reasons to have separate pools.  Find a logical division
_with_ a reason that justifies the administrative and operational
burden.

- - Customer privacy.  Do you have two clients whose data should not be
mixed?  Army and Navy pools, then.  Related to this is restricting
access to a pool to a specified host (media server) if there's a Really
Good Reason to do this.
- - Minimizing collateral damage.  Does someone occasionally leak
classified info onto an unclassified system--requiring you to destroy
all unclassified backups which might contain it?  Subdivide in any way
that makes sense to minimize loss of the rest of the backups.  
- - Related to the above, is there a project or client whose backups may
need to go elsewhere tomorrow?  Just eject all the tapes in that pool
and send them on their way with 100% of their info without losing any
that's not theirs.
- - And a third variation on the going-offsite theme:  Maybe a
given-to-legal pool for duplicating backups that go off to some other
entity and may not return...  
- - Availability assurance.  Have a really small library and need to be
positive there'll be enough tape for the big weekend database backup?
Separate, stocked-up "oracle" pool so that other backups/users can't use
up those tapes.  Or a separate "user" pool if you allow user
backups/archives and that's the group that might use up your free space
(though this method loses a lot with the advent of automatic draw from a
scratch pool).

There are undoubtedly other good reasons, but if you insist that someone
come up with a rationale that can't be met any other way--not just
something that _sounds_ logical.  It makes me crazy to see Full and
Incremental pools, or Unix and Windows ones.  Remember that pools are
another multiplier of tapes-in-use, alongside multiple media servers,
mux/non-mux and differen retention levels.

You're on the right track.  Simplify.  Let the computer manage what it
can and save your brain for important things.