Advanced Configuration - SQL Server iDataAgent

Table of Contents

Understanding the CommCell Console

The Microsoft SQL Server iDataAgent uses the following logical entities to manage backup and restore operations from the CommCell Console.

Agent

Facilitates SQL instance discovery.

Instance

Defines the SQL Server instance to be backed up.

Subclient

Defines the SQL databases to be backed up.

 

Creating User-Defined Subclients

By default, all databases within each SQL Server instance are automatically assigned to the default subclient. This subclient backs up the entire instance.

If you want to divide your backups into smaller groups, you can do so by creating user-defined subclients as described in the following sections.

For Databases

If you want to back up groups of specific databases, you can do so by creating a user-defined subclient containing any number of databases that exist within the instance. This is useful if you want to back up a subset of databases at certain times or with a particular frequency.

When you create a user-defined subclient, the contents of the user-defined subclient will be excluded from the Default Subclient.

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the Instance, point to New Subclient, and then click Database.
  3. In the Subclient Name box, type a name.
  4. Click the Storage Device tab.
  5. From the Data Storage Policy sub-tab, click a storage policy name from the Storage Policy list.
  6. From the Log Storage Policy sub-tab, click a storage policy name from the Storage Policy list.
  7. Click the Content tab and then click Configure.
  8. Click Discover.
  9. From the Subclient Name list in the Database Configuration window, select the name of this subclient for each database you want to include.
  10. Click OK to save the content.
  11. Click OK.

For Files and FileGroups

In many cases, large databases may contain portions of data that require more frequent backups than others. For example, tables consisting of records entered on a daily basis may require nightly backups, whereas tables consisting of records entered on a quarterly basis may require only monthly backups. You can group such elements together by creating a user-defined subclient for files or filegroups.

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the Instance, point to New Subclient, and then click Files and Filegroups.
  3. In the Subclient Name box, type a name.
  4. Click the Storage Device tab.
  5. From the Data Storage Policy sub-tab, click a storage policy name in the Storage Policy list.
  6. From the Log Storage Policy sub-tab, click a storage policy name in the Storage Policy list.
  7. Click the Content tab and then click Configure.
  8. From the File/FileGroup Configuration window, select the database containing the files or filegroups you want to back up from the Database list.
  9. Click Discover.
  10. Expand the nodes in the Name list.
  11. In the Subclient Name list, select the name of this subclient for each file or filegroup you want to include.
  12. Click OK to save the content.
  13. Click OK.

    It is recommended that filegroups be configured rather than individual files. Filegroups require less overall maintenance and reduce the need to manually add or remove individual files to the subclient.

Managing Instances

Manually Discovering New Instances

By default, new instances added to the SQL Server are automatically discovered if the option to do so was enabled during the SQL Server iDataAgent installation. If this option was not enabled during installation, you can discover new instances at any time as follows:

  1. Ensure you have a user account with sufficient privileges to create a new instance. Refer to the Configuring User Accounts for Backups section on this page for information on required account privileges.
  2. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server.
  3. Right-click SQL Server and click New SQL Server.
  4. In the Instance Name list, select the name of the SQL Server instance you want to assign to this instance.
  5. Click the Accounts tab and in the Server Type area, check the Override higher levels settings check box.
  6. Click OK.

Enable Automatic Discovery

If you enable automatic discovery new SQL Server instances will be discovered as follows:

  • Every 24 hours.
  • Whenever the Communications Service (GxCVD) is restarted (such as after a computer reboot).

This capability ensures all instances are accounted for on a daily basis for backups.

If you want to enable or disable automatic instance discovery, you can do so as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server.
  2. Right-click SQL Server and click Properties.
  3. Check or clear the Auto discover instances check box.
  4. Click OK.

Setting the Discovery Frequency

If you want instances to be automatically discovered on a more or less frequent basis, you can do so as follows:

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> and then click Properties.
  3. Click the Advanced button and select Additional Settings tab.
  4. Click Add.
  5. Click Lookup besides the Name field.
  6. In the Lookup Additional Settings dialog box search for the key by performing one of the following:
  7. Click OK.
  8. All other fields in the Add Additional Settings on Windows Client dialog box get automatically populated.
  9. In the Value field, type the number of minutes to discover instances.

    For example, to discover instances every two hours, type 120.

  10. Click OK.

Enabling Automatic Database Discovery

By default, new databases created on the SQL Server are automatically discovered and assigned to the default subclient during a backup operation. You can disable this functionality as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Enable or clear the Disable Auto-Discovery check box.
  4. Click OK.

