Conference decwet::networker

The script must be in the same directory as the save image (e.g. 
/usr/bin).

The name of the script must begin with "save" or "nsr" to 
facilitate nsr_shutdown.

Here's an example script:

	#!/bin/sh
	PATH=/sbin:/usr/sbin:/usr/bin:
	date > /tmp/presave.date		preprocessing goes here
	save $*
	date > /tmp/postsave.date		postprocessing goes here

You put the script name (name only, path is not necessary) in
the save command field in the client resource. 

NetWorker pre/post processing works as designed and documented.
The pre/post-processing script takes the place of the save binary
and runs once per filesystem or saveset being saved. 

Unfortunately, this causes complications in certain cases where
it is desirable for the pre/post processing to be done once for a
set of multiple savesets/filesystems. 

This is an application note to describe approaches to provide the
desired behavior.  Please note that these scripts and procedures
have not been tested, but reflect our best understanding of the
operation of NetWorker pre/post processing. These scripts and
procedures are provided "as is", no warranty. 

------------------------------------------------------------------------

Here are two possible approaches to pre/post-processing to 
shutdown/backup/restart application-specific data (e.g. a 
database) while avoiding the situation where a pre/post script is
run once per filesystem. The first is to use a sequence of
savegroups. The second is to do the sequencing in a more
sophisticated script. 


Sequential savegroups
---------------------

Step 1:

 Create three definitions for a single client system.

  The first has a single filesystem in its saveset and a
  preprocessing command in its "save command" field and is a member
  of group "A". 

  The second has "All" or a specific set of filesystems in its
  saveset and is a member of group "B".

  The third has a single filesystem as its saveset and a
  postprocessing command in its "save command field" and is a
  member of group "C". 

Step 2:

 Create a script that issues three savegrp commands to execute the 
 three groups in sequence.  This could be run in a cron job.

  savegrp -g A
  savegrp -g B
  savegrp -g C

This method has the advantage of allowing parallel backup during 
the execution of "savegrp -g B", thereby maximizing backup 
throughput.  However, it has the disadvantage of not using the
scheduling available in NetWorker. 

Intelligent script
------------------

Step 1:

 Create a client resource that has a single filesystem in the
 saveset, has a pre-processing script name (e.g. save.pre) in the
 save command field, and is a member of group "A".  I don't think
 it matters just what is in the saveset field, as long as it is 
 a single filesystem.  This filesystem does not necessarily need 
 to match the filesystems backed up by the script created in step 
 2.
 
Step 2:

 Create a script (see below) in /usr/bin on the client.  Make 
 sure it is executable (mode 755).

Step 3:

 Launch savegroup A, either manually or via the NetWorker 
 scheduler.

This method has the advantage of using the NetWorker scheduler, 
but does the filesystem saves serially instead of in parallel.  
It might be possible to run multiple savefs in the background,
and have the script loop until they complete, but this example 
does not include that (possibly extremely convoluted) logic.

========================================================================  

#!/bin/ksh
#
# Intelligent script example
#
#  this script was plagarized from DECWET::NETWORKER note 485.0
#
# customize the PATH to include necessary directories
#
PATH=/bin:/usr/bin:
#
while getopts s:g:L:f:m:t:l:qW:N: opt
do
   case $opt in
      s)   SERVER=$OPTARG;;
      g)   GROUP=$OPTARG;;
      f)   FILE=$OPTARG;;
      t)   TIME=$OPTARG;;
      l)   LEVEL=$OPTARG;;
      W)   WIDTH=$OPTARG;;
      N)   NAME=$OPTARG;;
      m)   ;;
      L)   ;;
      q)   ;;
      *)   echo "Error: $opt $OPTARG";;
   esac
done
#
# Execute commands here to do application-specific shutdown
#
#
# Execute savefs for those filesystems that actually need to be 
# saved.  This section can have multiple savefs commands.
# The saveset for the savefs command must either be in the 
# /etc/fstab file or in the saveset field of the client resource.
#
if [ $LEVEL = "full" ]; then
        savefs -s $SERVER -g $GROUP -l $LEVEL /work
else
        savefs -s $SERVER -g $GROUP -l $LEVEL -t $TIME /work
fi
#
# Execute commands here to restart the application
#