WHITE PAPER: ENTERPRISE SOLUTIONS. Symantec Backup Exec Continuous Protection Server Continuous Protection for Microsoft SQL Server Databases

WHITE PAPER: ENTERPRISE SOLUTIONS Symantec Backup Exec Continuous Protection Server Continuous Protection for Microsoft SQL Server Databases

White Paper: Enterprise Solutions Symantec Backup Exec Continuous Protection Server Continuous Protection for Microsoft SQL Server Databases Contents Executive summary..................................................................6 About the Backup Exec Continuous Protection Server...................................6 Phases of a CPS job..................................................................7 Scheduled versus continuous protection.................................................8 Maintaining previous versions of protected data..........................................8 Protecting SQL Server databases......................................................9 Protecting user-created SQL Server databases............................................9 Protecting multiple data files and log files...............................................9 Protecting all SQL Server databases...................................................12 Multiple server instances............................................................13 Restoring SQL Server databases.....................................................14 Restoring a single database..........................................................14 Restoring multiple databases.........................................................15 Restoring all databases..............................................................16 Post-restore tasks.................................................................16 Attaching a restored database........................................................16 Restarting SQL Server after restoring all databases......................................19 Client connectivity..................................................................19

Additional applications for SQL Server protection with CPS.............................20 Comprehensive SQL data protection...................................................20 Migrating a database to a new server..................................................21 Limitations........................................................................22 Replacing a SQL Server or volume when using CPS.....................................22 Summary.........................................................................23

Executive summary Microsoft SQL Server databases typically contain some of the most critical and sensitive information of a business. Thus, it is essential that the data residing on these servers be rigorously protected. As Backup Exec provides continuous protection for Microsoft Exchange and Windows file servers and workstations, the Symantec Backup Exec version 11d Continuous Protection Server (CPS) provides continuous protection for Microsoft SQL Server. The protection helps ensure that SQL Server data is always protected and, in the unlikely event of system failure, always recoverable. CPS maintains real-time copies of databases stored in a safe location on the network. When the need arises, CPS: Benefits of the Continuous Protection Server SQL Server always protected Simplified SQL recovery SQL migration facilitated Restores an older version of a database to a SQL Server Restores the data to another working SQL Server with minimal downtime Migrates data from one SQL Server to another This paper discusses how CPS protects SQL Server databases, including procedures for protecting data in the scenarios listed above and maintained by Microsoft SQL Server 2000 and SQL Server 2005 (including SQL Server 2005 Express Edition). Symantec Backup Exec also makes it possible to back up copies of the database files from the Continuous Protection Server a capability known as off-host backup. About the Backup Exec Continuous Protection Server The Backup Exec Continuous Protection Server (CPS) uses continuous file-based replication combined with periodic snapshots of data to deliver continuous protection. It creates faithful copies of source files from one or more source SQL Servers (referred to as Business Servers) to a backup destination folder on a (Continuous) Protection Server (target). See Figure 1. CPS protects the data through user-created jobs. A system administrator creates a Continuous Protection job to maintain up-to-date copies of data from a Business Server on a Protection Server. CPS can also quickly restore the data from the Protection Server back to the original Business Server or to an alternate Business Server. The CPS has no explicit knowledge of databases such as those maintained by Microsoft SQL Server. However, it can still be used to make accurate copies of SQL Server databases on a Protection Server. It is important to note that CPS can continuously protect a collection of files, even while the files are being updated on the Business Server. For a database product such as Microsoft SQL 6

Server, this means that CPS continuously protects all the files making up one or more databases, even while the databases are being changed. It is not necessary to shut down or detach a SQL Server database for CPS to back it up to a Protection Server, increasing database and server availability while dramatically improving protection and delivering faster recovery. This section outlines the steps CPS takes to ensure a faithful, consistent copy of a database on a Protection Server. Source SQL Server Target File Server CPS Backup Figure 1. SQL to Protection Server scenario. Phases of a CPS job There are two phases to a CPS job: synchronization and dynamic. Together these phases help ensure a faithful copy via continuous protection of files on the target system. When a job starts, it synchronizes copies of files between the source and target servers. If a file exists on the source system but not on the target, the file is simply copied to the target system. If the file exists on both systems, CPS analyzes the differences in the files and sends the target either a new copy of the file (if the file is smaller than 1 MB) or updated portions of the source file (if file is larger than 1 MB). For large database files, the initial synchronization may take a relatively long time. If there is update activity in the source database during this time, sections of the data files may be updated on the source after those sections have been copied to the target. If this happens, the synchronized file copies may contain stale data at the end of the synchronization phase. CPS protects against this mismatch with the dynamic phase of protection. At the same time the source and target files are being synchronized, CPS starts the dynamic phase, which tracks changes to the files as they occur on the source system. At the end of the synchronization phase, changes to the source files are sent to the target system and are used to update the copies of the files on the target. The dynamic phase tracks changes to the source files in the order in which they occurred on the source system. Files on the target system are updated in the same order, maintaining write-order fidelity. In this way, the relationships between write operations and different files on the source system are preserved on the target. This is important, for instance, in preserving the order in which SQL Server writes to its database log and data files to ensure transactional consistency of a database. 7

