OSSV Pre-exec (and Post-exec scripts)

NetApp Management Console:
    Protection:
     Overview (select the Policy like OSSV that you copied from a template)
   Edit
     Nodes and Connections
       Primary Data tab
section:

Backup Script

entries:
Path: c:\temp\ossv_vl112_test.bat
Run As: (left blank)

Oddly it runs this script twice, once before and once after.  Silly, they should have, like every other proper backup software, a field for "pre" and a field for "post".  Very unprofessional of NetApp to not document this better, me thinks.  Or Does it run four times?

My script echoed that the variable DP_BACKUP_STATUS is set to four different things, each of the four times the script gets ran from my DFM OSSV backup job:


DP_BACKUP_STATUS=DP_BEFORE_TRANSFERS
DP_BACKUP_STATUS=DP_AFTER_TRANSFERS
DP_BACKUP_STATUS=DP_AFTER_BACKUP_REGISTRATION
DP_BACKUP_STATUS=DP_BEFORE_PRIMARY_SNAPSHOTS

Maybe it's different when it's scheduled verses ran with "Protect Now"

New version of DFM must have changed variables as they used to expect:


DP_BACKUP_STATUS=DP_BEFORE_SNAPSHOTS

and the post will have

DP_BACKUP_STATUS=DP_AFTER_SNAPSHOTS


Ah, thanks to Marlon on the NetApp forums

• 
  

c:\DFM_scripts\ssh_ossv_hostname_pre.sh (runs the ssh to quiesce database)

c:\DFM_scripts\

Still, I don't understand what this bit from the  OSSV FAQ:  is on about though:

Q: Does the pre/post scripting capability in DFM work with OSSV?
A: Yes, you can use the DFM pre/post script ability to run commands on the host prior
to, or following an OSSV transfer.  The scripts are installed on the DFM server using
a “zip” file.  The “zip” file must contain the script (in PERL), and a XML File named
package.xml.  The package.xml file must include packaging information (version, file
name…) and the privileges needed to run the script.  Once the “zip” file has been
created, it can be imported into DFM and ran either manually or via a schedule set in
DFM.

Limitations, Limitations, Limitations:

There's only one pre-exec, post-exec script field for each backup job, even though it makes sense to backup about 10 OSSV clients per job.  Plus the backup job only runs a script on the DFM server, and obviously the OSSV clients need their databases quiesced.  That means you need to setup ssh and an ssh-key relationship between the DFM server and the OSSV client and get the DFM script launch a script remotely on the OSSV client by way of ssh--whew!

I install Cygwin for the ssh, ssh-key and a cygwin shell script to kick off the Linux script on the OSSV client from the DFM script, by way of OSSV in DFM. Again, whew!

Another limitation is that the OSSV backup environment variables only seem to track which stage of the OSSV backup job initiated it.  Nothing I can find about the name of the backup job, the OSSV client currently being backed up, or anything else I can put in my scripts to differentiate.  What we need to avoid is the same script running on all clients, needlessly and repeatedly.

CygWin & Windows Not Playing Nicely

You might use PowerShell to avoid some of this, but does powershell do ssh?  I had loads of problems if I copied my Cygwin linux shell by using windows (drag/drop in Explorer or from DOS command) as it changes the file format line endings (carriage return/line feed).  Same with if a DOS batch file is edited by VI or copied from Cygwin shell.  Ouch!   This ate much of my time.  Don't let it get you.