Netbackup script to report scratch tapes

4 05 2010

I’ve seen Netbackup used in two completely different ways now. In my last environment all tapes rotas, movements and scratch tapes were handled manually. We had a spreadsheet showing tape sets (see below for an example), when these tapes were collected by Iron Mountain, which days of the months we defined as Monthly/Quarterly backups and so on. In this scenario each set of tapes is a number of tapes – on some days you may use less, on some days you may not have enough loaded.

In the new environment we let Netbackup dictate which tapes are in the scratch pool and free for re-use based on the expiration policy of the jobs written to those tapes. In theory this should mean that you only ever use as many tapes as you need for a given backup job. The problem with this set-up is that although it is, in theory, more efficient, you don’t always know which tapes you will need each night and how many you have free.

Each day guys were running NBU command lines to show which tapes were in the scratch pool, but having to manually sift through them to see which tapes were currently sat in drives/libraries and of the ones held off-site, which tapes were of which format (LTO2, 3 or 4).

The following script can be scheduled to email out a list of tapes in the scratch pool, which are in what library and also groups the offsite tapes by format. It was knocked up in a hurry so isn’t as parameterised or dynamic as it should be, but the comments should help you fix it for your needs…

Read the rest of this entry »


Comments : 1 Comment »

Categories : Netbackup, Powershell, Scripting

Using Powershell to report on Netapp filer snapshots

2 03 2010

We had a few issues recently where SnapManager for Exchange and SnapDrive were failing to communicate properly which resulted in a weeks worth of missed snapshots before anyone realised what was going on.

I wrote this script to report on the status of snapshots. The filer name is passed as a variable and a list of volume names is stored as a variable at the top of the script. The output is nicely formatted email.

  1. The script uses SSH to connect to the filer (see my SSH guide for Netapp filers)
  2. For each vol listed in the array, the list of snapshots is returned
  3. Any line with “__daily” in is processed – all others are ignored (we only care about our nightly verified snapshots which are all named __daily)
  4. The snapshot name contains the date/time it was taken – this is read and if the date is within 24 hours of now a success is return (since reports are run the day after the verified job). If the date is over 24 hours a failure is returned.
  5. A nicely formated HTML email is sent out which looks a little something like this…

Please see below for today’s backup report.

VOL Name Status Snapshot name
Vol_Exc02_DB Success 0% ( 0%) 0% ( 0%) Mar 02 01:44 exchsnap__exchange02_03-01-2010_23.00.14__daily (busy,backup[0],dump)
Vol_Exc02_LOG Success 0% ( 0%) 0% ( 0%) Mar 02 04:38 eloginfo__exchange02_03-01-2010_23.00.14__daily
Vol_Exc02_DB1 Success 0% ( 0%) 0% ( 0%) Mar 01 23:00 exchsnap__exchange02_03-01-2010_23.00.14__daily
Vol_Exc02_LOG1 Success 1% ( 0%) 0% ( 0%) Mar 02 01:27 eloginfo__exchange02_03-01-2010_23.00.14__daily
Vol_Exc03_DB Success 1% ( 1%) 0% ( 0%) Mar 02 00:50 exchsnap__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_LOG Success 0% ( 0%) 0% ( 0%) Mar 02 02:06 eloginfo__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_DB1 FAILURE 1% ( 1%) 0% ( 0%) Feb 26 23:00 exchsnap__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_LOG1 FAILURE 0% ( 0%) 0% ( 0%) Feb 26 00:32 eloginfo__exchange03_03-01-2010_23.00.13__daily

See the script and HTML files after the jump… Read the rest of this entry »


Comments : 2 Comments »

Categories : Netapp, Powershell, Scripting, Storage / Backups

Scripting Netapp filers

26 02 2010

Scripting the Netapp filers can be accomplished by using either RSH or SSH. Both of these options must be enabled on the filer(s) in question using.

In either case scripts are not processed on the filers themselves. They are scheduled and run on Windows/Linux systems using their native languages (e.g. Vbscript or Powershell). These scripts simply call native OnTAP commands against a filer which then returns data in the form of text. This is important to note as although Powershell is a useful language to use OnTAP will not return native PS objects which means you are limited to text/string based manipulation.

RSH

