When something is going wrong in a NetWorker environment, the first thing you need to do is be able to run up some basic tests. If the issue has anything to do with NetWorker clients, you’ll want to be able to initiate a series of network, probe and index based tests. If you’ve got nothing scripted, ‘check-clients’ from IDATA Tools may very well be what you’re looking for.

As a command line tool, ‘check-clients’ can power through a suite of different tests and data gathering activities against your clients, all with very minimum effort on your part. Let’s look at the tests that are currently available:

[root@nox bin]# check-clients -l
Test Name           Test Description
------------------- ------------------------------------------------------
client_ids          Returns client ID for each configured client
empty               Report clients with empty indices
index               Perform nsrck -L3 on each client
index_rebuild       Perform nsrck -L6 on each client
info                Retrieve client information
list_active         List all configured clients in active groups
list_all            List all clients currently configured
performance         Check backup performance via bigasm
ping                Ping each client
probe               Savgroup probe for each client
resolution          Test/confirm name resolution
rpcinfo             Test rpcinfo/portmapper access
used_space          Calculates used space for backups

Now technically, not all of the above are actually tests as such – for instance, the used_space option was one recently requested by a customer to report on all backups currently held by a backup server for a client. Running it on one of my lab machines, the output looks like the following:

[root@nox bin]# check-clients -g all_active -t used_space
============================================================
Running test: used_space (Calculates used space for backups)
============================================================
        Client                         Used Space (GB)
        ----------------------------   --------------------
        archon                                    362.60783
        faero                                       0.00000
        luyten                                      0.00000
        nox                                       544.40887
        ----------------------------   --------------------
                 Total for 4 clients              907.01669
        ----------------------------   --------------------

To me, that’s a combo test/information gathering option; specifically the customer was after this particular test so that they could spot any newly added clients that hadn’t been backing up (i.e., by having a “Used Space” of 0 GB).

Equally, there’s use in periodically running the “client_ids” test – running and keeping the output of this test will give you help in any sticky situation where you suddenly need access to a previous clients’ host ID:

[root@nox bin]# check-clients -a -t client_ids
=======================================================================
Running test: client_ids (Returns client ID for each configured client)
=======================================================================
        aralathan = 65100d33-00000004-464fcacc-464fcacb-00050000-c0a86404
        archon = 3f33ca7b-00000004-43a4837c-43a484d7-00030000-c0a80006
        asgard = 00b151ed-00000004-43a4837b-43a4837a-00010000-c0a80006
        djwmp = 5560bbf6-00000004-4910cd4b-4910cd4a-01961a00-3d2a4f4b
        faero = 76c06b0a-00000004-453e8e44-453e8e43-00310000-c0a86406
        loki = d3f277da-00000004-4857452f-4857452e-00020000-c0a86404
        luyten = 93166424-00000004-4a2f8cde-4a2f8cdd-01041a00-3d2a4f4b
        nimrod = d6454919-00000004-496aaadc-496aaadb-006f1a00-3d2a4f4b
        nox = 85acae6f-00000004-464fbdd1-464fbdd0-00010000-c0a86404
        valhalla = 61d3ca1e-00000004-495525db-4955299a-00051500-98e71c17

Moving on into actual test territory, multiple tests can be teamed up to do a chunk of information gathering in one command. For instance, combining a ping test and a name resolution test against all active clients is as simple as:

[root@nox bin]# check-clients -g all_active -t ping,resolution
=====================================
Running test: ping (Ping each client)
=====================================
	archon  (0 responses, expected 4)
	faero  (0 responses, expected 4)
	luyten  (4 responses)
	nox.pmdg.lab  (4 responses)

=======================================================
Running test: resolution (Test/confirm name resolution)
=======================================================

	archon
		Name: archon (archon.pmdg.lab) (192.168.100.1) 
		Name: archon.pmdg.lab (archon.pmdg.lab) (192.168.100.1) 
		Addr: 192.168.100.1 (archon.pmdg.lab) 

	faero
		Name: faero (faero.pmdg.lab) (192.168.100.10) 
		Name: faero.pmdg.lab (faero.pmdg.lab) (192.168.100.10) 
		Addr: 192.168.100.10 (faero.pmdg.lab) 

	luyten
		Name: luyten (luyten.pmdg.lab) (192.168.100.18) 
		Name: luyten.pmdg.lab (luyten.pmdg.lab) (192.168.100.18) 
		Addr: 192.168.100.18 (luyten.pmdg.lab) 

	nox.pmdg.lab
		Name: nox.pmdg.lab (nox.pmdg.lab) (192.168.100.4) 
		Name: nox (nox.pmdg.lab) (192.168.100.4) 
		Addr: 192.168.100.4 (balrog.pmdg.lab (unknown))