Manually Discovering Databases

If automatic discovery of databases is disabled, you can manually add databases to a subclient as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the Content tab.
  4. Click Configure.
  5. Click Discover.
  6. In the Subclient Name list, select the subclient to which the database you want to add should be assigned.
  7. Click OK to save your settings.
  8. Click OK.

Automatically Discovering Databases in Offline States

By default, databases in the following states are not automatically discovered:

  • Standby
  • Restoring
  • Suspect (will also include the Standby state)
  • Shutdown (will also include the Suspect and Standby states)
  • Offline

You can configure automatic discovery of offline databases for one or all clients as described below.

For All Clients

  1. Log on to the CommServe computer.
  2. From the command prompt, navigate to <software_installation_path>\base.
  3. Run the following command:

    In this example, databases in the suspect, shutdown, and standby states will be automatically discovered.

For Individual Clients

Configuring this option will override the configuration at the CommServe level described in the For All Clients section above.

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> and then click Properties.
  3. Click the Advanced button and select Additional Settings tab.
  4. Click Add.
  5. Click Lookup besides the Name field.
  6. In the Lookup Additional Settings dialog box search for the key by performing one of the following:
  7. Click OK.
  8. All other fields in the Add Additional Settings on Windows Client dialog box get automatically populated.
  9. In the Value field, type the databases state or states that will be discovered. If entering more than one state, separate each with a semicolon.

    For example, to discover databases in the Suspect, Shutdown, and Standby states, enter the following:

    suspect;shutdown;standby

  10. Click OK.

Excluding Databases from Backups

In some cases, it may be necessary to exclude certain databases from backups for a period of time. For example, you may have configured an entire SQL Server to back up using a particular schedule, but do not require all databases to be backed up according to that schedule. You can exclude such subclients from backups by selecting the Do Not Backup option. Use the following steps to exclude subclients from backups:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the database subclient and click Properties.
  3. Click the Content tab.
  4. Click Configure.
  5. Click Discover.
  6. In the Subclient Name list, select the subclient to which the database you want to add should be assigned.
  7. Click OK to save your settings.
  8. Click OK.

Ignoring or Skipping Read Only Databases during Transaction Log Backups

You can use additional settings to set bSkipTLForReadOnlyDB to ignore Read Only Databases to be backed up during a transaction log backup.

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> and then click Properties.
  3. Click the Advanced button and select Additional Settings tab.
  4. Click Add.
  5. Click Lookup besides the Name field.
  6. In the Lookup Additional Settings dialog box search for the key by performing one of the following:

    A global parameter SkipTLForReadOnlyDB can be used to configure all SQL clients. You can use the Command Line Interface to do so, see qcommand execscript for details.

  7. In the Value field, type 1.
  8. Click OK.

Deleting Databases from SQL Server

You can delete discovered databases from a default subclient. When databases that are automatically discovered are deleted from the SQL Server, the databases are removed from the default subclient during the next backup operation.

Databases that are automatically or manually added to the user-defined subclient are not automatically removed when they are deleted from the SQL Server. Instead, the next backup operation skips the deleted database. Also, backup operations on a subclient fail if the database is in the offline state on the SQL Server.

From a Default Subclient

Databases that were manually added to the default subclient are not automatically removed if they are deleted from the SQL Server. You must manually remove them from the subclient so that the next backup job is completed without any errors.

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the Content tab.
  4. Select the database you want to delete from the Database List.
  5. Click Delete.
  6. Click OK.

Note: You can also delete the manually discovered databases from the default subclients by creating the additional setting nIgnoreNonExistentDB. This method is similar to deleting the databases from the user-defined subclients.

From a User-Defined Subclient

Create the additional setting nIgnoreNonExistentDB and set its value as 1. When the backup jobs on the subclient that contains deleted databases are finished, the deleted databases are removed from the user-defined subclients. You can also use this additional setting to remove manually discovered, deleted databases from the default subclient. Databases that are in the offline state are skipped during backup.

You can also configure the subclient to automatically remove deleted databases as follows:

  1. In the CommCell Browser, expand Client Computers.
  2. Right-click the client, and then click Properties.
  3. In the Client Properties dialog box, click Advanced.
  4. In the Advanced Client Properties dialog box, on the Additional Settings tab, click Add.
  5. In the Add Additional Settings dialog box, set up the additional setting:
    1. In the Name box, type nIgnoreNonExistentDB.
    2. In the Category list, select MSSQLAgent.
    3. In the Type list, select STRING.
    4. In the Value box, type 1.
    5. Click OK.
  6. Click OK to close the Advanced Client Properties dialog box.
  7. Click OK to close the Client Properties dialog box.

