Create a Backup Job Definition - SQL

ECX provides application database copy management through application-consistent backup creation, cloning, and recovery. ECX copy management leverages the snapshot and replication features of the underlying storage platform to create, replicate, clone, and restore copies of Microsoft SQL Servers. Archive log destinations as well as universal destination mount points are supported. Archived logs are automatically deleted upon reaching defined retention.

ECX auto-discovers databases and enables backups only of eligible databases. To be eligible for backup, application databases must reside on supported storage platforms.

The following options are available forSQL Backup jobs:

Log Backup - The log backup feature enables continuous backup of Archive logs to a specified destination. ECX leverages archived logs to enable point-in-time recoveries of databases to facilitate RPOs.

To create a SQL Backup job definition:

1. Click the Jobs tab. Expand the Database folder, then select SQL.
2. Click New , then select Backup. The job editor opens.
3. Select a Standalone or Failover Cluster or Always On Availability Group workflow template.
4. Enter a name for your job definition and a meaningful description.
5. From the list of available sites select a provider to back up. Expand servers to view associated application databases.
6. Note: You cannot select a database if it is not eligible for protection. Hover your cursor over the database name to view the reasons the database is ineligible, such as the database files, control files, or redo log files are stored on unsupported storage.
6. Select an SLA Policy that meets your backup data criteria.
7. Click the job definition's associated Schedule Time field and select Enable Schedule to set a time to run the SLA Policy. If a schedule is not enabled, run the job on demand through the Jobs tab. Repeat as necessary to add additional SLA Policies to the job definition.
8. If configuring more than one SLA Policy in a job definition, select the Same as workflow option to trigger multiple SLA Policies to run concurrently.
9. Note: Only SLA Policies with the same RPO frequencies can be linked through the Same as workflow option. Define an RPO frequency when creating an SLA Policy.
8. To create the job definition using default options, click Create Job. The job runs as defined by your triggers, or can be run manually from the Jobs tab.
9. To edit options before creating the job definition, click Advanced. Set the job definition options.
10. Maximum Concurrent Tasks
11. Set the maximum amount of concurrent transfers between the source and the destination.
12. Skip IA Mount points and/or databases
13. Enable to skip Instant Disk Restore objects. By default, this option is enabled.
14. Maximum Concurrent Snapshots on ESX
15. Set the maximum number of concurrent snapshots on the vCenter.
16. Job-Level Scripts
17. Job-level pre-scripts and post-scripts are scripts that can be run before or after a job runs at the job-level. A script can consist of one or many commands, such as a shell script for Linux-based virtual machines or Batch and PowerShell scripts for Windows-based virtual machines.
18. In the Pre-Script and/or Post-Script section, click Select to select a previously uploaded script, or click Upload to upload a new script. Note that scripts can also be uploaded and edited through the Scripts view on the Configure tab. See Configure Scripts.
19. Once complete, the script displays in the Pre-Script or Post-Script section. Click the Parameters field at add a parameter to the script, then click Add. Note additional parameters can be added to a script by entering parameters one at a time in the field, then clicking Add. Next, click the Identity field to add or create the credentials required to run the script. Finally, click the Application Server field to define the location where the script will be injected and executed. For parameter examples, see Using State and Status Arguments in Postscripts.
20. Repeat the above procedure to add additional Pre-Scripts and Post-Scripts. For information about script return codes, see Return Code Reference.
21. Select Continue operation on script failure to continue running the job if a command in any of the scripts associated with the job fails.
22. Enable Job-level Snapshot Scripts
23. Snapshot prescripts and postscripts are scripts that can be run before or after a storage-based snapshot task runs. The snapshot prescript runs before all associated snapshots are run, while the snapshot postscript runs after all associated snapshots complete. A script can consist of one or many commands, such as a shell script for Linux-based virtual machines or Batch and PowerShell scripts for Windows-based virtual machines.
24. In the Pre-Script and/or Post-Script section, click Select to select a previously uploaded script, or click Upload to upload a new script. Note that scripts can also be uploaded and edited through the Scripts view on the Configure tab. See Configure Scripts.
25. Once complete, the script displays in the Pre-Script or Post-Script section. Click the Parameters field at add a parameter to the script, then click Add. Note additional parameters can be added to a script by entering parameters one at a time in the field, then clicking Add. Next, click the Identity field to add or create the credentials required to run the script. Finally, click the Application Server field to define the location where the script will be injected and executed. For parameter examples, see Using State and Status Arguments in Postscripts.
26. Repeat the above procedure to add additional Pre-Scripts and Post-Scripts. For information about script return codes, see Return Code Reference.
27. _SNAPSHOTS_ is an optional parameter for snapshot postscripts that displays a comma separated value string containing all of the storage-based snapshots created by the job. The format of each value is as follows: <registered provider name>:<volume name>:<snapshot name>.
28. Select Continue operation on script failure to continue running the job if a command in any of the scripts associated with the job fails.
10. Optionally, expand the Notification section to select the job notification options.
12. SMTP Server
13. From the list of available SMTP resources, select the SMTP Server to use for job status email notifications. If an SMTP server is not selected, an email is not sent.
14. Email Address
15. Enter the email addresses of the status email notifications recipients. Click Add to add it to the list.
11. To edit Log Backup options before creating the job definition, click Log Backup. If Backup Logs is selected, ECX backs up database logs then protects the underlying disks. Select resources in the Select resource(s) to add archive log destination field. Database logs are backed up to the directory entered in the Use Universal Destination Mount Point field, or in the Mount Point field after resources are selected. The destination must already exist and must reside on storage from a supported vendor.
12. Note: Always On job definitions must specify the log destination as a path in the following format: \\server\share\optional_subfolder. The server can be either an IP address or hostname that is resolvable from the ECX appliance.
13. If multiple databases are selected for backup, then each of the servers hosting the databases must have their Destination Mount Points set individually. For example, if two databases, one from Server A and one from Server B, are added to the same job definition, and a single mount point named /logbackup is defined in the job definition, then you must create separate disks for each server and mount them both to /logbackup on the individual servers.
14. ECX automatically truncates post log backups of databases that it backs up. If database logs are not backed up with ECX, logs are not truncated by ECX and must be managed separately.
15. To disable a log backup schedule on the SQL server, edit the associated SQL Backup job definition and deselect the checkbox next to the database on which you wish to disable the log backup schedule in the Select resource(s) for log backup destination field, then save and re-run the job. Note that the job definition must be saved and re-run for the disablement to take effect.
16. When SQL backup job completes with log backups enabled, all transaction logs up to the point of the job completing are purged from the SQL server. Note that log purging will only occur if the SQL Backup job completes successfully. If log backups are disabled during a re-run of the job, log purging will not occur.
17. If a source database is overwritten, all old transaction logs up to that point are placed in a “condense” directory once the restoration of the original database completes. When the next run of the SQL Backup job completes, the contents of the condense folder is removed.
12. When you are satisfied that the job-specific information is correct, click Create Job. The job runs as defined by your schedule, or can be run manually from the Jobs tab.

 

---

Catalogic ECX™ 2.7.3

© 2018 Catalogic Software, Inc. | All rights reserved. | 9/18/2018

MySupport | Knowledge Base | Trademarks | info@catalogicsoftware.com