None of this is re-inventing the wheel of course, but being able to just run a single command that cycles through and tests every active client (or even all clients) is particularly useful.

Even performance testing is catered for with check-clients; reaching out to the clients, the utility can run bigasm tests automatically – a great way for easily testing where performance hits are happening on the network. For example, a quick/basic demo of this option is below:

[root@nox bin]# check-clients -c luyten,nox.anywebdb.com -b Staging -S 50 -t performance
===============================================================
Running test: performance (Check backup performance via bigasm)
===============================================================
        luyten (Solaris/UNIX style test)
                Backup 50 MB to Staging
                50 MB took 12 seconds (4.17 MB/s)
        nox.pmdg.lab (Linux/UNIX style test)
                Backup 50 MB to Staging
                50 MB took 3 seconds (16.67 MB/s)

If you are looking around for a test kit option for NetWorker – and want access to a heap of other goodies at the same time – then ‘check-clients’ out of the IDATA Tools suite may very well be what you need.

 

While I was on my blog hiatus, IDATA Tools v4.2 was released, and I’ve been meaning to outline what has been delivered in this version.

This release focused on making key enhancements to existing tools, and covers:

ToolEnhancements
backup-reportIntroduced new comprehensive mode. When run on the GST server, this utility can now report on backup failures as well as successful backups.
dbufreeNow supports staging from AFTD to pools that are not of "Backup" type.
sslocateCorrected reporting of data to be cloned when savesets to be cloned span multiple volumes.
check-clientsImproved the performance test.
media-freeImproved support for running on Windows servers.
review-resNow supports emailing the configuration report once it has been generated.

For more details about what IDATA Tools can do, check out IDATA’s reseller site, Krisanya, and click the “IDATATools for NetWorker” link in the main menu. IDATA Tools is available for purchase, and of course remains free on subscription to IDATA support customers.

The next, and more substantial update of IDATA Tools is currently in the works – but if you’re using IDATA Tools now, I’d highly recommend you upgrade to v4.2.

 

I’m pleased to report that IDATA Tools v4.1 is now available. This new version features a host of updates, including but not limited to:

  • New utilities:
    • mediafree – Designed for use in VTL environments, this utility allows you to free up media within VTLs on the basis of all savesets on individual volumes (a) exceeding a user-nominated time since generation, and (b) having clones in all user nominated pools. This can be run interactively or automated using command line options.
    • backup-report – Designed to produce and email a daily report of all backups generated the previous day, delivering for each backup the client, saveset name, size, start and finish time, pools and volumes written to. This can be delivered in one of CSV, HTML or Excel format, with HTML and Excel format including totals, etc. While the default execution is for the previous day, the actual timeframe can be user specified. A sample HTML report covering weekend backups on a lab server can be seen here.
  • Reporting enhancements:
    • Various utilities have been updated to support non-US date formats as a configuration option.
    • Utility recyclable-volumes now has an option to report recyclable volumes by location rather than pool; for “lights out” style environments this allows quick checks of available media per jukebox. Additionally, sites that make use of the NetWorker location field will be able to quickly see what volumes in external storage have become recyclable as well.
  • Configuration and documentation enhancements:
    • Core utilities that require configuration file setup now include a -H help option which produces a sample configuration class; this sample class can then be copied and pasted into the configuration file and adapted to suit local needs.
    • Some previously included features were inadequately documented; these have been corrected.
  • And of course, reported bugs have also been fixed.

For more information on all the utilities in IDATA Tools, check out my original post on them, Turbocharged Administration with IDATA Tools, and the announcement for IDATA Tools v4.

 

