Chapter 1.

Introducing Data Protection for SQL

Data Protection for SQL allows you to perform online backups and restores of Microsoft SQL Server databases to Storage Manager Server storage using either command-line or graphical user interfaces (GUI) on Windows NT and Windows 2000. This chapter provides the following information about Data Protection for SQL: Version migration and coexistence Features Functions Security Performance Backup strategy considerations Online help Microsoft Cluster Server (MSCS) considerations

|Version migration and coexistence considerations

||| |IMPORTANT! |Data Protection for SQL Version 5.1.5 utilizes the same |backup naming conventions, file space names and placement, and meta contents |as Data Protection for SQL Version 2.2. Like Version 2.2, |Data Protection for SQL Version 5.1.5 is completely incompatible |with Data Protection for SQL Version 1. You cannot query or restore |backup objects created by Version 1 with Version 2.2 or Version |5.1.5. As a result, if you are storing backup objects |created by Version 1, you must retain Version 1 for as long as you retain |those backup objects. Version 5.1.5 and Version |2.2 can coexist with Version 1. However, like Version |2.2, the Data Protection for SQL Version 5.1.5 interfaces |are not compatible with the Version 1 interfaces. No migration tool is |provided to help convert Version 1 command line scripts to Version |5.1.5 syntax. The Version 5.1.5 |installation program will not replace any installed Version 1. |Data Protection for SQL Version 5.1.5 is compatible with Data |Protection for SQL Version 2.2.

Data Protection for SQL features

Data Protection for SQL helps you protect and manage SQL Server data by making it easy to: |Back up any SQL database to any Storage Manager Server. |Perform full and transaction log backups and restores of SQL |databases. |Perform backups with an expanded range of options such as |differential, file, and group operations. See SQL Server database backup for more detail. Perform operations from multiple SQL Server instances on the same machine as Data Protection for SQL (for SQL Server 2000).

Note: You can access only one SQL Server per execution of Data Protection for SQL from either the command line or GUI. Perform any backup using data striping in parallel threads using parallel sessions (up to 32 stripes for SQL Server 7.0 and 64 stripes for SQL Server 2000). Automate scheduled backups. See Appendix A, Using the Storage Manager scheduler. Perform expanded restore operations on backup objects such as relocating, restoring to named marks, and partially restoring full backups. See SQL Server database restore. Restore database backups to a different SQL Server. Retain with a backup the information needed to recreate or move SQL databases or files, such as sort order, code page, and Unicode information, or filegroup and file logical and physical names. The meta object information is retained on the Storage Manager Server separately from the backup data objects. Inactivate all active objects, all objects of a particular backup type, or specific objects. Inactivate objects older than a specified number of days. See SQL Server database inactivate. Set automatic expiration of backup objects based on version limit and retention period. See Storage Manager policy requirements and recommendations. Query any local SQL Server or any connected Storage Manager Server for database, status, and configuration information. See Data Protection for SQL query. Monitor results through the Data Protection for SQL activity log and automatically prune the activity log. Set Storage Manager connection information options to Storage Manager Servers. Set Storage Manager security and performance options. See Data Protection for SQL security. Participate in MSCS and Windows 2000 fail-over clusters. See Running Data Protection for SQL on a MSCS. Apply fail-over clustering (for maintenance or restoring the master database) without unclustering. Obtain online context-sensitive, task, and concept help. See Online Help. View online documentation for Data Protection for SQL.

Data Protection for SQL functions

Data Protection for SQL provides these functions: Backup (page "SQL Server database backup") Restore (page "SQL Server database restore") Query (page "Data Protection for SQL query") Inactivate (page "SQL Server database inactivate")

SQL Server database backup

A backup creates a copy of all or part of a SQL database on Storage Manager storage media. Data Protection for SQL provides selection mechanisms and the logic that are required to back up and restore SQL data. For example, when you initiate a backup operation, Data Protection for SQL: 1. Starts a session with a Storage Manager Server using the Storage Manager API and information contained in a client options file. 2. Starts a session with the SQL Server using the SQL-DMO interface. 3. |Instructs the SQL Server using the SQL VDI interface to begin a |backup of the selected database objects. 4. Receives data from the SQL Server and sends it to the Storage Manager Server.

5. Ends the Storage Manager and SQL Server sessions. Notes: 1. Data Protection for SQL can compress SQL data before sending it to the Storage Manager Server. 2. Meta Data: When a backup is performed, Data Protection for SQL retains information about the SQL Server and database. This information is available for query and restore operations after the backup is completed. The information about the names and sizes of the database filegroups and files is stored along with the database data, as a sub-object. This sub-object is referred to as meta data. You will need this "meta" sub-object only when you need information about individual database filegroups and files. Data Protection for SQL offers an expanded range of backup types beyond full and log backups which allow greater flexibility when you do not want to backup an entire database, or when it is not practical to do so due to available backup time or performance requirements. Data Protection for SQL provides six types of backup: Full database backup Data Protection for SQL backs up an entire SQL Server database and the portion of the transaction log necessary to provide a consistent database state. With both full and differential backups, the copy includes enough information from any associated transaction logs to make a backup consistent with itself. The portion of the log included contains only the transactions that occur from the beginning of the backup until its completion. Note: You do not have to do a full backup to constitute the equivalent of a full backup. Backing up all the groups or files in a database as well as its log are recognized as a full backup by the SQL Server. A base backup may be a full, group, file, or set. Differential backup Data Protection for SQL backs up only the data pages in a SQL Server database changed since the last full backup and a portion of the transaction log. Log backup Data Protection for SQL backs up only the contents of a SQL Server database transaction log since the last successful log backup. To do the first log backup, you need to have done a full backup or its equivalent first. Log backups normally follow full backups. The portion of the log included in full and differential backups is not equivalent to a log backup. Additionally, in full and diff backups, the log is not truncated as it is during a log backup. However, a log backup following a full or differential backup will include the same transactions as a full or differential. Log backups are not cumulative as are differential; they must be applied against a base backup and in the correct order. Note: A log backup in SQL Server terms is not equivalent to an incremental backup in Storage Manager terms. File backup Data Protection for SQL backs up only the contents of a specified SQL Server logical file. This can ease the scheduling for backing up very large databases by allowing you to back up different sets of files during different scheduled backups. File, group, and set backups must be followed by a log backup, but a full is not required. Group backup Data Protection for SQL backs up only the contents of a specified SQL Server filegroup. This allows you to back up just the set of database tables and indexes within a specific group of files. Set backup

Data Protection for SQL backs up the contents of specified SQL Server filegroups and files as a unit. For more on backups using the GUI, see Backing up SQL databases, or for backups using the command line, see Backup command or Chapter 6, Command line parameters. See also Data Protection for SQL backup strategy considerations.

SQL Server database restore

A Data Protection for SQL restore obtains backup copies of all or part of one or more SQL databases and returns them to the SQL Server. A complete restore of a database involves restoring a full backup or the equivalent thereof (from group, file, or set backups) and restoring all transaction logs since the last full backup. For a restore, Data Protection for SQL: 1. Starts a session with a Storage Manager Server using the Storage Manager API and information contained in a client options file. 2. Starts a session with the SQL Server using the SQL-DMO interface. 3. Queries the Storage Manager Server for a list of database backups. 4. Instructs the SQL Server using the SQL VDI interfaceto begin a restore of the selected database objects. 5. Receives data from the Storage Manager Server and forwards it to the SQL Server. 6. Ends the Storage Manager and SQL Server sessions. Data Protection for SQL provides the same range of object types for restore as for backup: Full database restore Data Protection for SQL restores full database backup objects for specified SQL databases. Differential restore Data Protection for SQL restores only differential database backup objects for specified SQL databases. Restore time is reduced as only the latest differential backup is restored (after its associated full backup is restored). Log restore Data Protection for SQL restores only log backup objects for specified SQL databases. File restore Data Protection for SQL restores just the file backup objects needed from a full backup, filegroup backup, a file backup, or a set backup for specified SQL databases. Group restore Data Protection for SQL restores just the group backup objects needed from a full backup, filegroup backup, a file backup, or a set backup for specified SQL databases. Set restore Data Protection for SQL restores only set backup objects for specified SQL databases. Depending on the backup strategy you choose, restoring a SQL database might involve restoring multiple backup objects from the Storage Manager Server. See Data Protection for SQL backup strategy considerations. In support of current SQL Server restore capabilities, Data Protection for SQL also provides the ability to relocate files during restore and to perform point-in-time restores, named-marks restores, or partial restores: relocate

Allows you to move individual database files to a new location without having to first create the files. point-in-time Allows you to restore a transaction log backup to a specific SQL transaction date and time. named-marks For SQL Server 2000, allows you to restore a transaction log backup to or before a named point, possibly after a specified point in time, and recover multiple related databases to the same named mark. partial For SQL Server 2000, allows you to restore just enough of a database into a temporary location to copy a specific table to the active database. Further Data Protection for SQL restore functions include the following: Restore a backup using the same number of data stripes used to create the backup, or fewer stripes for SQL Server 2000. Restore with no recovery until the last restore with recovery. |Restore from any available backup version created by Data Protection |for SQL Version 5.1.5 or Version 2.2. Replace an existing database with the restored database (or replace by relocating the restored database). Restore to a different SQL Server or to a standby SQL Server. Automatically restore all backup objects needed to make a restore complete by using smart selection in the GUI. For more on restores using the GUI, see Restoring SQL databases, or for restores using the command line, see Restore command or Chapter 6, Command line parameters.

Data Protection for SQL query

A Data Protection for SQL query provides this information: Query the status of a local SQL Server. List the databases on a SQL Server. List the database objects in Storage Manager storage. Provides information about Data Protection for SQL |Provides connection information about the Storage Manager |Server. Query SQL Server A query of any SQL Server on the same node as Data Protection for SQL provides this information: Information about a specific SQL Server All databases on a SQL Server The configuration of any SQL Server database

Query Storage Manager Server You can query the Storage Manager Server in order to list the following: A summary of backup types and quantities for a specific SQL database or all SQL databases All databases from a particular SQL Server backed up to the current Storage Manager Server and node

|Connection information about the Storage Manager Server. The saved configuration of any backup object All or active versions of all backups, a specific type of backup, or a specific backup Files or file groups

Query Data Protection for SQL This lists the values in effect in the Data Protection for SQL configuration file. For more on Data Protection for SQL query using the command line, see Query command and Query. Using the Data Protection for SQL GUI, you can display information about servers, databases and backup objects through the list control pane of backup and restore windows. See Backup list and Restore list for details.

SQL Server database inactivate

This function allows SQL database backup objects to be inactivated on the Storage Manager Server and then participate in Storage Manager expiration processing. |Typical backups do not require this command as Storage Manager |performs inactivation as a part of Storage Manager policy |management. As a result, backup objects are typically inactivated as part of the scheduled backup processing. Data Protection for SQL: 1. Starts a session with a Storage Manager Server. 2. Marks the specified object inactive. 3. Ends the Storage Manager session. For cases when automatic processing is not sufficient, the inactivate function explicitly inactivates one or more (or all) active backup objects on the Storage Manager Server. As with backup and restore, Data Protection for SQL allows you to select any or all of six backup object types for operation: full, differential, log, file, group, or set. In addition, it is possible to inactivate any object or object type older than a specified number of days. For more on inactivate using the GUI, see Inactivating SQL databases, or for inactivate using the command line, see Inactivate command or Chapter 6, Command line parameters.

Data Protection for SQL security

Data Protection for SQL requires that you have Windows administrator authority. This is needed for installation.

Storage Manager security

Standard Storage Manager security requirements apply to Data Protection for SQL. Data Protection for SQL must be registered to the Storage Manager Server and the appropriate node name and password must be used when connecting to Storage Manager Server.

SQL Server logon information

Data Protection for SQL provides three options when specifying SQL Server logon information:

 Accept the default sa account and blank password. Use SQL user ID security and specify both the SQL user name and password. With SQL user ID security, the SQL Server administrator provides the logon ID and the password that provides access to the SQL Server. Use a trusted connection and let Windows NT or 2000 authenticate the logon. Note: The SQL logon user or Windows user name must be added to the SQL Server SYSADMIN fixed server role before it can be used by Data Protection for SQL.

Data Protection for SQL performance

Many factors can affect the backup and restore performance of Data Protection for SQL, such as hardware configuration, network type, and capacity. These factors are not within the scope of this document. However, some parameters that are related to Data Protection for SQL can be tuned for optimum performance. Buffering: Data Protection for SQL is a multi-threaded application that uses asynchronous execution threads to transfer data between the SQL and Storage Manager Servers. To accomplish this, multiple data buffers are used to allow one thread to receive data from one side, while another thread sends data to the other side. For example, one thread can be reading data from a SQL Server while another is sending data to the Storage Manager Server. The number of buffers that Data Protection for SQL allocates to these threads can be specified in the /buffers and /sqlbuffers parameters of the command line interface. The size of these buffers can be specified in the /buffersize and /sqlbuffersize parameters. For more information, refer to "Optional parameters". Data Striping: In addition to multi-threading to maximize throughput on a single session, Data Protection for SQL uses separate threads to support SQL data striping, which allows use of multiple parallel sessions to backup and restore a single database. This is another method to maximize data throughput. If a single session cannot fully exploit available bandwidth, multiple parallel sessions can yield improved data throughput, especially if the database is spread across multiple physical volumes. If you use one data stripe per physical volume for both the SQL Server and the Storage Manager Server, the performance (measured as the amount of time necessary to backup or restore a particular SQL database) should show an improvement over the unstriped case (approximately proportional to the number of data stripes used, given the constraints of the devices and the network used, and striping independent overhead in SQL Server, Storage Manager Server, and Data Protection for SQL). For more on striping using the command line, see ***. Notes: 1. Additional striping does not necessarily improve performance and may even decrease performance if system constraints involving real and paged memory, CPUs, network interface cards, networks, device reads and writes, and RAID become saturated or exceed capacity. 2. If you use striping in conjunction with SQL buffers, be certain that the number of SQL buffers specified is equal to or greater than the number of stripes.

3. |The default values that Data Protection for SQL assigns to buffers, |buffersize, and stripes can be changed in the Data Protection for SQL |configuration file. Use the set command or the Edit menu of |the GUI to modify the configuration file. Virtual Device Interface Microsoft SQL Server 7.0 introduced VDI to back up and restore databases. Data Protection for SQL uses this interface as a high-performance alternative to named pipes interfaces used with earlier server versions. LAN Free |Running Data Protection for SQL in a LAN free environment if you are |equipped to do so avoids network constraints. Specify |enablelanfree yes in the Backup-Archive Client options |file (dsm.opt). For information on setting up a LAN free |environment, refer to the Tivoli publication Managed System for SAN |Storage Agent User's Guide.

Data Protection for SQL backup strategy considerations

Depending on your specific requirements regarding network traffic, backup window and acceptable restore times, you might choose to follow different backup strategies. Some commonly used strategies are described as follows: Full backup only This approach is best for SQL databases that are relatively small because it implies that the entire database is backed up each time. Each full backup takes longer to perform, but the restore process is most efficient because only the most recent (or other appropriate) full backup need be restored. This is the appropriate strategy for system databases such as master, model, and msdb due to their normally small size. Full plus log backup A full plus transaction log backup strategy is commonly used when the normal backup window or network capacity cannot support a full backup each time. In such cases, a periodic full backup followed by a series of log backups allows the backup window and network traffic to be minimized. For example, you can perform full backups on the weekend and log backups during the week. The full backups can be done during low usage times when a larger backup window and increased network traffic can be tolerated. The restore process becomes more complex, however, because a full backup, as well as subsequent log backups, must be restored. Note: It is possible to do a point-in-time restore to restore a transaction log to a specified date and time. Differential backup Perform this type of backup between full backups. A differential database backup can save both time and space -- less space in that it consists of only the changed portions of a database since the last full backup (it is cumulative), and less time in that you can avoid applying all individual log backups within that time to the operation. This applies to restore operations as well; only the last differential backup (latest version) need be restored. If restore time is more critical than backup time, SQL Server 7.0 differential backups may be desirable. However, differential backups with SQL 7.0 may take longer than log backups and longer than expected, even if the database has changed little since the last full backup. This is because SQL 7.0 processes every page of the database to determine if it should be included in the differential backup. SQL Server 2000, on the other hand, keeps track of which database

pages have changed since the last full backup and does not have to process any pages that will not be included in the differential backup. Full plus differential plus log backup This strategy allows for a faster restore scenario by reducing the number of transaction logs that may need to be restored and applied. If, for example, a full backup is done weekly, a differential nightly, and a log backup every four hours, the restore would involve the full backup, a differential, and at most five log backups. However, simply a full plus log backup scheme on the same cycle could require a full plus up to forty-one log backups to be restored (six days times six log backups per day plus up to five backups on the day the full backup was done). File or group backups Use a file backup strategy when it is impractical to backup an entire database due to its size and accompanying time and performance issues. Note that when performing restore operations for a file or file group, it is necessary to provide a separate backup of the transaction log. File or group options can also save both backup and restore time in cases when certain tables or indexes have more updates than others and need to be backed up more often. It is timeeffective to place such data in their own filegroup or files and then back up only those items.

Additional strategy considerations

The following list provides additional information you should consider when choosing a backup strategy for SQL Server 7.0 or 2000 with Data Protection for SQL Version 5.1.5. Saving time: If a SQL Server volume fails, restoring only the files that are on that volume can save restore time. Using multiple data stripes can speed up both backup and restore time. If backing up directly to sequential storage media such as tape pool, use as many stripes as there are tape drives that can be allocated to the SQL backup; otherwise, the separate sessions will queue up waiting for a tape. For SQL Server 7.0, the restore must use the same number of data stripes as the backup. Using data compression will reduce network traffic and storage requirements. However, whether it increases or decreases total backup time depends on several factors including the speed of the processors doing the compression and available network bandwidth. For fast networks, compression can increase the backup and restore times. See *** for more detail.

Data striping: If you use data striping, also use Storage Manager Server filespace collocation to try to keep each stripe on a different storage volume. Use the Storage Manager command update stgpool to set this parameter. It is recommended that meta data (counted as a separate filespace) not be allowed to go to tape media. The maximum number of data stripes you can use must be smaller than the maximum supported by the SQL Server and less than the value of the Storage Manager Server txngroupmax option in the dsmserv.opt file. SQL Server 7.0 allows a maximum of 32 data stripes, and SQL Server 2000 allows a maximum of 64.

Clustering:

If you use Microsoft Cluster Server or Windows 2000 clustering for fail-over support, you must install Data Protection for SQL on each cluster node and configure it identically. Additional setup is required to complete the fail-over installation. You must identify a clustered SQL Server by its virtual server name and use that name in Data Protection for SQL to access that SQL Server. See Running Data Protection for SQL on a MSCS for more information. Truncate log on checkpoint option: When you choose to perform only full backups in SQL, you can also indicate that you want to truncate the log after checkpoints. This will prevent the log from growing without bounds. Truncate log option: When you choose to perform a transaction log backup, you can indicate that you do not want to truncate the log. In general, you do not want to truncate the log when rebuilding a corrupt database. This option enables the server to back up the transaction log but does not try to touch the data in any way. It writes all transaction log entries from the time of the last log backup to the point of database corruption. For SQL Server 7.0, the primary file group must be accessible. Collocation: If you use the full plus log backup strategy, you must decide whether to modify Storage Manager storage management policies to ensure that all log backups are stored together on the Storage Manager Server (collocated). This helps improve restore performance by reducing the number of media mounts necessary for restoring a series of log backups. Consult your Storage Manager administrator for details on collocation. Multiple SQL Servers: If multiple instances of SQL Server are running, the additional instances are identified by name. You must use that name in Data Protection for SQL to access that SQL Server. If you want to restore a backup to a different SQL Server, in SQL Server 7.0, that server must have the same sort order, code page, and Unicode configuration as the original server; otherwise, SQL Server 7.0 will reject the restore and issue an error message.

Various Recommendations: You must use the maxnummp parameter on a Storage Manager register node or update node command to allow a node to use multiple sessions to store data on removable media (which requires multiple mount points to be allocated to that node). Set backups are intended for special circumstances. If you plan to back up a set of file groups and files regularly, back up each separately in order to exploit version limits within the management class. You cannot back up the tempdb database. It is a temporary database that is recreated each time the SQL Server is started. SQL databases with the truncate log on checkpoint option (master or msdb) or that use the SQL Server 2000 Simple recovery model do not have transaction logs that can be backed up. Regardless of the frequency of database backups, it is highly recommended that you always run dbcc checkdb and dbcc checkcatalog on a database just before backing it up to check the logical and physical consistency of the database. See your SQL Server documentation for more information on using the SQL Server database consistency checker. Data Protection for SQL provides backup and restore functions for SQL databases and associated transaction logs. However, Data Protection for SQL does not provide a

complete disaster recovery solution for a SQL Server by itself. There are many other files that are part of the SQL Server installation. These files would need to be recovered in a disaster recovery situation. Examples of these files are executable and configuration files. A comprehensive disaster recovery plan can be obtained by using the normal Storage Manager backup-archive client for Windows, together with Data Protection for SQL. Consult your Microsoft SQL Server documentation for more details on SQL Server backup strategy and planning.

Online Help
Data Protection for SQL provides online help you can view from the GUI. Select Help ->Contents in the GUI Toolbar to launch the online help. The online help includes information about: How to configure Data Protection for SQL. How to back up, restore, and activate a database. Conceptual information about Data Protection for SQL. Note: Data Protection for SQL Version 5.1.5 online help does not support word searches for doublebyte character sets (DBCS). Data Protection for SQL also provides an online version of this Installation and User's Guide in compiled HTML and PDF format. These files are installed in the Program Files\Tivoli\TSM\doc directory.

Running Data Protection for SQL on a MSCS

Data Protection for SQL supports SQL Server running in a MSCS environment. For Windows 2000, Data Protection for SQL uses the Active Directory to support fail-over clustering. The list below provides information to consider when running Data Protection for SQL in a Microsoft Cluster Server Environment. References to the SQL Server made in this book pertain to the virtual SQL Server name in an MSCS environment. You must install Data Protection for SQL on both nodes of the cluster. In addition, when installing Data Protection for SQL, you must install it on a disk local to each node (not on a shared cluster disk). You must specify clusternode yes in the Data Protection for SQL options file. Use identical configurations in the Data Protection for SQL options file when configuring Data Protection for SQL on each node of the cluster. If you are using the Storage Manager scheduler for automating backups, you must install the scheduler service on both nodes of the cluster to enable fail-over support. See Appendix A, Using the Storage Manager scheduler for more information. |Use the Cluster Administrator to start the SQL Server |service. The Storage Manager Server treats backups as coming from a single server (the virtual server) regardless of which node of the cluster a backup was performed on. When accessing the MSCS from the GUI, note the following:

 You must invoke the GUI with the /sqlserver parameter. For example, if the SQL Server name on your MSCS is "sqlvs2", the GUI invocation is: tdpsql /sqlserver=sqlvs2 If you install Data Protection for SQL prior to converting to a Microsoft Cluster Server environment, you need to modify the Start menu shortcut for the Data Protection for SQL GUI program. You can do this by adding the /sqlserver parameter to the invocation of tdpsql. For example, if you installed Data Protection for SQL to the default location and your virtual SQL Server name is sqlvs2, you would modify the shortcut to be: "C:\Program Files\Tivoli\TSM\TDPSql\tdpsql.exe /sqlserver=sqlvs2" If you have an ACTIVE/ACTIVE SQL Server cluster environment, you should create a Start menu shortcut for each virtual SQL Server that can run on this machine.