Suggested Policy Standards for NetBackup

From World History Wiki
Jump to: navigation, search
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.

NetBackup Policy naming tends to differ greatly depending on the personality of the person who did the initial setup, and the culture of the environment or company. Setting some basic guidelines around how to name your policies can greatly improve the cleanliness and clarity around your backup environment. For small environments, doing a single policy (or multiple policies) per client is an easy way to do it; especially if your server names follow a standard naming convention. However in larger environments, and especially those using quires to get the client list, this method doesn't work.

Here is a suggestion of how I would configure NetBackup policies for a large environment with hundreds or more clients.

The Policy Name is made up 3-4 fields, each separated by an underscore (_) starting with generic, and moving to more specific. Depending on the environment you may find that the most generic classification for the 1st field is a location (if you have multiple sites) or a function (such as SQL, FNP, etc) or even a tier (such as Development, or Prod). For example:

1st Field 2nd Field 3rd Field 4th Field (Optional)
Tier (can also be Location, or Type) Location (City, DC name, Network, etc.) Application/Platform Descriptor
2-4 Characters 2-3 Characters 3-5 Characters Free Form
Dev, Prod, QA, Test,
Legal, Vault, Catalog, etc.
SLC (Salt Lake City)
DEV (Denver)
DAL (Dallas)
PHX (Phoenix)
DC1, DC2, etc.
LAN1, Blue, Black, DMZ, etc.
Robot #
Win, HypV
Ora, FNP, Sql
Unix, VMS
Exch, VMware

01, 02, 03,
D, E, etc. (drive letter),
Arch, Hot, Ctl, DR, etc.
What ever is needed
to make the policy
name more intuitive.

Policies should be named so that they are easy for anyone to read and understand what it is intended for. Total length should be as short as possible without compromising readability.

I've also use policy names help determine the customer and CTI that should be used for problem tickets and e-mails. The underscore (_) helps with scripting when you want to pull out a specific field to compare to a database or configuration file to automate the ticket creation and e-mails.

Policy priorities can be set to help determine the urgency and importance of a particular backup. Scripts can be written in such way that it will automatically produce the appropriate procedures to use as follows, or set the ticket priority. For example:

Urgency Level Escalation/Notification Policy Priority Range
1 - Urgent Page/e-mail on-call.
If no answer (not assigned) in 30-60 minutes,
escalate to secondary on-call, etc.
Requires escalations in ticketing system.
99999 - 90000
2 - High Page/e-mail on-call in the morning/daytime
and auto assign ticket to on-call person.
Script can "sleep" until morning if needed.
89999 - 60000
3 - Medium E-mail NetBackup group and assign ticket to group.
This is the Default Priority level.
Escalate after 8-24 hours.
59999 - 30000
4 - Low E-mail NetBackup group and auto close ticket.
Primarily Used for Testing.
29999 - 10000
5 - Notice E-mail only, should not generate tickets 9999 - 0
Other Default Priorities
For Reference
Imags Cleanup & Import
Drive Operations
Media Operations
Duplications (to be Set in Vault Profile & SLPs)
75000 - 70000
60000 - 80000

If the policy is not named appropriately or the tier level cannot be determined, the script can default to Tier 1 and a note placed in the e-mail/ticket.

Using scripting (i.e.: "bp_exit_notify"), you can detect certain conditions and override certain response as needed. For example, if policy name's 3rd field starts with Win or VMS you know status 1's are often unavoidable and not serious issues, and can change them to a "Notice" or "Low" priority.

For all status' determined to be configuration issues, the e-mail can be sent only to the NetBackup team.

When you combine the Error Code, and Policy Type, and other information, it can help you produce output in the e-mail, or to the ticketing system, that will give educated guesses as to the reason for the failure. If certain conditions are consistent at producing certain errors, you could possibly even script in a automatic response, or even a potential fix and re-try.

Basic networking tests can also be performed form the script to help aid in troubleshooting.

Other Policy Setting Standards may include:

  • Insuring the appropriate policy types are being used (Such as using VMware backup policies, not direct client backups)
  • Using SLP's and/or Storage Unite Groups for all policies (not using Storage Units directly saves you headaches down the road)
  • Data Classification Usage (if applicable to your environment - I have yet to seen a necessity for this)
  • Checkpoint settings (every 15-30 minutes is a good setting)
  • Media Owner (I like to set it to any, but you can complicate your media management as much as you want)
  • Client Side De-dup and/or accelerator usage (usually a good standard to use, unless you have older systems with low CPU power)
  • True Image Recovery with Move Detention (this is especially important if you want to use BMR, or full volume/file system restores)
  • Backup selections should be set to "ALL_LOCAL_DRIVES" or use VIP/Automatic Query when possible (exceptions may apply, but excludes lists are also very helpful in avoiding exceptions).
  • etc...

Back to NetBackup