- This option is not available for Oracle Unix iDataAgents.
- The Image Level iDataAgent does not support user impersonation for volume level restores.
Pre/Post Processes Considerations
Data Protection and Recovery jobs comprise one or more sequential phases. Each phase must complete before its successor can begin. These phases can be used to trigger operations outside of the data protection or recovery process. For example, copying files from a share to your local disk and then deleting the files after the data protection operation has run, running a database integrity check prior to backing up your databases/workspaces, or deleting files to make room for the data to be restored.
For each batch file/shell script that is associated with one of a job's Pre/Post processing phases, the system examines the return code. A return code of zero indicates a successful run and the job continues. When a non-zero return code is encountered, the job will wait and restart that phase.
For jobs that are run with Pre/Post Process commands, the CommServe sends additional arguments, appending them to your Pre/Post commands. See Commands and Arguments for more information.
Pre/Post Processes for Data Protection are configured in the Subclient Properties (Pre/Post Process) tab, which allows you to use the job phases as triggers to start processes. For more information on which agents support Pre/Post Processes for Data Protection, check the configuration section for your agent.
Pre/Post Processes for Data Recovery Operations are configured in the Advanced Restore Options dialog box, which allows you to use the restore phases as triggers to start processes. For more information on which agents support Pre/Post Processes for Restore, see Restore Options - Support.
Pre/Post Processes for Recovery Points for ContinuousDataReplicator are configured in the Pre/Post tab of the Replication Set Properties; this allows you to execute processes either before or after the Recovery Point is created. See Create a Replication Set.
Under normal circumstances, a specified post process command is executed only upon the successful completion of the respective job phase, or when the job is killed or fails. However, you may still want to run a post process even if the job phase did not complete successfully, especially if your post process is used to bring a database online or release a snapshot.
The system provides you with an option to run post data protection or restore processes when the respective phase of the job is interrupted, suspended or fails in addition to successful, killed or failed jobs. For data protection operations, the Run Post <phase> Process for All Attempts option can be selected in the Subclient Properties (Pre/Post Process) tab. For restores, the Run PostRestore Process for All Attempts option is selected on the Pre/Post Processes for Restore dialog box.
When using pre/post commands on a Windows client computer to execute processes before and/or after the operation, you must designate the Local System Account or, for added security, assign a Windows User Account as having permission to run these commands. This option does not apply to subclients on Unix platforms.
User Impersonation requires that the affected user have write permissions to the product installation folders; otherwise, the User Impersonation account may not take effect. This is especially true if the associated computer is not part of a domain and if the user is not a domain user.
The User Impersonation designated for data protection operations is independent of the User Impersonation account you can assign for recovery operations.
|
|
|
See the following as appropriate for a step-by-step procedure:
When entering a Pre/Post command, specify the full file path. For example, C:\users\profile.bat for Windows or /etc/pre.sh for Unix. Do not use relative paths.
The system allows the use of spaces in commands and arguments provided they begin with an opening quotation mark and end with a closing quotation mark.
| Examples: | "c:\program files\test file\pre.bat" "c:\program files\test file\pre.bat" "test set" "c:\program files\test file\pre.bat" "arg one" "arg two" "/root/space cmd.sh" "/root/space cmd.sh" "one arg" "/root/space cmd.sh" two args |
For Windows, a Pre/Post command that is a batch file needs to be run using the command interpreter cmd.exe /C.
| Example: | c:\winnt\system32\cmd.exe /C ""c:\program files\pre.bat" "test set"" |
In addition to the specified Pre/Post commands, the CommServe sends additional arguments and appends them to the Pre/Post commands (if any); this can provide a useful means of control based on the type of job being run. You can use the value of the argument(s) within Pre/Post batch files or scripts to run specific operations based on the level, number of attempts, or status of the job (e.g., for Unix, by issuing an echo command or including a case statement within the appropriate script). These arguments include the following:
| --bkplevel <level> | where "level" can be |
| '1' = |
iDataAgents:
Full Backup DataArchiver Agents: Archive level that creates a new index |
| '2' = |
iDataAgents:
Incremental Backup DataArchiver Agents: Archive level that appends the existing index |
| '4' = |
iDataAgents:
Differential Backup DB2 iDataAgent: Delta Backup |
| No argument is passed for Synthetic Full Backups because the client is not involved with this backup type. | |
| '1024' = | Selective Offline Full Backup |
| '2048' = | Snapshot QR Volume |
| '4096' = | Create QR Volume |
| '8192' = | Update QR Volume |
| '32768' = | Selective Online Full Backup |
|
|
If your agent's data protection rules allow backup levels to be changed "on-the-fly", the Job Manager will submit the new backup level to the next Pre/Post command that occurs in the job. This could result in the backup level varying among Pre/Post commands for a given job. |
| -attempt <n> | where "n" is the number of attempts (will always be at least one) for a given Pre/Post process (not the phase) within a given job. This will be passed to all Pre and Post processes. |
|
|
Example: If you want to run a Pre/Post process only the first time the job is attempted, you can test the value of the "attempt" argument received by the Pre/Post process and take the appropriate action. |
| -status <n> | where "n" is one of the following values indicating the status of the phase that preceded a given Post process within a given job: (This will be passed to all Post processes, but not to Pre processes.) |
| '1' = | The phase succeeded |
| '2' = | The phase failed |
| '3' = | The phase succeeded with one or more errors |
| '4' = | The job was killed while executing that phase |
|
|
Example: If you want to run a Post process (e.g., PostBackup) only if the preceding phase (e.g., Backup) was a success, you can test the value of the "status" argument received by the Post process and take the appropriate action. |
| -job <n>; | where "n" is the Job ID number received from Job Manager. |
| -vm <virtualmachine> | The vm argument is used by Pre/Post commands internally. The vm argument does not apply for Unix agents. |
The arguments can be tested in a sample batch file using the PrePostCmdExample command line utility in the Resource Pack. This utility lists the different backup level values that are passed to the batch file and shows how to parse the command line parameters in a batch file. Use this utility to prototype the actual pre-post command batch file.
Consider the following when adding a Pre/Post Process to a job:
A save a job as script file can run as a pre/post process only if you include the absolute path of the associated input file in the script file. Therefore, be sure to include this path in the script file.
See Save As Script for more information.
Pre/Post process commands are used for the PreScan and PostScan phases when performing Oracle BLI backups. Two sample scripts are provided in the e <software installation path>\Base folder to serve as a template that you customize for your environment:
PreOraScan.bat - used to quiesce the Oracle instance.
PostOraScan.bat - used to unquiesce the Oracle instance and take an archive log volume snapshot of the Oracle instance.
Copy and rename the sample files before customizing them for a given Oracle instance (e.g., copy PreOraScan.bat to PreOraScan_<instancename>.bat and copy PostOraScan.bat to PostOraScan_<instancename>.bat, thus, to quiesce the oltpdb Oracle instance, copy the PreOraScan.bat to PreOraScan_oltpdb.bat and copy PostOraScan.bat to PostOraScan_oltpdb.bat.)
The provided scripts are samples only and must be customized to quiesce and unquiesce the Oracle instances that you are backing up. Edit the scripts to have the following variables set properly: ORACLE_HOME, ORACLE_SID, GALAXY_BASE, SQL_CONNECT, GALAXY_SQL_TEMP_DIR.
The PreOraScan.bat and PostOraScan.bat files are commented with instructions about setting each of these values for your environment.
For non-CXBF Image Level or Image Level ProxyHost subclients on Unix, you must provide the appropriate PreScan scripts to run the snap and mount operations. You must also provide the appropriate PostBackup scripts to run the un-mount and un-snap operations. For a list of supported snapshots, see Snapshot Engines - Support.
The following is an example of a PreScan script:
#!/bin/sh
lvcreate --size 100m --snapshot --name TestLv01_snap /dev/testvg/TestLv01
mount /dev/testvg/TestLv01_snap /vol1
lvcreate --size 100m --snapshot --name TestLv02_snap /dev/testvg/TestLv02
mount /dev/testvg/TestLv02_snap /vol2
exit 0
The following is an example of a PostBackup script:
#!/bin/sh
umount /vol1
lvremove -f /dev/testvg/TestLv01_snap
umount /vol2
lvremove -f /dev/testvg/TestLv02_snap
exit 0
See Configure a Subclient for Pre/Post Processing of Data Protection/Archive Operations for a step-by-step procedure.
The PreScan and PostScan phases are not used by Transaction Logs.
For NAS, the Pre/Post process commands are executed on the MediaAgent as specified in the default data path of the associated Storage Policy that is assigned to the subclient. If this Storage Policy assignment changes, or if the active drive pool for that Storage Policy changes, the machine where the Pre/Post commands will be executed will also change. Ensure that the Pre/Post commands that you have specified are available on the MediaAgent where they will be executed.
NetWare will not wait for pre/post processing commands to complete unless a command delay is configured for that process. If a command delay is not configured, NetWare will immediately move to the next phase of the backup job after launching the command. Also, command failure will not prevent the next phase of the backup job. See Configuring a Command Delay for a Pre/Post Process for more information.
Consider the following for this iDataAgent:
In most cases, the QR Agent will create your QR volumes seamlessly. However,
the QR Agent must be able to lock the destination volume to complete a
successful copy or incremental update. If there are other applications, services,
or users preventing the QR Agent from locking the destination volume, you must
create pre/post binding scripts to ensure the QR Agent can lock that volume.
Pre/Post binding script files are not provided with the QR Agent; they are user-created. In most cases, it is not necessary to create pre/post binding scripts.
They should only be created by administrators to address potential errors
that may be encountered when creating QR Volumes.
Pre/Post scripts operate at the subclient level, and they must be manually created
and placed in the ../<software installation path>/Base folder on the client
controlling the destination volume. See
Configure Pre/Post Binding Scripts for the Quick Recovery Agent.
Even if the Local System Account is selected as the account to run the Pre/Post processes, the account that actually will be used is the SharePoint Administrator Account for the site in which the SharePoint Server resides. This account was configured during installation and can be changed in Agent Properties.
See SharePoint Agents in User Accounts and Passwords for more information on this account.
A save a job as script file can run as a pre/post process only if you include the absolute path of the associated input file in the script file. Therefore, be sure to include this path in the script file.
See Save As Script for more information.
#!/bin/bash
base='basename $0'
echo $0, 'date' > /extra/aah/RESULTS/$base.out
exit 0