Using probe based backups in NetWorker

Probe based backups were introduced in NetWorker 7.5, though you might think they had already existed in there, given the limited coverage they’ve been given thus far. Most announcements relating to NetWorker 7.5 have touted the virtualisation improvements, IPv6 support, etc.

Like so many things related to backup, some of the most useful things are the least “sexy” and thus get the least attention.

What is a probe backup?
Probe backups are a new class of scheduled backups that rely on executing a custom command/script on one or more clients within a group to determine whether the backup should be run. Additionally, rather than running just once per day, probe backups are designed to be run as frequently as necessary (as frequently as every 15 minutes) over a defined start and stop window.

To better understand how probe backups work, we need to first remember how standard groups work. These work as follows:

• At a preset time of the day, the group starts.
• A backup attempt is made on all clients that belong to the group.
• Optionally the group may start more frequently than once daily.

That’s about it with group based backups – they’re good for regular, routine backups. But they don’t cover all the options – nor would you expect them to.

There are a few of important scenarios that regular groups don’t help with which has traditionally required additional (and at times, messy) scripting. These are:

• Having a client process determine whether a backup is required.
• Backing up after a particular event on a client has occurred when that event isn’t in the control of the backup administrator.
• Cross-system sychronisation – i.e., backing up only when say, key applications are shutdown on every client within a group.

For the first issue, the traditional mechanism was to configure client-initiated backups. However, these violate centralisation of the environment, and introduce a variety of administrative headaches. For the second issue (e.g., caused by the need to export a non-supported database for filesystem backups), typically the DBA and the backup administrator would agree on a time at which point backups would start. This could lead to all sorts of issues if exports didn’t finish in time, etc. For the final option, a variety of mechanisms could be deployed that would normally consist of savepnpc and/or groups running groups.

So, back to the question – what is a probe backup? – it’s a variant to the standard group that allows all of the above, and more. Groups that are configured for probe backups have:

• A time at which point probing starts
• A time at which point probing stops
• The frequency, in minutes, of the probing
• A success criteria – should all probes succeed, or is it sufficient for one probe to succeed?
• (Optionally) how many days should elapse following a successful backup before a new backup is run, regardless of whether probes have been successful or not.

This configuration area looks like the following:

Once a group has been configured as a probe group (by turning on the “Probe based group” checkbox), the standard group start time is disregarded by NetWorker, and instead the probe start time/end time as well as the interval becomes the primary governing factor in the execution of the group.

In order for the probe based backups to work, we must also then define probes, and assign those probes to one or more clients in the group. (There must be at least one client in the group with a probe associated with it.)

The probe is actually defined as a new NetWorker resource in the configuration (“NSR Probe”). Within the NetWorker configuration, this is actually very basic indeed:

The probe has a name by which it is referenced (in the above, “Basic Probe”), and the command; command options (i.e., arguments) may be included as well. The probe command, like custom backup commands, must either start with nsr or save, and must be stored in the same location as the save and nsrexecd binaries on the client. So in the above example, we’ve got a probe command written in Unix shell called “nsrprobe.sh” that will reside on one or more clients in the group.

Once the probe resource has been configured, it must be referenced in the client configuration:

In the above example, the probe resource assigned to a client is the “Basic Probe”.

At this point, NetWorker doesn’t really care what the probe runs – it could be something very basic (e.g., a check to see if all clients are connected to the network), or it could be quite complex. All NetWorker cares about is the exit code of the probe.

An exit code of 0 means that the probe is successful, indicating backup is required; an exit code of 1 means that the probe is unsuccessful and therefore a backup isn’t required.

The backup will then be executed so long as the required probes are successful (all vs any).

So that you know what is going on, logging is performed as follows:

• To indicate whether a probe ran
• To indicate if a client that required a probe command to be present didn’t have the probe command
• To indicate if probing has been run, but a backup wasn’t required
• To indicate if probing has been run, and a backup was required.

I’m presuming that there’s also logging done if a group has been configured to run after a nominated number of days even if probing hasn’t been successful, but I haven’t played around with that feature yet.

Once configured, the probe backups work quite well and with minimum fuss, running backups as necessary. Given the frequency at which they can be run, they offer considerable flexibility – if for instance, you’ve got an array that isn’t supported by NetWorker you might even find probe backups an appropriate mechanism for pseudo-integration of snapshot backups into your environment (aka PowerSnap, albeit not quite as flexible).