Scheduled versus continuous protection A CPS backup job can be configured to protect files in several ways; the system administrator chooses the appropriate method for optimal protection. Any of the protection methods can be used with SQL Server data files. Scheduled protection. CPS starts a job at a user-specified time. The job synchronizes the source and target files, as previously described. When the synchronization phase finishes and dynamic updates have been applied, the job terminates. A job schedule can be configured to ensure that the source and target files are synchronized on a periodic basis. Using this method, the files on the target system represent snapshots of the source files at the time the job completes. The scheduled protection approach (also known as scheduled replication) is useful, for instance, to make daily or hourly copies of important database files. Manual protection. This method is similar to the scheduled protection option, but the job runs only when a system administrator initiates the operation. This method can be used for a one-time operation to protect files in order to migrate them to a different server, or simply to initiate a backup at a convenient unscheduled time. Continuous protection. If a CPS job is configured to run continuously, changes made to the source files are also applied to the target files. With continuous protection, the file copies on the target system represent live copies of the source files. A continuous job starts in the same way as a scheduled job: Source and target files are synchronized, then updates recorded by the dynamic phase are applied to bring the target files up to date. At this point, the synchronization phase is completed. But with a continuous job, the dynamic phase continues indefinitely, recording all changes to source files and applying them to the target files. No further synchronization is needed. Maintaining previous versions of protected data In addition to the live copy of protected data maintained by a Continuous Protection job, CPS creates periodic snapshots of the protected data, which enables the system administrator to recover previous versions of files. Within a CPS snapshot, the collection of protected files is preserved as it looked at a specific point in time. The system administrator can configure the frequency of snapshots, which determines how many past versions of files can be restored. 8

When a system administrator restores files comprising one or more SQL Server databases, it is important that the versions of all selected files match. When you select a group of files making up a SQL database, be sure to choose the ones with similar last modified dates to help ensure all the files relate to the same version of the database as a whole. Protecting SQL Server databases This section describes how to configure CPS backup jobs to protect the data in SQL Server database files continuously or in scheduled mode. Protecting user-created SQL Server databases A typical SQL Server installation manages a collection of several databases, including system databases such as master, model, msdb, and tempdb, as well as user-created databases. In many cases, protecting all SQL Server databases is not needed, and you can configure CPS to protect one or more user-created databases. Protecting multiple data files and log files SQL Server installations can vary dramatically from server to server. It is rare that the default setup of SQL Server will be followed. For performance and fault-tolerance reasons, the data files making up a database may be spread across multiple disks, and the transaction log files are usually kept on a different disk than the data files. The following procedure explains how to create a Continuous Protection job to ensure that all data is protected, including one with multiple source directories. Before creating a CPS backup job to protect the database files, complete the following: Install the CPS components, including only one Continuous Management Service (CMS); a Continuous Protection Agent (CPA) included with Agent for Windows Servers on each server that will act as a Business Server or Protection Server; and at least one CPS Administration Console. (See Installing CPS in the CPS Administrator s Guide.) Define and configure at least one backup destination, which is a specific volume on a specific Protection Server (target) that will hold the protected files. This backup destination must be on a different server than the one containing the SQL Server data files you want to protect. 9

