Designing a Backup Strategy

Base the design of your backup strategy on the speed and amount of data you are adding to your databases. For example, you would have a different backup strategy for databases that rarely change than you would have for databases to which large quantities of data are continuously added. Consider each database separately, because Commerce Server uses each database differently. For example, your transaction database may change over one hundred times in a single day, while your Commerce Server Administration database may only change once a month. In this example, you would want to backup your transaction database more frequently, and your Administration database less frequently.

In addition to the frequency of change, you will also need to consider the availability needs of your databases. While it is important to backup your databases, it may also be important that those databases are accessible to users at certain times. If you are backing up production databases, you will want your backup to make as little impact as possible on the availability of your site.

You can back up directory data and configuration files to traditional media, such as magnetic tape, or to a separate local or network disk drive. Directories are frequently replicated to provide load balancing, high availability, and localized access in a distributed environment.

It is recommended that you back up SQL Server databases to physical drives that are separate from the drives that contain the databases. You can use RAID arrays to create a single logical drive for your backup, or you can use striping to write the backup to multiple drives. Backing up and restoring from tape takes a long time and the backed-up data is only current as of the time the backup was created. In most cases, it is better to rebuild a directory from peer replicas, because the data in the peer replicas is already online and the data is always current.

This section contains:

Copyright © 2005 Microsoft Corporation.
All rights reserved.