Everyone has had that horror recovery scenario, where a user wants a file recovered, but they can’t tell you where the file was, or even on what machine it was stored. You can find this information out through a series of mminfo and nsrinfo commands, or, if you’re in a hurry and you have IDATA Tools installed, you can run the find-files utility to quickly locate it.

Say for instance I’ve got a user who lost the file “Safari4.0BetaLeo.dmg” somewhere between 6 and 1 week ago on either the machine archon or aralathan. To find where this file may be located in backups, one would run the following command:

[root@nox nsr]# find-files -c archon,aralathan -S "6 weeks ago" -F "last week" 
-f Safari4.0BetaLeo.dmg
=== Probe backups ===
    aralathan
    archon

=== Search for Safari4.0BetaLeo.dmg ===
    Check aralathan, 20 savesets to check
    Check archon, 8 savesets to check

=== Results ===
aralathan:/ @ 04/24/2009 23:45 (384942702)
Volumes: Staging-01, Staging-01.RO
    /Users/preston/Desktop/* Incoming/Safari4.0BetaLeo.dmg

archon:/ @ 04/25/2009 04:27 (15860863)
Volumes: Staging-01, Staging-01.RO
    /Users/preston/Desktop/DNB/Safari4.0BetaLeo.dmg

As I mentioned before, you can run mminfo and nsrinfo queries yourself to do this, but having a tool there just waiting for you to point it in the right direction can be a time-saving boon.

 

For the last several weeks I’ve been doing a lot of development work, putting the finishing touches on IDATA Tools v4, and it’s being released 1 May (AU/NZ – 30 April US, etc.)

This represents a significant functionality bump over the last version of IDATA Tools, and I thought I’d spend a few minutes mentioning some of the new features that I think make the tool set both useful and very compelling. This is by no means a comprehensive list – there’s been a lot of improvements.

By the way, in the list below I’m saving the best to last, so make sure you follow it right to the bottom!

list-resources

This is a new utility with one purpose, that being to quickly list all the resources of a given type as defined on the NetWorker server. This is basic, and a lot of people have scripted similar things in the past, but included in this tool suite, it helps you write your own scripts. Using list-resources, you can quickly grab details of all the configured clients, and then step through each client name in your own script to run some task, or do something to each configured group, etc. It has two output modes – the default is “human readable”, designed for when you just want to get some information out of the server. The second is delimited format – your choice of delimiter. This means you can extract information about any resource (and any field within a resource) in one simple command, in the format you want, for use wherever else you want.

For example, if you wanted a list of all your groups, whether they automatically clone and which pool they clone to, it would be as simple as:

C:\> list-resources -t group -c, -F "clones,clone pool"
Default,No,Default Clone
Daily Desktops,Yes,Daily Clone
Daily Development,Yes,Daily Clone
Daily NMC,No,Default Clone

Or, if you wanted a list of your licenses with their enabler codes and authorisation codes, you could run:

# list-resources -t license -c, -F "enabler code,auth code"

I developed list-resources on a whim, because I got tired of firing up nsradmin (let alone NMC!) every time I wanted to quickly check out some configuration option or get a list of resources. I was pleasantly surprised when every beta tester for IDATA Tools v4 commented on how useful the utility was for their environment.

check-clients

This long-term utility has been a bit of a sleeper – it’s not used as often as I think it should be used. I do strongly recommend that you give it a go – it’s great at automating a lot of tests and checks against clients, meaning that if you’ve got even just one client that’s malfunctioning, you can set check-clients running against it and gather all results in one command. For example, even something as basic as reconfirming name resolution for all active clients is as simple as could be using check-clients:

[root@nox ~]# check-clients -t resolution -g all_active
=======================================================
Running test: resolution (Test/confirm name resolution)
=======================================================
    aralathan
        Name: aralathan (aralathan.lab.idata.com.au) (192.168.100.7)
        Name: aralathan.lab.idata.com.au (aralathan.lab.idata.com.au) (192.168.100.7)
        Addr: 192.168.100.7 (aralathan.lab.idata.com.au)
    archon
        Name: archon (archon.lab.idata.com.au) (192.168.100.1)
        Name: archon.lab.idata.com.au (archon.lab.idata.com.au) (192.168.100.1)
        Addr: 192.168.100.1 (archon.lab.idata.com.au)
    arcweld
        Name: arcweld (arcweld.lab.idata.com.au) (192.168.100.232)
        Name: arcweld.lab.idata.com.au (arcweld.lab.idata.com.au) (192.168.100.232)
        Addr: 192.168.100.232 (arcweld.lab.idata.com.au)

Now in v4, there’s several new checks and pseudo-reporting options available. One requested by a new IDATA Tools customer is a particular favourite – generating details of the amount of space occupied by all backups for each client. The output looks like the following:

[root@nox ~]# check-clients -t used_space -g all_active
============================================================
Running test: used_space (Calculates used space for backups)
============================================================
    Client                         Used Space (GB)    
    ----------------------------   --------------------
    aralathan                                 138.51074
    archon                                     53.18894
    arcweld                                     2.98269
    asgard                                      7.92337

(I’ve cut the output there – you don’t need to see a full list of all my lab machines to get the idea.) Note the “all_active” option there; the command line means: run the used_space test against all clients that happen to belong to groups that are active (autostart enabled). No fussing around with long lists of clients if you don’t want to.

Additionally, as a sanity check run once a week (or even once a day), how about checking to see whether there’s any clients with empty indices?

C:\> check-clients -t empty -a
=======================================================
Running test: empty (Report clients with empty indices)
=======================================================
    rhltst5 has an empty index
    nazgul has an empty index
    rhltst6 has an empty index
    shrike has an empty index
    rhltst3 has an empty index
    rhltst4 has an empty index
    grumpy has an empty index

Phew! Lucky it’s a lab server otherwise there’d be trouble at the station.

Reporting enhancements

Under reporting more generally, there’s a whole raft of enhancements:

  1. Both client-report and review-res now allow you to specify additional fields to be reported on; thus, it doesn’t matter if your reporting requirements are different any more, you can just run the same reporting utility and add the extra required fields in. We also report on the client ID wherever possible too.
  2. (In fact, given how important it is to regularly, routinely extract details of clients and their client ID fields, the check-clients utility also has a new test which extracts and prints this information.)
  3. The idata-notify tool, always an excellent savegroup completion parser, has some extra options. First, it can now give you details of the last full backup date for each saveset listed in the savegroup completion report, and it can also now send all the additional information as a HTML attachment, such as in this example.
  4. Additional options are available in the find-files utility to allow you to run faster queries.

Portion Control for Cloning and Staging

These are without a doubt the two biggest enhancements to IDATA Tools in this release. By “portion control” I mean automatically break up cloning and staging operations into smaller, more granular activities with pauses inbetween by running operating on savesets at any one time.

Where is this useful? Let’s examine each utility:

  • In relation to cloning, sslocate supports portioning of the data to be cloned so you can set a large clone job running and know that periodically it’s going to stop, release resources, and in doing so give them up to anything that’s been sitting waiting for resources to become available. If a recovery is waiting for the tape you’re reading on to clone from, the recovery will get a chance to run before all cloning has finished, rather than you having to abort the cloning.
  • In relation to staging, dbufree is significantly more useful at freeing up space faster. Consider the following – you’ve got 200GB of a backup left to run, your disk backup unit fills, and you have to wait for NetWorker to stage out 500 GB due to watermarks before you can finish your backup. It’s maddening, right? Well, with portioning, you could still tell dbufree to stage out 500 GB of data, but to do it in portions of approximately 100GB. Disk backup unit space will get released at the end of each portion, meaning that instead of waiting for 500 GB to be staged, you’ll see space reclaimed after approximately 100GB, then another 100GB, and so on.

For both cloning and staging, you also get a level of reporting not normally available. Everyone when they run cloning and staging eventually get to the point of wondering “where is this at? how much is left to go?” Now by keeping an eye on the portion based cloning and staging, you’ll have a much better idea of how much data has already been copied, and how much is left to run.

In Summary

We’ve really put a lot of new features into IDATA Tools for this new release. Existing users should find the upgrade reasons compelling, and those of you who haven’t tried out IDATA Tools yet should contact us to request a trial.

 

My colleague Brian Norris has an excellent suggestion in his blog about periodically capturing the client IDs within the NetWorker datazone.

I plan on making his suggestion slightly redundant for users of IDATA Tools – I plan to update the client-report utility to include the client ID to assist with this very strategy.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha