Basics – Directed Recoveries

Periodically people who are new to NetWorker will lament that it doesn’t support “push” recoveries. That is, a recovery run on the server that pushes data out to the client.

This supposed lack of support comes down to NetWorker using an alternate nomenclature for the term, and making it more generic. In NetWorker, you have two distinct styles of recovery:

• A local recovery (run on the machine where the backup was taken)
• A directed recovery

In actual fact, a local recovery is effectively just a “special case” of a directed recovery. So let’s look at what a directed recovery involves.

For directed recoveries, we need to think of 3 different types of client. These are:

• The source client – the host from where the original backup was taken.
• The destination client – the host to where the recovery will be written.
• The control client – the host that runs the recovery.

You can hopefully see from the above how a local recovery is just a special case of a directed recovery – it’s just a directed recovery where the source, destination and control clients are the original source client.

(Similarly, a push recovery, in terms of workgroup backup products, is one where the control client is the backup server, and the source/destination clients are different to the backup server.)

As you can imagine, in order to perform directed recoveries, you need some special permissions; this prevents any user on any host from recovering data from another machine. There are two ways that one can have permission to do directed recoveries:

• Any member of the NetWorker administrator user group can conduct a directed recovery without any additional setup.
• Users configured in the ‘Remote Access’ properties for a client can access that client either as a source or destination client in a directed recovery.

As an example, let’s consider a 2-way directed recovery, where our destination and control clients are the same host, and the source client is another machine. Our destination/control client is called ‘cyclops’, and our source client is called ‘medusa’.

In this case, without running as a member of the NetWorker administrator group, we need to configure the ‘Remote Access’ field on medusa to permit the appropriate user on cyclops to have access to its data. Within the client properties for ‘medusa’, the remote access field resembles the following:

Note that users can be specified either in the old method (as per the above), or in the newer standard. (The above user specification, in the new standard, would be “user=preston,host=cyclops”).

Once this has been setup, the recovery program can be run on the client cyclops. You can always see whether permissions are working for directed recoveries right from the outset of a recovery, as the recovery program will list, in the “Select Source” dialog, all hosts that the client has permission to access data from:

Thus, in order start a directed recovery once permissions are setup, all you have to do is change the source client from the current host (cyclops) to the client you want to recover from (in this case, medusa), and you’re already well progressed down the directed recovery path.

Having selected the client we want to recover from, we can then select the client we want to recover to:

With that done, we can now browse the source client for files we want to recover, selecting them the same way we would select files from a local client:

Note that at the bottom of the window we can see in the status area a statement indicating that we’re recovering from medusa to cyclops.

Now, once you’ve selected files to recover, remember that in directed recoveries it’s usually a very, very good idea to change where you want to recover to on the destination – often you don’t want it to be the same as the original backup location on the source. To do this of course, use the “Recover Options” item in the “Options” menu:

With that done, you can start the recovery. Here’s the recovery details from our example case:

There you go, that’s all there is to it; as you can see, a directed recovery is really no more difficult than a regular recovery in NetWorker.

To close off though, here’s some tips:

1. Cross platform directed recoveries are no longer supported in NetWorker (they were, for a time, in NetWorker 6, but posed too much of a security issue). While the control client may be of a different platform, you must ensure that your source and destination clients are of the same platform type – Unix/Linux to Unix/Linux, and Windows to Windows.
2. All 3 of the source, destination and control clients must be defined clients within NetWorker. While previously this was not required, in more recent versions of NetWorker it has been introduced to increase the security of directed recoveries.
3. Watch out for special savesets, particularly with Windows. Don’t try, for instance, to run a directed recovery from the backup server of a clients’ SYSTEM FILES: saveset back out to the client. I believe these days NetWorker warns you, but in previous cases it would overwrite the control clients’ SYSTEM FILES: saveset with the one being recovered, since these special savesets didn’t support directed recovery.
4. Be sure to decide in advance, for directed recoveries, how to handle duplicate files (i.e., files already existing on the target) when the control and target clients aren’t the same host – NetWorker won’t allow interactive prompting for duplicate files when the control and target clients are different.
5. In Unix environments, directed recoveries are a great way of getting out of particularly sticky situations – e.g., someone accidentally clobbering the /etc/passwd or /etc/shadow file. Push the recovery back out to the client in question to restore access.
6. When using directed recoveries for binaries, make sure the source and destination clients are the same operating system type and bitness.