Note: You can also configure all SQL clients to delete databases by using the command line interface. Run the qcommand execscript command with the IgnoreNonExistentDB parameter.

Selecting Backup Types for On-Demand Backups and Executing the Backups

You can modify the argument file (xml file) to perform different types of backups such as Full, Transaction Log and Differential backups, you can do so as follows:

  1. The xml file will have the backup type parameter available, for example the Full backup parameter of the xml file (SQLbackup.bat):

    <backupLevel>FULL</backupLevel>

    can be changed to

    <backupLevel>INCREMENTAL<backupLevel>

    for Transaction Log backup

    or to

    <backupLevel>DIFFERENTIAL<backupLevel>

    for Differential backup.

  2. Execute the batch file using the following query in SQL Management Studio:

    exec master..xp_cmdshell 'C:\SQLbackup.bat'

Setting Up Backup Conversion Rules

Backup conversion rules provide the facility to convert certain types of backups to another backup type under specific circumstances. This functionality helps ensure all SQL data is protected regardless of circumstances that may cause a failure.

For Default and Database Subclients

By default, database backups are converted as depicted in the following table.

Backup Conversion Type Conditions for Conversion Benefit of Conversion
Log Backup to Differential Backup The database recovery model is set to Simple. Because the Simple recovery model does not support log backups, converting to a differential backup ensures both logs and data are properly backed up. This, in turn, provides the facility to restore the logs.
Differential Backup to Full Backup A full backups was performed using other software. For first-time users, starting with a full backup provides complete protection as a baseline for future backups.
All Backups to Full Backups
  • You are running your first backup using this software.
  • Database creation time is newer than the last backup performed using this software.
  • The last restore performed was a Point-in-Time or Transaction Mark restore.
  • Any system database (i.e., master, model, msdb) was restored after the last backup.
Converting to full backups in these scenarios ensure you have complete protection of the latest state of each database. In the case of system databases, a full backup will ensure the restored database is backed up at the most recent point-in-time.

If you want to disable this functionality, you can do so using the steps below.

Keep in mind that disabling this option for one scenario disables the option for all scenarios listed above. As such, it is recommended this option remain enabled to ensure no data is unintentionally left out of a backup.

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the Backup Rules tab.
  4. Disable the Convert check box.
  5. Click OK.

Conversion Options for Log Backups

By default, log backups performed outside of the system (for example, using SQL Enterprise Manager) are automatically converted to full backups. This provides a baseline for future backups.

If necessary, you can preserve the log backups performed by previous software packages as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the Backup Rules tab.
  4. Enable the Convert check box.
  5. Select the Do Not Convert Log Backups to Full if a Log Backup Was Performed Using Other Software option.
  6. Click the SQL Settings tab.
  7. Select the Disable Log Consistency Check check box.
  8. Click OK.

Disabling Conversion of Transaction Log Backups to Differential

If the Convert checkbox is selected, all backups convert as specified in the rules of the dialog box. However, if you want to skip the conversion of Transaction Log Backups to differential backups for subclients with databases set to simple recovery model, you can do so by configuring additional settings to set bSkipTLForSimpleRecoveryModelDB.

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> and then click Properties.
  3. Click the Advanced button and select Additional Settings tab.
  4. Click Add.
  5. Click Lookup besides the Name field.
  6. In the Lookup Additional Settings dialog box search for the key by performing one of the following:
  7. In the Value field, type 1.
  8. Click OK.

Conversion Options for Files and FileGroups in a Database

By default, if files or file groups have been added to a database since the previous backup, the next backup will automatically be converted to a full backup. This ensures the new files or filegroups are given proper protection as quickly as possible, regardless of the type of backup originally intended.

If you do not require this functionality, you can disable it as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the Backup Rules tab.
  4. Enable the Convert check box.
  5. Clear the File or Filegroups are added check box.
  6. Click OK.

For File or FileGroup Subclients

By default, all backups performed on File or Filegroup subclients are automatically converted to full backups as depicted in the following table:

Backup Conversion Type Conditions for Conversion Benefit of Conversion
All Backups to Full Backups
  • First backup using this software.
  • Database creation time is newer than the last backup performed using this software.
  • Subclient content is modified.
Converting to full backups in these scenarios ensure you have complete protection of the latest state of each file/filegroup.

