Disaster Recovery for Microsoft Speech Server

Disaster Recovery for Microsoft Speech Server

What would happen if a natural disaster or simple hardware failure caused Microsoft Speech Server 2004 (MSS) to crash? Would you lose data? Could you recover? How long would it take? Having a well-planned disaster recovery plan is critical to protecting your company's valuable data.

A good disaster recovery plan ensures that you can quickly recover lost data. Develop your backup and restore strategies with appropriate resources and personnel, and test them. A disaster recovery plan should ensure that all your systems and data can be quickly restored to normal operation in the event of a natural disaster such as a fire, or a technical disaster such as a disk failure. When you create a disaster recovery plan, you prepare all the actions that must occur in response to a catastrophic event.

Note This topic explains which types of files you should regularly back up in order to recover from a loss of data in your Speech Server environment. It is not intended to be a step-by-step manual for developing a disaster recovery plan. You can find procedures and checklists for backup, restore, and disaster recovery in Windows Server Help (click Start, and then click Help and Support.)

Your disaster recovery plan is directly related to the deployment plan you implemented. As you think of disaster recovery, consider your deployment structure and its unique backup requirements.

• Is your deployment large-scale, handling thousands of calls per day, or is it small-scale, receiving relatively few calls?

• Does your deployment require that you back up audio log files, which can grow quite large? Do you have enough hard disk space to back up both log files and databases, and do you have the proper removable hardware to which you can transfer those files?

• What is an acceptable downtime limit for your deployment? Excessive downtime can lead to loss of sales, productivity, and customer goodwill.

• How will the disaster recovery be administered? Will several departments be responsible for various actions, or will it all be handled by one central administrator?

  Note For detailed deployment information and procedures, see Deploying Speech Applications.

Thoroughly test your disaster recovery plan before deploying Speech Server in a production environment. When testing, look for vulnerable areas by simulating as many possible failure scenarios as you can. Be sure to verify your disaster recovery plan through the simulation of a catastrophic event.

Your Speech Server disaster recovery plan should include regular backups of the following items:

To start the Windows Server backup utility (Backup), click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup. For more information about Backup, see "Backup overview" in Windows Server Help.

To start SQL Server Enterprise Manager, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager. For more information, see "SQL Server Enterprise Manager" in Microsoft Management Console (MMC) Help.

Note  This topic references Windows Server Help topics that are found in Windows Server 2003 Help and Support. The topic titles may vary in other versions of Windows Server Help.

Event Trace log files

Event Trace log (.etl) files contain Speech Server activity data and can grow quite large, particularly if they are configured to capture the audio spoken by the user. Microsoft Speech Server provides several log analysis tools that enable you to extract the data from .etl files and import it into a usable format, such as text file or a SQL database. For more information about these tools, see "Log File Extraction Utilities" in the Speech Application Log Analysis Help that is installed with the Microsoft Speech Application SDK (SASDK). Because .etl files accrue with Speech Server usage, you should regularly archive older files using Backup (selecting Normal as the Backup Type). By default, .etl files are stored on the MSS computer under C:\Program Files\Microsoft Speech Server\Logs\. Your disaster recovery plan should also include a company policy that sets the life span of archived files before they can be deleted.

Databases

The MSS log analysis tools use Microsoft SQL Server to import .etl file data, enabling you to obtain detailed results based on SQL queries. As part of your disaster recovery plan, back up your SQL database using SQL Server Enterprise Manager. Also, because this database grows with use, you should regularly delete older events from the database to keep it at a manageable size. You can do this either through Enterprise Manager or by using a stored procedure provided with the SASDK. For more information, see "Database Maintenance" in the Speech Application Log Analysis Help installed with the SASDK. If you have created other unique database tables that store events, you can modify the stored procedure or use Enterprise Manager to delete events from those tables as well.

Also, once the data from an .etl file has been imported to a SQL database, the MSS log analysis tools interact with the SQL database only. The .etl file is no longer required, and can be archived or deleted according to your company policy.

Application list file

The Speech Application Deployment Service (SADS) installs a file called applist.xml, which lists all applications to be managed by SADS. Use Backup to save this file as part of your disaster recovery plan. By default, applist.xml is stored on the SADS server under systemdrive:\Inetpub\wwwroot\MS_Speech_Deployment. For more information, see "Backing up and restoring data" in the Windows Server Help.

Registry settings

Microsoft Speech Server uses the Windows Registry to store property values and configuration information. If you have installed telephony interface manager (TIM) software, it may also modify your registry. Registry settings are part of your system state data that is backed up when you create an Automated System Recovery (ASR) disk set. To ensure that your most recent registry settings are backed up, use Backup (Advanced mode) to create an ASR disk set for each server in your deployment.

File permissions

When you save your files using Backup, the file permission settings are saved as well, provided the files are saved from an NTFS volume to another NTFS volume. You can restore these permission settings by using the Restore Security procedure in Backup. See "Set advanced restore options" in Windows Server Help.

Telephony interface manager log files

If you installed TIM software, it may create log files that should be included in your regular backup. You can do this using Backup provided you know the location of these TIM log files. For more information, see your TIM manufacturer's documentation.

Web applications

In the event of a disaster, you can reinstall your Web applications along with your other Speech Server requisites and programs. However, depending on its purpose, a Web application may access and modify files that contain volatile data which, if lost, would cripple your business. For example, imagine if a Web-based e-mail service were to lose the files that contain the user information and passwords for all of its customers. As part of your disaster recovery plan, be sure to identify and back up any volatile information that is created or changed by your Web applications.

Remarks

• Note the virtual directory structure on your Web server, and maintain the same paths upon recovery. This will hasten your recovery time considerably.

• Use Microsoft Windows Event Viewer daily to check both the system log and application log on your production servers for any errors or warnings.

• Maintain an up-to-date Windows Emergency Repair disk or ASR disk set for each server in your deployment. ASR is primarily responsible for capturing system state and does not backup data files. You can create an ASR set using the Advanced mode in Backup. For more information, see "Automated System Recovery (ASR) overview" in Windows Server Help.

• Make sure that all your servers are protected with antivirus software, and keep the software up-to-date with the latest virus signature files. Use the automatic update feature of your antivirus application to keep the virus signatures current.