Conference decwet::networker

>    DMO for Oracle is not an option at this time for the database server,
>    even if it were, does it correct the above behavior ?

 yes. since it is specifically designed for database saves, it has a 
 central script that fires up (once), and can optionally shutdown the
 database, do the saves, then re-start the database. Alternatively,
 on-line backups can be done.

(from the readme for V4.2B)
          o  Pre/Post Processing for Saves -- With this NetWorker release,
             a backup command script can be specified for each client
             resource. The script can contain a set of commands to be
             executed before starting the client save, as well as a set of
             commands to execute following the save. The script must be
             stored in the same directory as the NetWorker save command,
             and its name must begin with either save or nsr. For example:

             /usr/bin/save-command.sh:
             #! /bin/sh
             PATH=/sbin:/usr/sbin:/usr/bin:
             date > /tmp/pre-save.date
             save $*
             date > /tmp/post-save.date


 What this implies to me is:
   -- this is run *instead* of save
   -- this is run each time a save *would have* run, ergo, when savegroup
	starts, and makes savefs fire up 3 "saves", it just executes your
	script instead... 3 times.
   -- this is the wrong way to save an Oracle Database, unless the database
	is in one "save" stream (1 mountpoint, usually).

    This problem also applies to the single script being used to shut down
    an application.  Since there are multiple file systems, the script is
    run once for each file system again shutting down and restarting the
    application software multiple times.
    
    Does the customer buy a DMO-like product just to shutdown and restart
    their application software only one time ?
    
    I know what the customer's answer would be.
    
    I anticipate abandoning the use of the pre/post processing script to
    manage the application software and/or Oracle database shutdown and
    restart.  I'll have to go with a cron job scheduled in synchronization
    with each Cluster Service backup to perform the above.  Not the desired
    solution, but one that is more acceptable to the customer than the
    alternative.
    
    Could you check with someone at Legato to determine if they have any
    plans to fix this behavior, or is it destined to remain a "feature" of
    the software ?
    
    Thanks.

I believe your customer is perceiving NetWorker's pre-/post- processing
 to be "pre-savegroup", and "post-savegroup" processing, instead of what
 it really is: "instead-of-save".

It sounds like this customer has an Oracle database they want to back up. It
 also sounds like this customer has an "application" like Oracle: it needs
 to be quiesced, data saved, then restarted (SAP?). This customer has a
 High Available System (ASE), and TurboLasers - this spells serious data
 work to me

I'm confused in that they do not want to use DMO to back up their Oracle
 databases - this says to me they percieve their data NOT to be worth saving
 well.

I believe this customer has only one option: use cron for the scheduling
 of the "backup" operation. When the script runs to do the "backup", it first
 quiesces applications, then executes the various NetWorker save's to backup
 the local mountpoints, then restarts the various applications. Customer
 writes/supports backup script. Don't forget to execute index saves!

With an 8400, and some good fast tape drives, this can be done in a reasonable
 timeframe.

Your customer may wish to investigate rawasm...

    If you examine the location where the pre/post processing script name
    is entered, you will notice that it is entered in the "client setup"
    window.
    
    A client is part of a save group.
    
    A save group client consists of a system with one or more individual
    mount points to be backed up according to what mount points are listed
    in the "client setup" window for that client.
    
    If an application or a database doesn't need to be shut down prior to
    running a backup, nsr runs cleanly and efficiently.
    
    The customers "perception" is reality, nothing in the documentation
    says "your pre/post processing script will run once for each mount
    point on the client".  All it says is "you can create a program that
    shuts down either a mail server or database before a NetWorker backup
    and then restarts it after the backup completes".  (NetWorker Admin
    Guide, page 50).
    
    Based upon the evidence from our testing, and your confirmation, it
    appears that nsr save group client membership for this function will
    not work and Legato may not have any intention of providing this
    option.  Thus the only option is "cron" with multiple "save" commands. 
    nsr will not provide the scheduling and automatic index backups
    inherent in the product.
    
    DMO on two AlphaServer 8400 cost is $15K per node, customer finds that
    excessive after all of the incremental licensing costs to get the
    appropriate nsr server, jukebox, cluster client, and network client
    licenses.  This was their feedback when DMO was proposed.

    Fred,
    
    Can you give us one single interesting function of the 'pre/post'
    processing you describe,?
    
    Meanwhile, we are requesting in the field, a CLIENT PRE-processing, a
    save of all filesystems, and a CLIENT POST-processing since DECnsr
    V1.0. So, this "feature" is what we need... and not this
    pseudo-pre/post processing.
    
    Regards, Manu.
    

There are lots of ways to accomplish what you wish.

While I agree  that your description of a CLIENT pre/post processing
option is really more intuitive than the current scenario, that is
not what Legato has implemented, so we must deal with what we've got.

Options:
If you have only one filesystem that really requires the pre/post processing,
you could create multiple client resources for the node, and put the one
filesystem in its own client resource.  That resource would have the pre/post
commands specified.

You could make your scripts more complicated in that they could look around
for any other "savefs" processes (ps ax | grep savefs | grep -v grep)
For the pre-command, it would only run if there were no savefs processes
running, on the theory that if savefs was running, the script had already been
run.  Similarly for post-processing: If any savefs is still running, you don't
want to start up the DB yet.

You could have the script check its args, and only take action on certain
filesystems.

So, there are options.

They are not as simple as they could be.

They are not optimum.

They require thought and work to implement correctly.

There may be situations that still cannot be covered.

But I bet that with some effort you can take care of 90% of the cases.

Kevin

    So, the  Legato's designers have worked two hours to produce a simple
    feature that will need a lot of repeated efforts everywhere in the
    world !!!
    
    That's what I called an unusefull feature. Thanks anyway, Fred, for
    your answer, but keep our request on your wish list...
    
    Manu.

Take a look at note 27.3 for a scripting "example".  It is 
borrowed from the script in note 485.

Wes

    .6> You could have the script check its args, and only take action on
    .6> certain filesystems.
    
    This sounds useful for my application; please tell me more about how to
    do this.  That is, where can I find the list of arguments passed by
    NetWorker V4.2 to a script executing as a pre-/post-processing script.
    
    Thanks!
    tl

    Hi,
    
    I too was facing that need of information and used this simple "save"
    command to learn the argument list:
    
    # cat /usr/sbin/save_my_nsr
    #!/bin/ksh
    echo $* > /tmp/nsr.$$
    
    Then I ran the savegroup, and found three files in /tmp, one for each
    of my file systems:
    
    fscr44 root # cat /tmp/nsr.*
    -s fscr44.bro.dec.com -g Default -LL -f - -m fscr44.bro.dec.com -t
    860688865 -l incr -q -W78 -N / /
    
    -s fscr44.bro.dec.com -g Default -LL -f - -m fscr44.bro.dec.com -t
    860684490 -l incr -q -W78 -N /usr /usr
    
    -s fscr44.bro.dec.com -g Default -LL -f - -m fscr44.bro.dec.com -t
    860684491 -l incr -q -W78 -N /home /home
    
    So, I had been able to know the arguments passed. To understand their
    contents, simply read the man pages of save(8).
    
    Manu.
    
    

    Thanks, Manu!
    
    tl