If you do not want backups to convert to full backups under these circumstances, you can disable this option by following the steps below.

Keep in mind that disabling this option for one scenario disables the option for all scenarios listed above. As such, it is recommended this option remain enabled to ensure no data is unintentionally left out of a backup.

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the file or filegroup subclient and click Properties.
  3. Click the Backup Rules tab.
  4. Clear the Convert check box.
  5. Click OK.

Enhancing Performance during Backups

Several options are available for enhancing backup performance reducing network bandwidth overhead. These options include:

  • Limiting the maximum size of data blocks used during backups.
  • Specifying the number of buffers used to reserve bandwidth for data transfer.
  • Limiting the maximum amount of data to be transferred at a time during backups.

You can configure these options as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Properties.
  3. Click the SQL Settings tab.
  4. Enter the desired number of data blocks to use during backups in the Block Size box.

    All data transfers are in integral multiples of this value. The default value being 65,536 bytes (i.e., 64KB) or any value between 512 bytes and 65,536 bytes (inclusive) may be entered.

  5. Enter the desired number of buffers to use during data transfer in the Buffer Count box.

    The default value is 20.

  6. Enter the maximum number of bytes to transfer at a time in the Maximum Transfer Size box.

    The default value (in bytes) is 2,097,152.

    • Make sure the Application Read Size value on the Data Transfer Option tab has the same or greater value as the Maximum Transfer Size; otherwise, backups may fail.
    • The default value being 2,097,152 bytes (i.e., 2048KB) or enter a value in multiples of 64 KB ranging between 65,536 bytes and 4,194,304 bytes (i.e., 4 MB).

  7. Click OK.

AlwaysOn MSSQL Availability Groups

Simpana data protection for AlwaysOn Availability Groups provides a high-availability and disaster-recovery solution for SQL Server 2012 and SQL Server 2014 databases. AlwaysOn Availability Groups support a failover environment for a set of user databases, known as availability databases, that fail over together. An MSSQL Availability Group client protects availability databases based upon the backup preferences and backup priorities configured for the availability group, and provides a single entry point for initiating backups and restores.

After installing the SQL iDataAgent on all the physical nodes of an AlwaysOn cluster, create a new MSSQL Availability Group (AG) client. An MSSQL AG client is a logical grouping of one or more availability groups. You can create separate MSSQL AG clients for each availability group or use the same MSSQL AG client for all the availability groups, even if these availability groups belong to different clusters.

This feature is not supported for SnapProtect and Volume Shadow Copy Service (VSS).

For steps on creating the MSSQL AG client, see Creating MSSQL Availability Group Client.

For steps on adding an availability group to an existing MSSQL AG client, see Adding Availability Group to an Existing MSSQL Availability Group Client.

Same impersonation account should be used for all the SQL instances of an MSSQL AG client. For more information, see User Account and Password Management - Microsoft SQL Server iDataAgent.

Configuring Default Subclients on an MSSQL Availability Group Client

After creating an MSSQL Availability Group client, you can configure the default subclient or create a new subclient the same way that you create a regular SQL subclient.

For steps to configure the default subclient, see Configuration - SQL Server iDataAgent.

For steps to create a new subclient, see Creating User-Defined Subclients.

Running Backups on an MSSQL Availability Group Client

You can either use the default subclient or create a new subclient to run backups on availability group clients. You can run the backup operation the same way that you run backups on a regular SQL subclient.

When you start the backup, the proxy client runs the master process, and then retrieves the backup information from the availability group. Depending on the type of backup, backup preference, and the backup priority, the backup job runs on either the primary replica or one of the secondary replicas. All activities of the master process will be logged and available for review in the SQLBackupmaster.log file on proxy client.

Note the following two points before setting up the backup preferences and priorities:

  • Full and Differential backups always run on the primary replica.
  • Full Copy Only and Transaction Log backups either run on the primary replica, if the primary replica is set as the preferred replica for running backups, or on the secondary replica with the highest backup priority.

If the preferred replica for running a backup job is not available, then the backup runs on the next available replica. The backup operation fails if the CVD services on the selected replica are down.

During a backup operation, database is backed up twice, both from the Availability Group client and from the physical nodes with SQL agent installed. You cannot stop database backup from the physical nodes as all the AG clients might not be configured. If all the AG clients are configured, you can prevent two times backup of database by setting the value of global parameter BackupAGDBsViaActualInstance to zero. Use the Command Line Interface to set the value of global parameter, see qcommand execscript for details.

For steps to run a backup operation, see Backup - SQL Server iDataAgent.

