Sometimes it’s helpful to run NetWorker in debug mode – but sometimes, you just want to throw the nsrmmd processes into debug mode, and depending on your site, there may be a lot of them.

So, I finally got around to writing a “script” to throw all nsrmmd processes into debug mode. It hardly warrants being a script, but it may be helpful to others. Of course, this is Unix only – I’ll leave it as an exercise to the reader to generate the equivalent Windows script.

The entire script is as follows:

#!/bin/sh

PLATFORM=`uname`

if [ "$PLATFORM" = "Linux" ]
then
	PROCLIST=`ps -C nsrmmd -o pid | grep -v PID`
elif [ "$PLATFORM" = "SunOS" ]
then
	PROCLIST=`ps -ea -o pid,comm | grep 'nsrmmd$' | awk '{print $1}'`
fi

DBG=$1

for pid in $PROCLIST
do
	echo dbgcommand -p $pid Debug=$DBG
	dbgcommand -p $pid Debug=$DBG
done

The above is applicable only to Solaris and Linux so far – I’ve not customised for say, HPUX or AIX simply because I don’t have either of those platforms hanging around in my lab. To invoke, you’d simply run:

# dbgnsrmmd.sh level

Where level is a number between 0 (for off) and 99 (for … “are you insane???”). Running it on one of my lab servers, it works as follows:

[root@nox bin]# dbgnsrmmd.sh 9
dbgcommand -p 4972 Debug=9
dbgcommand -p 4977 Debug=9
dbgcommand -p 4979 Debug=9
dbgcommand -p 4982 Debug=9
dbgcommand -p 4991 Debug=9
dbgcommand -p 4999 Debug=9
Note that when you invoke dbgcommand against a sub-daemon such as nsrmmd (as opposed to nsrd itself), you won’t get an alert in the daemon.{raw|log} file to indicate the debug level has changed.
 

A question that’s just come up on the NetWorker mailing list again (it’s a periodic one) is, “how do I query mminfo to return all savesets that don’t belong to a particular group?” or “how do I return all savesets except those belonging to a single client?”

The part of mminfo here that causes the confusion is the bang operator – otherwise known as the exclamation mark (!).

In a lot of programming languages, an exclamation mark is typically equated with “not”. For instance, if we look at Perl:

if ($a != b)

Means “If the value of $a is not equal to the value of $b”. It’s a similar story in other languages that make use of the exclamation mark. Indeed, making it perhaps a little more confusion to the uninitiated is that in mminfo, ! does indeed mean “not”; the trick though is that it’s not available for all possible usages, just a subset.

In particular, you can only use the exclamation mark within an mminfo query when against a flag field. Not a string field, nor a numeric field, etc. Just a flag field. The “catch” is that if you use it against a non-flag field, mminfo won’t abort the query, but will instead ignore the not component specified. This means that if you specify, say:

# mminfo -q "!client=archon,savetime>=24 hours ago"

The query actually executed will be:

# mminfo -q "client=archon,savetime>=24 hours ago"

There’s clearly a big difference between the two, and it’s brought a few people unstuck.

As it currently stands in NetWorker, if you want to retrieve mminfo details for strings that don’t match particular patterns, your only option is to use an external filter, such as:

  • A command line utility, such as grep;
  • Writing the output to a text file and manually extracting;
  • Writing a custom filter programme;
  • Writing the output to a CSV file and filtering in a spreadsheet.

It would certainly be highly desirable for NetWorker’s mminfo command to be updated to fully support the not/’!’ syntax; until then however keep in mind that it will be ignored for non-flag fields, and you’ll avoid getting into trouble with it.

 

Amazon are currently selling Enterprise Systems Backup and Recovery: A Corporate Insurance Policy at a reduced price.

If you’ve been wanting to buy it, but the price has previously put you off, this may be a good excuse to go back and revisit Amazon for it.

Remember if you do read it that reviews are always welcome!

 

Having spent the last several days of my holiday clearing lantana from my property, I needed to take a break from yard work and spent the day writing a new micromanual.

Titled “Configuring LinuxVTL on CentOS for NetWorker”, this micromanual focuses on providing a start-to-finish description of the process required to install and configure the LinuxVTL software and then subsequently get it configured with NetWorker – in this case, NetWorker 7.6 SP1.

If you’re interested in using the LinuxVTL for lab/testing purposes, but needed a more comprehensive guide on getting it set up and running, this micromanual should get you over the line.