When you create a backup job, the following additional information is required: Name and optional description of the job Location of the data to be protected (Business Server) Specific backup destination where the protected data will reside (Protection Server) Schedule for when the job will run (periodic, continuous, or manual) To create a CPS backup job using the wizard: 1. From the navigation bar, select Setup. 2. In the task pane, under Backup Job Tasks, click New backup job using wizard. 3. Review the text on the Welcome to Backup Job Wizard screen, then click Next. 4. On the Name the Backup Job screen, enter a name and optional description for the backup job. 5. On the Select a Backup Destination screen, select one of the defined backup destinations. This selection is the Protection Server where the data is backed up. 6. On the Select Data to Back Up screen, select the information you want to back up. In this case, select the SQL Server (source) on which the database is stored. Then select all the files making up the databases you want to protect. If your database is made up of files in multiple directories, add any additional database directories and/or database log directories to the protection job. 7. On the Select When to Backup screen, designate when the backup should occur (see Figure 2). The options are: Whenever a file changes. This option initiates continuous protection or backup of the folders and files. That is, data in a file or folder is backed up whenever changes are made to it. This job starts as soon as the user clicks OK. According to a schedule. This option enables you to set a regularly scheduled or periodic backup of the folders and files. If this option is selected, you need to define the backup schedule. This job starts if it is in the backup window and the user clicks OK. 10

Note: Backup job schedules are always shown in the local time of the user creating the backup job. If the backup schedule is for servers located in another time zone, the times specified must be converted to the local time. Initiate the backup job manually. This option enables you to back up the contents of the folder or file on demand. This job will not start automatically. Figure 2. New Backup Job Wizard (Schedule Step). 8. The Completing the Backup Job Wizard screen indicates completion of the protection job configuration. It also provides an option to create another protection job as needed. Verify that the Continuous Protection or backup job has been created by checking that it appears in the list of jobs on the Monitor view of the console. Note: Backup jobs can be modified in a number of ways, such as to include or exclude specific data, change the job schedule, limit bandwidth dedicated to a job, or add scripts that run before or after a job. For additional information on modifying jobs, see the CPS Administrator s Guide. 11

Protecting all SQL Server databases In some cases, it may be best to protect all SQL Server databases, including system databases containing SQL Server configuration information. One reason to protect all databases is if you make frequent changes to system tables, such as adding users to the syslogins table in SQL Server s master database. If you protect all databases, changes to system tables will be reflected in the protected data files. This option is often used when you run SQL Server on a CPS Business Server, named Machine A for example, but plan to restore all the data from the CPS Protection Server to a new Business Server named Machine B in case Machine A fails. There are several rules to follow when continuously protecting all SQL databases. Because the master database contains information on the structure of the SQL Server installation, it is important to complete all of the steps: If the installation of SQL Server on Machine A was given the path C:\Program Files\Microsoft SQL Server\MSSQL, then the installation of the SQL Server on Machine B must also be given the path C:\Program Files\Microsoft SQL Server\MSSQL. If the installation paths vary between servers, the master database will contain incorrect path information after the protection job, and the MSSQLServer service on Machine B will fail to start. See the Limitations section at the end of this paper for concerns specific to SQL Server 2005. All login credentials supplied during the original SQL Server installation on Machine A must be supplied during the installation of SQL Server on Machine B. When restoring all of Machine A s data to Machine B, the MSSQLServer service must be stopped on Machine B while the restore job is active. This allows the current information stored on Machine B to be overwritten. If the MSSQLServer service is running on Machine B when the restore job starts, the job will fail because the MSSQLServer service has the database files open on the target machine. Note: On the source machine, the backup job is able to read the database files, even if they are open on MSSQLServer service. This allows CPS to protect live databases, as previously described. Creating a CPS job to back up all SQL databases is similar to creating a job to back up user-created databases; follow the same steps described previously. The only difference is that the job must be configured to back up all directories containing SQL Server database files, including the directory containing the master database. 12

Multiple server instances With Microsoft SQL Server 2000 or 2005, multiple instances of SQL Server create multiple data directories with names corresponding to the name of the server instance. The naming conventions are different for each product. SQL Server 2000 instance names and paths The default installation of SQL Server has a server name that matches the name of the computer it s installed on. A default installation of SQL Server on a computer named CHEMIST has a SQL Server name of CHEMIST. Data files for this instance are installed by default in a directory structure in the following format: C:\Program Files\Microsoft SQL Server\MSSQL\DATA (The default SQL Server) A named instance installation of SQL Server has a two-part server name. The first part is based on the computer name and the second part is the instance name. For example, an instance named SQL2 installed on a system named CHEMIST has a SQL Server name of CHEMIST\SQL2. The installation directory structure looks like this: C:\Program Files\Microsoft SQL Server\MSSQL$SQL2\DATA (A named server instance, named SQL2) Each instance creates and runs a separate MSSQLServer service. Services for each instance contain the name of the instance. Continuing with the example above, the two servers have been installed and registered on one machine. Each will have its own MSSQLServer service in the following format: MSSQLServer MSSQL$SQL2 - (For the default server.) - (For the SQL2 installation.) 13

SQL Server 2005 instance names and paths For SQL Server 2005, the server naming conventions are the same as for SQL Server 2000. The default server name matches the computer name, and named instances have server names constructed from the computer and instance names. But the naming scheme for installation directories is somewhat different. Installation directories are named by their order of installation, and have no relation to the server instance names. For example: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA (The first installed instance of SQL Server 2005) C:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\DATA (The second installed server instance) Each instance creates and runs a separate MSSQLServer service. Services for each instance contain the name of the instance. Using our example, the two servers have been installed and registered on one machine. Each will have its own MSSQLServer service in the following format: SQL Server (MSSQLServer) - (For the default server instance) SQL Server (SQL2) - (For the SQL2 named instance) Restoring SQL Server databases This section describes how to use CPS to restore a SQL Server database. The files making up a database can be restored to the original SQL Server, or can be restored to an alternate server in case the original server has failed. Restoring a single database To restore a single user-created database to its original server, perform the following steps: 1. If the database is still online and you want to restore an older backup copy, use SQL Server management tools on the SQL Server system to put the database offline, or detach it. 2. From the CPS Management Console navigation bar, select Restore. 3. Select the computer where the database files originally came from. 4. In the Backup Folder pane, expand the folder structure to find the files making up the database you want to restore. 14

5. Select all the files you want to restore. Remember to include the primary data file (.mdf), any secondary data files (.ndf), and transaction log files (.ldf). If there are several versions of each file listed in the All Versions pane, select the version you want to restore for each file. Note: The selected versions of data files and transaction log files must match for a successful restore operation. 6. In the Restore Tasks menu group, select Restore Files. 7. A pop-up dialog will appear. Pick a job name for the restore job. 8. In the Restore to box, select the name of a server to restore the files to. This usually is the original SQL Server. 9. You can restore the files to their original folders (recommended) or relocate the files to a different folder structure. If you relocate the files, it is important to check the Preserve folder structure box so the file layout will mirror the original layout as much as possible. 10. If you are restoring an older version of the database files, also check the Overwrite existing files that are newer box. 11. Click the OK button, review the restore job properties, then click the Restore button. The restore job will start immediately. You can monitor its progress in the Job Monitor pane. When the restore job finishes successfully, the database files have been restored to their original location. To make the database available again, follow the post-restore tasks described in the next section. Restoring multiple databases To restore more than one user-created database at a time, simply follow the instructions for restoring a single database, but select all the files making up all the databases you want to restore. Remember to detach or put those databases offline if they are still online on the original SQL Server. 15