Restoring Availability Databases

An availability group instance protects a set of user databases, known as availability databases. By default, a database is restored to the same location where it was backed up, and the existing database files are overwritten. Because restores are not allowed on any replica of availability groups, before running the restore, remove the database from the availability group.

Even if you performed the backup on a different replica, run the browse and restore operations from the availability group instance, because all backups are registered against the availability group instance. Run the restore to an instance installed with the same SQL version or later than the instance where the backup ran.

For steps to run a restore operation, see Restore - SQL Server iDataAgent.

Configuring Backup and Restore Checksum Validation

You can configure to run checksum validation to verify SQL databases during backups and restores. This configuration allows to calculate the checksum on a page during backup as it writes to a disk and then calculates the checksum on the page during restore as it reads from disk. Mismatched values returned during the validation are indicative of corrupted database or page corruption on disk.

Follow the steps given below to configure checksum validation for backups:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Backup.
  3. Select a Backup Type and click Immediate.
  4. Click the Advanced button and select the Checksum checkbox.
  5. Click OK.
  6. Click OK to start the backup.

Follow the steps given below to configure checksum validation for restores:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server.
  2. Right-click the <Instance> and then click All Tasks | Restore.
  3. Click OK.
  1. In the right pane of the Browse window, select a database you want to restore and click Recover All Selected.
  2. Click the Advanced button.
  3. Click the Options tab and select the Checksum checkbox.
  4. Click OK.
  5. Click OK to start the restore.

    Restores will fail if checksum option is selected during restore and its corresponding backup was done without this option.

Ignoring Backup and Restore Errors

By default, backups and restores use the Stop on Error parameter, which means that a backup or a restore will fail if SQL Server encounters an error during a backup or restore. However there might be a scenario where the backup is corrupted. In such cases, you can configure for SQL server to ignore the errors encountered during backups and restores and continue till the job completes.

Follow the steps given below to configure for backups:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the default subclient and click Backup.
  3. Select a Backup Type and click Immediate.
  4. Click the Advanced button and select the Continue After Error checkbox.
  5. Click OK.
  6. Click OK to start the backup.

Follow the steps given below to configure for restores:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server.
  2. Right-click the <Instance> and then click All Tasks | Restore.
  3. Click OK.
  1. In the right pane of the Browse window, select a database you want to restore and click Recover All Selected.
  2. Click the Advanced button.
  3. Click the Options tab and select the Continue After Error checkbox.
  4. Click OK.
  5. Click OK to start the restore.

    Selection of Continue After Error option will override the Checksum error on restore.

Configuring the Number of Log Backups to Run before a Full Backup

Create the additional setting nLogThreshHoldValue to set the number of log backups that you want to run automatically before a full backup is run. If one log backup is corrupt, it invalidates all the log backups performed afterwards. So, you should run full backups at regular intervals as it reduces any chance of data loss.

After the set number of transaction log backups are run, a minor event is generated in the Simpana event viewer for reminding users to run a full backup.

Use the following steps to configure the number of log backups to run before a full backup:

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> and then click Properties.
  3. Click the Advanced button and select Additional Settings tab.
  4. Click Add.
  5. Click Lookup besides the Name field.
  6. In the Lookup Additional Settings dialog box search for the key by performing one of the following:

    A global parameter SQLiDALogThreshHoldCount can be used to configure the number of transaction log backups to run before a full backup (for all SQL subclients within the same CommCell). You can use the Command Line Interface to do so, see qcommand execscript for details.

  7. Enter a number in the Value field. Range is [1 - <max_integer>].
    This value specifies the number of transaction log backups that will be taken before a minor event is issued to remind users to run a full backup.
  8. Click OK.

Configuring Log Backups to Run without Full Backups

By default, a full backup is required before performing a log backup. If you do not require a full backup at the time you want to back up the logs (for example, a full backup was performed outside of the system), you can do so as follows:

  1. From the CommCell Browser, navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the subclient and click Properties.
  3. Click the SQL Settings tab.
  4. Enable the Disable Log Consistency Check check box.
  5. Click OK.

Performing Backups Using VSS

VSS can be enabled for backups of local volumes in both clustered and non-clustered environments. If the operating system fails to create a shadow copy of the data a traditional backup of the data will be performed, and a corresponding message will appear in the Event Viewer.

When VSS option is enabled at instance level, the following will automatically occur:

  • All previously scheduled traditional full backups and differential backups convert to VSS full backups and VSS differential backups respectively.
  • All previously scheduled transaction log database backups are unaffected.
  • All previously scheduled File/Filegroup backups are blocked from running.
  • Immediate and scheduled VSS full backups and VSS differential backups run as single-stream backups.