To download, go to the micromanuals page and fill out the registration form.

 

It used to be 10 years ago that you couldn’t do anything in the backup space without having an answer to the question, “How do you achieve BMR?” Nowadays, it’s not a dirty word in backup, but it certainly seems to be somewhat passé.

So what happened? Is BMR now dead? Is it on life support? Did it ascend?

It’s an interesting question. I think that as an independent technology, BMR has become ever more niche, and what we’ve seen is a gradual shift in technology so as to allow BMR to become a silent feature. As such, it doesn’t necessarily get a lot of attention – it just blends into the background.

For the most part, I’d suggest that I found BMR to be more of a focus point in the Windows market, then later in the emerging Linux market, though still with a primary focus on Windows. This wasn’t to say that rapid systems recovery wasn’t important on other platforms, but on those platforms there were frequently technologies built into the OS. AIX could boot from a system image tape. Solaris could be Jumpstarted, etc. Eventually, Linux could be Kickstarted.

In the Legato space, BMR options were pretty challenging for the most part, so 10 years ago I’d regularly recommend customers wanting to BMR their Windows servers to deploy Ghost. It wasn’t perfect, but it did the trick – the goal in my mind was to get a system back to a state of easy recoverability; i.e., BMR was about allowing you to get a system back to the point where you could run a full recovery. Nothing more, nothing less. That was undoubtedly influenced by the lack of integrated BMR within NetWorker, but it worked, and it let each product focus on what it did best.

These days I think BMR is something that’s effectively available in most enterprise spaces without actually needing to reference it as an independent technology. So it comes into play primarily as a result of virtualisation and snapshots.

Within virtualisation, there’s two options that tend resolve independent BMR requirements – templates, and image level backups, though for slightly different reasons.

Templates are designed to allow a rapid deployment of a new guest – be it just at the operating system level, or a combination operating system and application level; such templates will usually include a certain level of patching – enough to get a host at a secure enough point to connect to a corporate network. But they don’t have to be used just for the deployment of a new guest; instead, if a guest fails or becomes otherwise hopelessly corrupt, there’s nothing stopping the use of a template to rapidly bring the guest “back to life” to allow a regular recovery. If backups are being done at the guest level, then a smart template will also include the backup software so that it’s immediately available on system (re)creation.

On the other hand, image level backups fulfil the old “cold backup” niche. When virtualisation started hitting its stride, image level backups were seen as the future, but then reality struck and it became painfully obvious that recovering a 100GB virtual machine to pull out a 10KB document was wasteful and time consuming. Since then file level recovery from image level backup has improved, but it’s still not an omnipresent technology. That being said, image level backup works perfectly as a rapid BMR mechanism. Even assuming a situation where an image level backup is only taken once a month, recovering a machine from an image backup done 30 days ago puts you in a situation to allow regular host-based recoveries to run with minimum effort.

We frequently look at snapshots at enabling more useful RPO and RTOs than traditional “once per day” backups. It’s common for instance to see NAS systems with hourly read-only snaps immediately available to end users for self-directed recoveries. They’re also used to facilitate traditional backups by doing quiesced backups with minimum downtime, or less disruptive backups.

However, certainly in the enterprise space, snapshots equally provide an excellent BMR solution. Snapshot, patch, revert to snapshot if patch fails, etc. Array level snapshots (IMHO) provide a significantly greater level of flexibility than a traditional BMR solution where the primary focus is getting a machine back to its most recent usable state. Snapshots are so useful on this front that they’re even used within virtualisation for exactly that reason – why go back to an image level backup, or waste time doing a cold backup of a virtual machine when you can just roll back to a snapshot taken 10 minutes ago?

What I’ve been observing now for a while is that BMR as an independent product gets very little attention these days in enterprises. At the small to medium business it still gets bandied about – often for desktops as much as for servers, but it increasingly seems that virtualisation and snapshots have gobbled up most of the BMR space in the enterprise.

It seems that over time even that space may become narrowed. Looking at Mac OS X as an example, the ability to do a new system install referencing a Time Machine backup is a perfect example of an operating system integrated approach to BMR. Does it solve all BMR issues, even on the OS X platform? No, but it addresses the 80% rule, I believe. Will it be the only such product? I can’t believe so – I have to believe we’ll eventually see something comparable in other operating systems.

What are your thoughts?

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha