NetWorker Basics – Rolling your own Savesets

One of NetWorker’s power-user features is the option to name a saveset. This is most commonly used by Windows disaster recovery savesets and database savesets, but you can specify your own if you need to.

Why would you need to name savesets?

Example: I made use of this in the process I outlined for backups of Linux KVM guests. (Using the -N savesetName option in NetWorker, my script generated saveset names of hypervisor:KVM:guestName:diskName, making it easy to identify KVM backups in the mminfo output.)

Let’s have another look at how you can make use of named savesets to beef up your recovery options using Linux.

When I used to be a Unix systems administrator, our team had scripts that ran on all the hosts we were responsible for, building up all the system rebuild data we might need in an emergency – copies of the filesystem tables, disk layouts, network configuration and a myriad of other details. (At the time, these were printed and stored for several months.)

So in this example, I’m going to outline a scenario of gathering critical rebuild information for systems and sending that data to NetWorker with a saveset name that makes it very clear what it is. The process will look like this:

• A ‘critical rebuild’ script is copied onto the backup client.
• Backup client is configured with:
  • Save set of ‘All’
  • Pre-command that runs the ‘critical rebuild’ script with arguments for pool, server and expiration date.
• Policy/workflow runs:
  • Pre-command generates the critical rebuild information
  • Pre-command runs a manual backup with the required details, naming the manual saveset for easy identification
  • Backup runs.

So let’s start with the backup script:

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

RebuildDir=/critrebuild
SERVER=null
POOL=null
EXP=null
HOST=`hostname`

while getopts s:b:e: flag
do
	case "${flag}" in
		s) SERVER=${OPTARG};;
		b) POOL=${OPTARG};;
		e) EXP=${OPTARG};;
	esac
done

if [ "$SERVER" = "null" ] || [ "$POOL" = "null" ] || [ "$EXP" = "null" ]
then
	echo "Your must specify -s server -b pool -e expiration"
	exit 1
fi

if [ ! -d $RebuildDir ]
then
	echo You need to create $RebuildDir
	exit 1
else
	# Let's get a start on.
	env > $RebuildDir/run_env.txt
	rpm --query -a > $RebuildDir/rpm_query_a.txt
	fdisk -l > $RebuildDir/fdisk_l.txt
	mount > $RebuildDir/mount.txt
	cat /proc/mdstat > $RebuildDir/mdstat.txt
	ifconfig -a > $RebuildDir/ifconfig_a.txt
	netstat -ar > $RebuildDir/netstat_ar.txt
	lvm fullreport > $RebuildDir/lvm_fullreport.txt
	systemctl > $RebuildDir/systemctl_list.txt

	save -s $SERVER -b "${POOL}" -e "+${EXP} days" -N ${HOST}:CRITREBUILD $RebuildDir
fi

I’ve called the script ‘nsrcritrebuild.sh’ and symbolically linked it to /usr/bin/nsrcritrebuild.sh. (This puts it in the same directory as the NetWorker save command.) Assuming you have a directory of /critrebuild on the server, the command generates the following information:

• A list of installed packages
• Partition maps
• Mounted disks
• Details for any Linux software-RAID volumes
• Network configuration details and default routing
• Details of any Linux Volume Manager configuration
• Service information

The command should be invoked as follows:

# nsrcritrebuild.sh -s backupServer -b poolName -e expirationInDays

(If you’re wondering why I use -b poolName rather than -p poolName, it’s because NetWorker uses -b for the pool in commands like save.)

So, if I wanted to generate a critical rebuild dataset and write it to the backup server orilla using the pool Backup_01 and keep it for 31 days, I’d invoke the command as follows:

# nsrcritrebuild.sh -s orilla -b Backup_01 -e 31

Once the file is in place on the client and the /critrebuild directory created, I can set it up within NetWorker. To do that, I need to define the pre-command correctly. Using the NWUI, you can see it as follows:

Once the critical rebuild script gathers the data, it fires off a manual saveset to the backup server, naming the saveset hostname:CRITREBUILD. For my client, ‘totesrhelly’, that means if I do a mminfo query for its savesets, I get clear details of the rebuild saveset:

So, in addition to a ‘/’ saveset, and a ‘/boot’ saveset, I’ve got a totesrhelly.turbamentis.int:CRITREBUILD saveset. Now, you might argue that anyone wanting the critical-rebuild data can just recover the /critrebuild directory from the client as part of a normal filesystem recovery – and you’d be right! But you’ve now got it also easily identified as a specific saveset making it easy for anyone to see. For instance, if you’re in the NetWorker Management Console recovery interface and looking at recoverable savesets, you’ll see:

This also means you can build your recovery process, if you’d like, around the named saveset. For instance:

[root@totesrhelly /]# mminfo -s orilla -q "name=totesrhelly.turbamentis.int:CRITREBUILD,savetime>=24 hours ago"
 volume        client       date      size   level  name
Backup01       totesrhelly.turbamentis.int 15/08/21 66 KB manual totesrhelly.turbamentis.int:CRITREBUILD
[root@totesrhelly /]# mminfo -s orilla -q "name=totesrhelly.turbamentis.int:CRITREBUILD,savetime>=24 hours ago" -r ssid
2434297097
[root@totesrhelly /]# recover -s orilla -iN -d /tmp/critrebuild -S 2434297097
179040:recover: Step (1 of 11) for PID-8458: Recovery has been started on the client 'totesrhelly.turbamentis.int'.
179732:recover: Step (2 of 11) for PID-8458: Checking if the set of exclusion files is given for the recovery of the save set '2434297097' for the client 'totesrhelly.turbamentis.int'.
179737:recover: Step (3 of 11) for PID-8458: Setting the server 'orilla' for the media database calls for the recovery of the save set '2434297097' for the client 'totesrhelly.turbamentis.int'.
179742:recover: Identified a file system recovery with PID 8458 for the relocated recovery of the save set '2434297097' for the client 'totesrhelly.turbamentis.int'. Updating the total number of steps from 11 to 10.
179044:recover: Step (4 of 10) for PID-8458: Checking if the save set ID '2434297097' given for recovery is valid or not for the client 'totesrhelly.turbamentis.int'.
179045:recover: Step (5 of 10) for PID-8458: Fetching the save set record for the given save set ID '2434297097'for the client 'totesrhelly.turbamentis.int'.
179748:recover: Step (6 of 10) for PID-8458: Initializing a recovery job with the nsrjobd for the recovery of the selected file(s) for the client 'totesrhelly.turbamentis.int'.
179749:recover: Step (7 of 10) for PID-8458: Validating and setting the relocation path '/tmp/critrebuild' for the recovery of selected file(s) for the client 'totesrhelly.turbamentis.int'.
184407:recover: Step (8 of 10) for PID-8458: Validating whether the save set 'totesrhelly.turbamentis.int:CRITREBUILD' with save set ID 						'2434297097' is block based recoverable for the client 'totesrhelly.turbamentis.int'.
184408:recover: Step (9 of 10) for PID-8458: Initializing the file system save set recovery for 			the save set 'totesrhelly.turbamentis.int:CRITREBUILD' with the save set ID '2434297097' for the client 'totesrhelly.turbamentis.int'.
179722:recover: Building the recovery list of the client 'totesrhelly.turbamentis.int'.
179725:recover: Checking for the availability of the disk space on the client 'totesrhelly.turbamentis.int' for the recovery of the specified file(s).
Recovering a subset of 11 files within / into /tmp/critrebuild
179728:recover: Initializing the recovery session with the NetWorker server 'orilla' to recover the selected files.
Recover start time: Sun 15 Aug 2021 12:24:31 AEST
179718:recover: Initializing to recover multiple streams of data from the NetWorker server 'orilla'.
Requesting 1 recover session(s) from server.
179714:recover: Initializing the child threads to recover the given recovery stream from the NetWorker server 'orilla'.
179713:recover: Initializing to set up a connection to start reading the data from the recover stream.
./critrebuild/run_env.txt
./critrebuild/rpm_query_a.txt
./critrebuild/fdisk_l.txt
./critrebuild/mount.txt
./critrebuild/mdstat.txt
./critrebuild/ifconfig_a.txt
./critrebuild/netstat_ar.txt
./critrebuild/lvm_fullreport.txt
./critrebuild/systemctl_list.txt
./critrebuild/
179716:recover: Coordinating all the child recovery processes.
179717:recover: Releasing all the resources held by the recovery process.
179721:recover: All recovery streams from the NetWorker server 'orilla' are read successfully.
Received 10 matching file(s) from NSR server `orilla'
Unneeded files and directory listings are discarded and excluded from the matching file count.
Recover completion time: Sun 15 Aug 2021 12:24:33 AEST
179068:recover: Step (9 of 10) for PID-8458: The recovery completed successfully on the client 'totesrhelly.turbamentis.int'.
[root@totesrhelly /]# ls /tmp/critrebuild/
critrebuild
[root@totesrhelly /]# ls /tmp/critrebuild/critrebuild/
fdisk_l.txt     lvm_fullreport.txt  mount.txt       rpm_query_a.txt  systemctl_list.txt
ifconfig_a.txt  mdstat.txt          netstat_ar.txt  run_env.txt

Sometimes you want specific savesets to stand out. They might be for database dumps (e.g., for a database with no module), KVM backups like the example at the start, or even just ‘essential’ rebuild data. As always, the power of NetWorker is in its flexibility and adaptability to do what you need.

Rolling your own savesets? You can definitely do that.