During a VSS backup, the total amount of free space depends on the size of the backup data. As such, make sure to have sufficient disk space when you perform VSS backups.

  1. Navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the instance and click Properties.
  3. Enable the Use VSS check box.
  4. Click OK.

Configuring Data Streams

By default, backup data is sent to media in two streams. This means that a database, or a portion thereof, is sent to media during a backup in two parallel waves. This results in the backup taking about half the time to complete as it otherwise would if only one stream is used.

You can increase the number of streams used for backups for a particular subclient provided the number of streams does not exceed the maximum number configured in the subclient's storage policy. Increasing the number of streams for a subclient further reduces the amount of time a backup takes to complete. For example, increasing the number of streams from two to three enhances backup time from one-half that of a single stream to one-third.

  • Keep in mind that the number of streams configured for backups must also be used when restoring data. For example, if you configure a subclient to use four streams, you must also use four streams to restore the data.
  • If you are performing a restore operation from a secondary copy that has the Combined Stream option enabled, the restored data is temporarily staged at the Job Results folder before restoring it to a SQL Server. You can change the location of the staging folder by changing the value of additional setting sStageFolderAuxCopyRestore.

  1. From the CommCell Browser, navigate to Policies | Storage Policies.
  2. Right-click the storage policy associated with the subclient you want to increase the streams for and click Properties.
  3. Ensure the number in the Device Streams box is greater than the number of streams you want to configure for the subclient.

  1. Navigate to Client Computers | <Client> | SQL Server | <Instance>.
  2. Right-click the subclient and click Properties.
  3. Click the Storage Device Tab tab.
  4. Increase (or decrease) the number of streams in the Number of Streams for data backup box.
  5. Click the Log Storage Policy tab.
  6. Increase (or decrease) the number of streams in the Number of Streams for transaction log box.
  7. Click OK.

Configuring User Accounts for Backups

The SQL Server iDataAgent requires a Windows user account that has sufficient privileges for the software to:

  • Perform backups and restores
  • Access the Windows registry
  • Stop or start the SQL Server services.

By default, the local system account is used. The following table illustrates the requirements for a user-defined account:

If the SQL Server Is The User Account Should Be:
Member of a WorkGroup
  • Local Administrator of the computer on which the SQL Server resides, like computer_name\user1.
  • Member of the SQL sysadmin fixed server role.
Member of a Domain An account other than the Domain Administrator account that has Administrator and SQL sa privileges. The account should have interactive logon rights on the computer where the SQL Server resides.

Initially, the user credentials are not provided during the agent installation and by default, the local system account is used. You can change the user account at the CommCell, client computer group, agent, and instance levels. Accounts configured at each level will be used for all entities within that level as described in the following sections.

You can use any SQL account that satisfies the account requirement or use a user account from which SQL Server services are running by providing their respective login credentials.

In order to access the SQL Server databases to perform data protection and recovery operations, the SQL sysadmin rights are required.

For more information about the SQL sysadmin privileges, go to the Microsoft Support website and search for Microsoft KB article 2926557, SQL Server VDI backup and restore operations require Sysadmin privileges.

At the CommCell Level

This user account will be used for all SQL Server iDataAgents in your CommCell. Configure the user account at this level if one person will be conducting all backup and restore operations in your organization.

  1. From the CommCell Console ribbon, click the Home tab, and then click Control Panel.
  2. Under the Configure section, click SQL iDataAgent Configuration.
  3. In the SQL iDataAgent Configuration dialog box, select one of the following:
    • Use Local System Account if the Administrator account for the computer contains the required privileges.
    • Impersonate User if a different account contains the required privileges. Type the User Name and Password for this account in the space provided.
  4. Click OK.

At the Client Computer Group Level

This user account will be used for all computers within a Client Computer Group. Configure the user account at this level if different users will be conducting backup and restore operations for each Client Computer Group in your organization. This user account will override the user account configured at the CommCell level.

  1. From the CommCell Browser, navigate to the Client Computer Groups node.
  2. Verify that all the Agent clients for which you wish to configure the user account are included in the Client Computer Groups.
  3. Right-click the <Client Group> and click Properties.
  4. Click the Advanced Settings tab.
  5. Click the Override higher levels settings check box.
  6. Select one of the following:
    • Use Local System Account, if the computer's Administrator account contains the required privileges.
    • Impersonate User, if you want to use a different account that contains the required privileges. Type the User Name and Password for this account in the space provided.
  7. Click OK.

User credentials provided at the client computer group level are ignored if one of the clients in the group belong to more than one group that have credentials specified. In such a case, provide user credentials at the instance level of that client.

At the Agent Level

This user account will be used for all instances and associated subclients. Configure the user account at this level if one person will be conducting all backup and restore operations on the client on which the SQL Server iDataAgent is installed. This user account will override the user account configured at the CommCell and Client Computer Group levels.

  1. Navigate to Client Computers | <Client>.
  2. Right-click SQL Server and click Properties.
  3. Click the Authentication tab.
  4. Enable the Override higher levels settings check box.
  5. Select the following:

    Use Local System Account if the computer's Administrator account contains the required privileges.

    Impersonate User if you want to use a different account that contains the required privileges. Type the User Name and Password for this account in the space provided.

  6. Click OK.

At the Instance Level

This user account will be used for all subclients within the instance. Configure the user account at this level if backup and restore operations will be conducted by a different person for each instance. This user account will override the user account configured at the CommCell, Client Computer Group, and Agent levels.

  1. Navigate to Client Computers | <Client> | SQL Server .
  2. Right-click the <Instance> and click Properties.
  3. Click the Accounts tab.
  4. Enable the Override higher levels settings check box.
  5. Select the following:

    Use Local System Account if the computer's Administrator account contains the required privileges.

    Impersonate User if you want to use a different account that contains the required privileges. Type the User Name and Password for this account in the space provided.

  6. Click OK.

For SQL Availability Group (AG) clients, configure the user account at the instance level. The availability groups may belong to different clusters under the same SQL AG client, so the permissions may not work at the agent level.

Modifying an Agent, Instance, or Subclient

There are several configurable properties available for your agent that can be modified from the agent, instance, or subclient level as per need.

It is recommended that you do not modify the properties of a subclient when a job is in progress for that specific subclient. If a job is in progress, either wait for the job to complete or kill the job from the Job Controller.

The following table describes the properties that can configured from the agent, instance, and subclient levels.

Option Description Related Topics
Change Storage Policies You can modify the storage policies in any of the following situations:
  • To include a different media for the backup operation.
  • To use a storage policy with a different retention criteria.

You can change the storage policies from the subclient level.

  1. From the CommCell Browser, right-click the subclient.
  2. Click Properties.
  3. Click Storage Device.
  4. Select the Storage policy from the drop-down menu.
  5. Click OK.
Refer to Storage Policies.
Rename a Subclient

You can rename a subclient:

  1. From the CommCell Browser, right-click the subclient.
  2. Click Properties.
  3. Type the new name in the  Subclient name field.
  4. Click OK.
 
Data Transfer Options You can configure the available resources for transferring data secured by data protection operations from the subclient level. This includes the following:
  • Enable or disable Data Compression either on the client or on the MediaAgent.
  • Configure the transfer of data in the network using the options for Network Bandwidth Throttling and Network Agents.

You can configure the data transfer options.

  1. From the CommCell Browser, right-click the subclient.
  2. Click Properties.
  3. Click Storage Device.
  4. Click Data Transfer Option tab.
  5. Choose the appropriate software compression option for this subclient.
  6. Select Throttle Network Bandwidth and set the required bandwidth.
  7. Click OK.
Refer to Data Compression and Network Bandwidth Throttling.
View Data Paths You can view the data paths associated with the primary storage policy copy of the selected storage policy or incremental storage policy. You can also modify the data paths including their priority from the subclient level.
  1. From the CommCell browser, right-click the subclient.
  2. Click Properties.
  3. Click Storage Device.
  4. Select Storage Policy from the drop-down menu.
  5. Click Data Paths.
 
Configure a Subclient for Pre and Post Processing of Data Protection You can add, modify or view Pre/Post processes for the subclient. These are batch files or shell scripts that you can run before or after certain job phases.
  1. From the CommCell browser, right-click the subclient.
  2. Click Properties.
  3. Click Pre/Post Process.
  4. Click one of the following phases and type the full path of the process that you want to execute during that phase. Alternatively, click Browse to locate the process (applicable only for paths that do not contain any spaces).
    • PreBackup Process
    • PostBackup Process
  5. Click OK.
  6. Select Run Post Backup Process for all attempts to run a post backup process for all attempts.
  7. For subclients on Windows platforms, Run As displays Not Selected.

    If you want to change the account that has permission to run these commands, click Change.

    1. In the User Account dialog box, select Use Local System Account, or select Impersonate User and enter the user name and password. Click OK.
    2. If you selected Local System Account, click OK to the message advising you that commands using this account have rights to access all data on the client computer.
