Volume Naming and Groups for NetBackup

From World History Wiki
Jump to: navigation, search
Spaldam's FJ Pic World History Wiki is Brought to you by:
S.J.'s Adventures

These documents are for entertainment purposes only. Use at your own risk. This site is in no way affiliated with Veritas or NetBackup, and any trademarks are those of their respective companies.

If you need assistance with anything NetBackup and/or Disaster Recovery related, You can find me on linkedIn.

With the increasing use of Disk targets and snapshots for backups, many question the need for tapes in a backup environment. While it is possible to create a completely tape free backup environment, you still need to address the Disaster Recovery requirements of getting your data replicated off-site. Having a large enough disk array to send all your backups to disk storage can be expensive, but having two of them of the same size makes it twice as expensive (not to mention having an off-site location to keep it at, and the bandwidth to send it). Also if you are keeping backup data longer than 1 year, your de-duplication rates may start to drop off as most files are archived or discarded (or forgotten) after a year (more likely a few months).

The cost effective solution, is to keep your disk retention short (I recommend no more than 3 months, but no less than 3 full backups), so you don't need as much of it, and use the less expensive, easily portable, low-power consumption solution of tape for longer term retentions. Plus if you create your tape at your DR site, then it's already off-site so you have no need for a 3rd party storage vendor. Or you could try sending it to "the cloud", and then try to pull it all back over the WAN during a Disaster Recovery exercise.

Either way, it's good to evaluate all your options and decide on the cost vs benefits vs risk that you are willing to accept.

Volume Pools

For details on adding a Volume Pool see the Veritas NetBackup™ Administrator's Guide, Volume I - page ???.

Volume Pools are used to separate different types of tapes and to help identify a final destination.

Here's a suggested list of Volume Pools you may consider using, and their purposes:

None            –  Cleaning and Diagnostics tapes
NetBackup       –  On-site short retention testing pool and imported tapes
Catalog         –  Catalog Backups
DataStore       –  Required for the XBSA, Open Group Technical Standard Backup Services API.
                   I like to use it as a default pool within the Volume Pool Rules to flag mislabeled or misplaced tapes.
Archive         –  Long retention on-site data pool
Offsite_Archive –  Long retention off-site data pool (send off-site only if tapes are full)
Offsite         –  Off-site short retention data pool
NDMP            -  For NDMP backups
NDMP_Archive    -  For long retention NDMP backups
Scratch         –  Scratch pool

For encrypted tapes use the same as above, but with the required “ENCR_” prefix.

It's also good to limit the number of partially full media to maximize tape/media usage. This is accomplished by keeping the number of Volume Pools to a minimum, using Unrestricted Volume Sharing (media owner set to "Any"), and only ejecting (or vaulting) full tapes. There may be situations that call for more complex Volume Pool configurations, but usually this can be avoided, which helps keep your media management and costs to a minimum.


Media ID’s must be unique to insure identification of the correct tape. You can use things such as a location, or environment type, or other settings to try and make your bar-codes unique.

For virtual tape libraries (which I don't recommend unless you insist on using 8gb SAN instead of 10gb LAN - even then, some de-dup vendors now support OST over SAN), it's usually best to keep the individual volumes size to a minimum (50-200 gig each), and only create as many as needed, to insure optimal usage of the disk space. The one exception to this is when your VTL is used as a front end target with a physical tape library - hidden from the backup software (which I really don't recommend) - on the back end, in which case you must make them the same size as your physical tapes.

Here's an example for a mixed LTO and VTL environment.:

Location Virtual Unique Identifier PetaBytes
S - Salt Lake
L - Las Angles
If the tape is Virtual
This will be a "V#"
Were # is the VTL number

Otherwise it will be part
of the Unique Identifier
000-ZZZ for Virtual
00000-99999 for Physical
50 gig X 1000 tapes = 50 TB per VTL
+ X 24 letters = 690 PB per VTL

1 TB X 100,000 Tapes = 1000 PB
1000 / (52 weeks * 7 years)
= 2000 TB per week

For differentiating tapes intended for a specific library or a different density, or to easily identify the Catalog tapes (the only pool I recommend not pulling from scratch tapes), the second character can be a specific number or a "C" for Catalog.

Media is most efficiently used when it is placed back into a Scratch Pool when it expires to allow it to be used within any Volume Pool.

All cleaning and diagnostics tapes should start with a different character for easy identification, such as CLN with a post-fix of "cu", and DIAG followed by the standard "l#" post-fix.

Volume Groups

The ultimate purpose of a volume group is to describe a location. NetBackup already provides a default naming convention for volume groups on the tape libraries. It's easy to continue following this naming convention for other locations as well.

Up to three fields can be used, each separated by an underscore (_).

Location Group
(i.e. robot group #)
Robot #, Location Name
or other information
Media Density or Robot Type within Location
000, 001, 002,
IronMountain, Office,
Missing, etc.
00000, 00001, Offsite, etc. TLD, LTO6, VTL, etc.

Volume Groups can be configured in Vault to aid with move tapes to an off-site Volume Group, and automatically updated when injected into a tape library; however, if tapes are manually ejected or put into a cabinet, NetBackup has no way of tracking their movement, and thus the Volume Group must be manually updated as well.

Volume Pool Rules

Volume Pool and Bar-code rules should be properly configured to allow pool/scratch configurations/assignments to occur automatically.

For details on configuring Bar-code rules see Veritas NetBackup™ Administrator's Guide, Volume I - pages ???. Also see pages 441 - 444 for media ID generation rules.

Also see Tuning and Testing for NetBackup#Create Barcode and Media Management Rules

Here's some guidelines you may follow when setting up Bar-code rules.

  1. New tapes get put into the Scratch Pool
  2. Cleaning tapes get put into the None Pool
  3. VTL tapes get put into the DataStore Pool
  4. Other tapes (including older tapes/labels) get put into the NetBackup Pool
  5. BarCodes show the full 8 digit label, including the two density designator.
    Creates a line in the vm.conf file that looks like this:
    MEDIA_ID_BARCODE_CHARS = 0 8 1:2:3:4:5:6
    This may also require tweaking the configuration on the tape library - (Quantum Scalar series libraries require changing the partition to show bar-codes as "Extended")
  6. Media Labels are the correct 6 digits (as to not show the two digit density designator) and start with the location designating letter.
    This also requires insuring your tape labels are put on the tapes with the proper orientation.

Tape Library Automatic Inventory

See also: Miscellaneous_NetBackup_Standards#Libraries_and_VTL.27s

On any NBU server controlling the robotic library, the /usr/openv/volmgr/vm.conf can be updated to do auto inventory.

echo "AUTO_UPDATE_ROBOT" >> /usr/openv/volmgr/vm.conf

This eliminates the need to manually run an inventory to pull the tapes into the library. Be sure the library in question supports this feature before setting. Often times partitioning a library with a shared I/O port (sometimes called the MAP or CAP) prevents this feature from working.

Back to NetBackup