This method is the least secure but is the quickest and easiest to set up. Users need not necessarily be filer administrators. Although there is some degree of security in the sense that access is restricted to a set user account and accessible only via a set IP address, data is not encrypted.

RSH is not natively supported in Windows 2008 [from the command line] as it is in Windows 2003.

To enable RSH on the filer use the following command:

options rsh.enable on

You must also specify user accounts and IP addresses via the FilerView web interface.

SSH

Windows 2008 does not natively support SSH either so this is accomplished using plink.

To enable SSH on the filer use the following commands:

secureadmin setup
secureadmin enable ssh

Read more after the break…

Read the rest of this entry »


Comments : 4 Comments »

Categories : Netapp, Powershell, Scripting, Storage / Backups

Netbackup Report Scripting

25 02 2010

Hi everyone. I’m going to jump right in to my first post (the main reason for starting this blog in the first place) and show you the progress I’ve made with automating daily reports using our backup solution of choice, Symantec (used to be Veritas) Netbackup.

Until now our users have demanded daily reports to be emailed out to key individuals. The format of these emails was quite basic in theory…it simply showed a list of all servers (clients) that were backed up, their status from last night (e.g. successful, failed, etc…) but then, crucially, a list of files that had been skipped.

The reason for listing each file that had failed was due to Netbackup’s poor poor (don’t get me started on how poor) feedback in the Activity Monitor and it’s built in reports. You see sometimes jobs could be marked as “Successful with warnings” if the job completed but the odd file had been skipped (if it were in use, for example). But other times, although it still listed which files had been missed if you double-clicked on each job, it showed the overall status as Successful. This meant that to report on the servers in the format that was required by our users we had to manually trawl through the 360 jobs across two Netbackup servers just to copy and paste the lines of the files that had been missed.

Needless to say it didn’t take me long to get bored of this so I started looking at a way of reproducing our reports automatically. After some time, I’ve come up with a solution – it uses VBScript to parse the logs files which I output using a few key Netbackup command-line tools.

The basic process and components to the script are as follows…

  1. A VBscript calls a number of external batch scripts
  2. These batch script run NBU commands and spit their output to text files
  3. The VBscript then reads these text files
  4. The VBscript reads a servers.txt file to determine what jobs to report on*
  5. A LOT of array and string manipulation is used to catalogue which jobs have run and which have errors and if so, it collates all skipped files
  6. These arrays are then parsed and dumped to either an HTML file (which can be used directly in the body of an email) or, as I’ve recently changed to script, outputs to an Excel file.

There are some nice bits to the script(s) and some really nasty bits – I welcome you to improve on the original and share it with everyone (for example, I know there is a much neater way of calling and parsing the output of batch jobs rather than the nasty wscript.sleep I have used).

* A text file (called servers.txt) is kept along side the scripts. This file is manually edited and must be kept up to date. The file is a number of lines, each one representing a client/job that we wish to report on. The format is as follows:

60, myserver, mypolicy, GroupName

The number at the start represents what days of the week the report should be generated. myserver is obviously the client that is to be reported on. mypolicy is the name of a policy that you are reporting on (since a client may me a member of multiple policies). Finally, GroupName is free text and can be used to group similar clients (that may not necessarily be grouped by the same policy.

The scripts necessary to generate a report are…

  1. generateReport.vbs
    The primary script which calls the others and also performs of the processing and HTML/Excel generation
  2. jobs_summary.bat
    Issues the bpdjobs – simmary command and pipes output to a text file. This provides a simple overview of number of total jobs and the number that have succeeded, failed or errored.
  3. jobs_report.bat
    This is the main batch script upon which the report is generated. It is a hideous mess of space-formatted garbage and why so much processing is needed to generate a useful and nice looking report.

Clicking the scripts above will take you to a separate page with the code and more explanations of how to use it in your environment.

UPDATE: Okay, so enough of you have expressed an interest that I decided to put it up for public download. Please note that it is not currently protected via any kind of license so please use your discretion. I have included a very basic READ ME that I encourage you to go through. Post your comments here if you have any problems.

Download: Dave’s Netbackup Reporting script


Comments : 12 Comments »

Categories : Batch, Netbackup, Powershell, Scripting, VBscript