Refer to Pre/Post Processes.
Configure Activity Control You can enable backup and restore operations from the agent and subclient level. However, you can enable restore operations only from the agent level.
  1. From the CommCell browser, right-click the subclient.
  2. Click Properties.
  3. Click Activity Control, select or clear option(s) as desired.
  4. Click OK.
Refer to Activity Control.
Configure User Security You can configure user security from the agent or subclient level.

You can perform the following functions:

  • Identify the user groups to which this CommCell object is associated.
  • Associate this object with a user group.
  • Disassociate this object from a user group.
  1. From the CommCell browser, right-click the subclient.
  2. Click Properties.
  3. Click Security.
  4. Select the appropriate user groups to which you want to associate to the CommCell object from the Available Groups pane, and then move the user group to the Associated Groups pane.
  5. Click OK.
Refer to User Administration and Security.
Enable and Disable Data Encryption When you configure encryption at the client level, it is configured automatically for all the subclients associated with all the agents installed on that client. If you want to disable or change the encryption at the subclient level, follow the steps given below:
  1. From the CommCell browser, right-click the subclient.
  2. Click Properties.
  3. Click Encryption.
  4. Select the desired encryption.
  5. Click OK.
Refer to Data Encryption.
View Software Version and Installed Updates At the client level, the Version tab of the Properties dialog box displays the software version of the component.
  1. From the CommCell Browser, expand Client Computers.
  2. Right-click the appropriate client, and then click Properties.
  3. Select the Version tab.
  4. Click OK.
 
CommCell Configuration Report The CommCell Configuration Report provides the properties of the CommServe, MediaAgents, clients, agents, subclients, and storage policies within the CommCell based on the selected filter criteria.
  1. From the CommCell browser, click Reports icon.
  2. Select CommCell Configuration.
  3. Click Run.
Refer to CommCell Configuration.

Deleting an Agent, Instance, or Subclient

The following sections describe the steps involved in deleting an agent, instance, or subclient.

When you delete an instance or backupset, the associated data is logically deleted and you can no longer access the corresponding data from CommCell Console for recovery purposes.

Refer to the troubleshooting article on Recovering Data Associated with Deleted Clients and Storage Policies for information on how to recover data if you accidentally delete an entity.

Deleting an Agent

You need to uninstall or DeConfigure the agent software from the client computer before deleting from CommCell Browser. After you delete the client software, you can either leave the corresponding data intact for appropriate action or you can remove the data immediately. If you choose to remove the data immediately, you must delete the agent from the CommCell Browser. If you delete the agent, all of the agent's data is irretrievably lost.

  • You cannot delete an agent while operations for that agent are running.
  1. From the CommCell Browser, navigate to Client Computers | <Client>.
  2. Right-click the <Agent>, and then click Delete.
  3. A confirmation message is displayed with the following message:

    This operation will permanently delete the data backed up from this level and it cannot be restored.

  4. Click OK to continue with the deletion operation or click No to abort the deletion.

Deleting an Instance

Consider the following before deleting an instance:

  • When you delete a specific instance all job schedules and job histories that pertain to any of the levels within the deleted instance are deleted.
  • You cannot delete an instance if it is being backed up. Attempts to delete an instance under such conditions cause the deletion to fail. If a backup is in progress, either wait for the backup to complete or kill the backup job using the Job Controller. Once the backup is no longer in progress, you can delete the instance level.
  • You cannot delete an instance if there is only one instance present for an agent. To delete the final instance, you must remove the agent software from the client computer.
  1. From the CommCell Browser, right-click the instance that you want to delete, click All Tasks and then click Delete.
  2. Click Yes to confirm the deletion. (Clicking No cancels the deletion and retains the node.)
  3. Type the requested phrase in the Enter Confirmation Text dialog box and click OK. This should delete the instance.

Deleting a Subclient

Consider the following before deleting a subclient:

  • You cannot delete a default subclient.
  • Schedules associated with the subclient are also automatically deleted.
  1. From the CommCell Browser, navigate to Client Computers | <Client> | <Agent> | <Instance>
  2. Right-click the <subclient> that you want to delete, and then click Delete.
  3. A confirmation message is displayed, asking if you want to delete the subclient.

    Click No to cancel the deletion and retain the subclient, or click Yes to continue the deletion.