Recommended Tivoli Storage Manager policy settings

Define the policy set to the policy domain to which Data Protection for SQL Server backups belong. The policy set must be activated and only one policy set can be active in the policy domain.

Define a management class for backups on local shadow volumes, and a management class for backups on Tivoli Storage Manager server storage. Different management classes provide the opportunity for specialized policies for each storage destination. For example, you can maintain six versions of local VSS backups of a given storage group (verexists=6) while you maintain only two versions of the same storage group on Tivoli Storage Manager server storage (verexists=2). In addition, you can create a separate management class for copy backup types for use in long term storage. Such policies can maximize storage resources and provide more control over your storage strategy.

You can have five active backups of the same storage group because legacy backups on Tivoli Storage Manager server storage, VSS backups on Tivoli Storage Manager server storage (COPY and FULL), and VSS backups on local shadow volumes (COPY and FULL) all have different Tivoli Storage Manager server naming and therefore, can each have their own management class. Ensure that you plan your backup strategy before you define management classes.

Metadata considerations (Legacy only)

The management classes for Data Protection for SQL Server metadata are to be identical to the corresponding management classes for database data. The exception is that the metadata management classes do not allow migration to removable media. If any Data Protection for SQL Server metadata is on removable media, queries might require media mounts, and backups or restores might require more media mounts.

Data objects and their associated meta objects are to have the same version limits and retention values. However, because meta objects might be restored as a result of a Data Protection for SQL Server query, consider storing meta objects in a disk-only storage pool. In doing so, a media mount is not necessary to resolve the query. To achieve this scenario, implement these steps:

1. Define a separate management class with a Copy Destination pointing to a disk pool that does not have any removable media in its hierarchy.
2. Bind all meta objects to that management class by using an include statement in the Data Protection for SQL Server options file.

Alternatively, you can choose to use the same management class (and storage pools) for both meta and data objects if you rarely need the meta objects, or need them only immediately preceding a restore when a volume mount is required anyway. In many cases, you can also obtain the meta object information from SQL Server as recorded in its msdb database. For more information about binding backup objects to specific management classes, see Configuring Tivoli Storage Manager policy to set automatic expiration and version control (VSS and legacy backups).

Define the copy group as a backup copy group and not as an archive copy group. Because Data Protection for SQL Server stores all objects as backup objects on Tivoli Storage Managerin backup storage pools, an archive copy group is not required, although an archive copy group can exist. The following backup copy group parameters significantly influence your backup policy:

VERExists

Determines the maximum number of SQL Server database backup versions to retain for databases that exist on the Data Protection for SQL Server client system.

VERDeleted

Determines the maximum number of SQL Server database backup versions to retain for databases that were deleted from the Data Protection for SQL Server client system after being backed up by Tivoli Storage Manager.

RETExtra

Determines the number of days to retain an SQL Server database backup version after that version becomes inactive.

RETOnly

Determines the number of days to retain the last SQL Server database backup version of a database that was deleted from the Data Protection for SQL Server client system. Because of version limit, incremental backups are not expired. Only one version of an incremental backup object exists at a time because incremental backups are always uniquely named. However, all legacy backup objects for an SQL Server storage group are inactivated when a new full backup of that SQL Server storage group is completed. VSS backup objects remain active. The retention period that is set in the RETOnly parameter controls the expiration of incremental backup objects.

When you set the value of the RETOnly parameter for incremental backups, the value must be, at a minimum, as long as the value that is set for the full backup objects to which the incremental backups are associated. You can use the same management class for incremental backups and the full backup objects (that are retained the longest) to ensure that an adequate value is used. However, when a new legacy full backup of that SQL Server storage group is completed, all legacy backup objects for an SQL Server storage group are inactivated. In this scenario VSS backup objects remain active.

MODE, SERialization, FREQuency

Because theses parameters settings do not apply to Data Protection for SQL Server, accept the default values.

When you plan a backup strategy, as a best practice, consult with the Tivoli Storage Manager server administrator about recommended parameter settings.

A single restore operation can require a full backup, a differential backup, and multiple incremental backups. Use collocation if backups are stored on removable media. Specify collocation by file space (define stgpool COLlocate=FILespace) if you plan to restore multiple storage groups in parallel.