Restoring all databases To restore all databases for a particular SQL Server, including the master database, you must follow the procedure for restoring multiple databases and select the data files for all the databases on the SQL Server. You must also stop the MSSQLServer service if it is running on the SQL Server to which you are restoring the files you cannot restore the master database while the MSSQLServer service is running. When you restore all databases, the master database is overwritten with the saved copy. Because the master database records the names and locations of all the other databases served by a SQL Server installation, it is important to restore the database files to their original locations. Restoring them to an alternate directory path will not result in usable databases after the file restore job finishes. This is of particular concern for SQL Server 2005, where you may not be able to choose the full installation path. The Limitations section at the end of this paper gives more details. Post-restore tasks This section outlines the few steps that must be taken before restored databases can be brought online. It also suggests how clients can connect to an alternate SQL Server if you restored database files to a different SQL Server than the original. Attaching a restored database After restoring a database with CPS, you must reattach the database, or put it back online if the SQL Server is already aware of the database. With SQL Server 2000, you can use the sp_attach_db stored procedure or SQL Enterprise Manager to attach the database. With SQL Server 2005, you can attach the database using the CREATE DATABASE FOR ATTACH Transact-SQL statement or by using SQL Server Management Studio. Attaching a SQL Server 2000 database using the sp_attach_db stored procedure Syntax (See SQL Server Books Online for further information: http://msdn2.microsoft.com/ en-us/library/ms166020.aspx) sp_attach_db [@dbname =] dbname, [@filename1 =] filename_n [,...16] 16

Arguments [@dbname =] dbname is the name of the database to be attached to the server. The name must be unique. dbname is sysname, with a default of NULL. [@filename1 =] filename_n is the physical name, including path, of a database file. filename_n is nvarchar(260), with a default of NULL. There can be up to 16 file names specified. The parameter names start at @filename1 and increment to @filename16. Note: The file name list must include at least the primary file, which contains the system tables that point to other files in the database. The list must also include any files restored to a different directory than the original location. If all files were restored to their original locations, only the primary file needs to be specified. If the files were restored to an alternate location, you must specify all database files. Return code values 0 (success) or 1 (failure) Remarks If more than 16 files must be specified, use CREATE DATABASE with the FOR ATTACH clause. Permissions needed Only members of the sysadmin and dbcreator fixed server roles can execute this procedure. Examples The following example attaches a database with multiple data and log directories that was restored to an alternate location. If the database files are restored to their original location on the SQL Server, the primary file will contain correct information about where the other files (data or log) exist. If the location is different, each file will need to be listed within the stored procedure. The following example attaches a spanning database1 (4 data files and 1 log file) to the SQL Server. EXEC sp_attach_db Bank, E:\data1\Bank_branch_data.mdf, E:\data1\Bank_teller_data.ndf, E:\data1\Bank_account_data.ndf, E:\data1\Bank_history_data.ndf, E:\log1\Bank_log.ldf 17

Attaching a SQL 2005 database using CREATE DATABASE FOR ATTACH With SQL Server 2005, the recommended way of attaching a database is with the CREATE DATABASE FOR ATTACH statement, naming all the database files as in the following example: CREATE DATABASE Bank ON (FILENAME= E:\data1\Bank_branch_data.mdf ), (FILENAME= E:\data1\Bank_teller_data.ndf ), (FILENAME= E:\data1\Bank_account_data.ndf ), (FILENAME= E:\data1\Bank_history_data.ndf ), (FILENAME= E:\log1\Bank_log.ldf ) FOR ATTACH Attaching a SQL 2000 database using SQL Enterprise Manager With SQL 2000, you can use the SQL Enterprise Manager to attach a database, as shown in Figure 3. Figure 3. Attaching a database using SQL Enterprise Manager. With SQL Server 2005, use SQL Server Management Studio to attach the database (see Figure 4). 18

Figure 4. Attaching a database using SQL Server Management Studio. Restarting SQL Server after restoring all databases If you restored all databases, including the master database, you must restart the MSSQLServer service. In o, all files were restored to their original locations, so no attach procedure is necessary because the restored master database is aware of the locations of all the other databases. Client connectivity If an alternate SQL Server is brought online to host restored databases, the database clients must be able to access the alternate SQL Server. Two options are described below. Update ODBC on clients The server name for an ODBC connection is a registry value. A registry file can be created and distributed to clients to update the DSN value, and point to the new SQL Server. The best way to distribute the file is through a logon script. Be aware that this will most likely require either a logoff/logon or a reboot in order to kick off the registry file merge. The DSN registry entry can be found in one of the following locations: User DSN: HKEY_CURRENT_USER\Software\ODBC\ODBC.INI System DSN: HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI 19

Rename alternate SQL Server Alternatively, you can rename the alternate SQL Server. This is the easiest solution however, some issues could arise: If the alternate computer is used only for SQL Server, renaming the server most likely will not cause a problem; but if other software is installed on the system, renaming it could potentially cause problems. Below are the steps to follow in order to rename the system on which SQL Server resides. When you change the computer name, the new name is recognized during SQL Server startup, so you need not run Setup again to reset the computer name. You can connect to SQL Server using the new computer name after you have restarted the server. However, to correct the sysservers system table, you should manually run the following procedures (make sure the CPS job is stopped before running the sp_dropserver stored procedure): sp_dropserver <old_server_name> go sp_addserver <new_server_name>, LOCAL go The corresponding SQL Server service must then be stopped and restarted so the internal @@servername variable has the new value for the server name. Issues with remote logins If the computer has any remote logins, sp_dropserver may generate an error similar to this: Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44 There are still remote logins for the server <server_name>. To resolve this error, you may need to drop remote logins for this server. Additional applications for SQL Server protection with CPS So far, this paper has discussed the use of CPS to protect SQL database files to standby servers to guard against loss of a primary server. There are several other interesting uses for CPS protection of SQL databases. Comprehensive SQL data protection Because CPS is a disk-based solution, for best practices it is recommended that the Continuous Protection data be backed up to tape periodically for long-term data protection or disaster recovery purposes. In the event of data corruption or server failure, these backups can be used to restore 20

a database. In an enterprise with many SQL Servers deployed over a distributed area, it is usually desirable to employ a centralized backup strategy. With the speed and benefits of disk-based Continuous Protection and the impracticality of attaching a tape drive or library to each SQL Server centralizing all backups to a single media server, then periodically moving data off to tape serves as a well-rounded data protection strategy. SQL Server BE CPA Backup Exec Tape Library SQL Server BE CPA BE CORE BE CPS SQL Server BE CPA Figure 5. The Backup Exec Continuous Protection Agent (CPA) installed on the SQL Server. With the Backup Exec Continuous Protection Agent installed on the SQL Server, the data is continuous protected to the Backup Exec Continuous Protection Server (see Figure 5). The Backup Exec CPS can be protected and moved off to tape using Backup Exec for long-term data protection or disaster recovery purposes. With this method, backups are centralized; running a backup job to tape does not impact the performance of the SQL Servers. Migrating a database to a new server In order to expand capacity, you may want to move a database from its original server to a new one. This way, you can spread out the server load among more systems. You can use a CPS backup job to move the files making up a SQL Server database from the original server system to a CPS, then restore the database files to a new SQL Server. The steps are the same as described in the Restoring a SQL Server Database section for an alternate server. 21

Limitations There are a few limitations to using CPS to backup and restore a SQL Server database: Restoring fulltext catalogs is not supported. Fulltext catalogs must be re-created after attaching a copy of the database captured with CPS. Installations of SQL Server in a cluster are not protected, because CPS does not support failover in a Microsoft Cluster. In general, restoring the master database to an alternate server is not supported for SQL Server 2005. During installation of SQL Server 2005, you cannot choose the subfolder for installation. If you have multiple instances of SQL Server 2005, they are installed in folders named MSSQL.1, MSSQL.2, etc., so it usually is not possible to match the installation paths of the original server when using an alternate server. However, if you can match the SQL Server installation path exactly on an alternate server, then restoring the master database for SQL Server 2005 is possible. Replacing a SQL Server or volume when using CPS In the unfortunate event of a hard disk failure with the SQL Server, it is important that certain steps be taken to ensure that Continuous Protection data is not accidentally overwritten during the repair. Continuous protection is designed so that if a file included in a Continuous SQL Protection/Backup Job is deleted from the SQL Server (Business Server), the same file will be removed from the Backup Destination or Protection Server. When replacing a volume on a Continuous Protection SQL Server, the following is recommended: 1. If a hard disk failure is encountered on a Business Server, the Continuous Backup Job protecting it should be canceled and the backup method changed from a Continuous Backup Job to a Manual Backup Job before a replacement disk is installed. 2. After the replacement disk has been installed in the Business Server, the data should be restored from CPS. 3. Once restored, the data should be verified. 4. Only after the restored data has been verified should the original backup job be changed from a Manual Backup Job back to a Continuous Backup Job, and then started. For further information, we recommend reviewing Backup Exec Tech Note 284275 (http://support.veritas.com/docs/284275). 22

Summary Microsoft SQL Server databases often contain some of the most critical and sensitive information of a business. It is essential that the data contained on these servers be rigorously protected. Symantec Backup Exec 11d Continuous Protection Server (CPS) helps ensure that SQL Server data is always protected and, in the unlikely event of loss, always recoverable. Continuous Protection (or even scheduled protection) for mission-critical SQL Servers improves protection and speeds recovery times, so enterprises stay in business, conducting critical transactions and meeting the needs of their customers continuously. 23

About Symantec Symantec is a global leader in infrastructure software, enabling businesses and consumers to have confidence in a connected world. The company helps customers protect their infrastructure, information, and interactions by delivering software and services that address risks to security, availability, compliance, and performance. Headquartered in Cupertino, Calif., Symantec has operations in 40 countries. More information is available at www.symantec.com. For specific country offices and contact numbers, please visit our Web site. For product information in the U.S., call toll-free 1 (800) 745 6054. Symantec Corporation World Headquarters 20330 Stevens Creek Boulevard Cupertino, CA 95014 USA +1 (408) 517 8000 1 (800) 721 3934 www.symantec.com Copyright 2007 Symantec Corporation. All rights reserved. Symantec, the Symantec logo, Backup Exec, and Veritas are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other names may be trademarks of their respective companies. Printed in the U.S.A. 1/07 10753256