Planning for Site Maintenance, Backup, Archive, and Recovery

Published : September 1, 2004

During the planning phase of site deployment, incorporate planning for maintenance, backup and recovery as discussed in the next topics. You can use the Planning_Preparing.xls spreadsheet to track your progress:

On This Page

Planning for Minimum Risk and Impact of a Site Failure
Planning for the Simplest Recovery Operation Possible
Planning for Maintenance
Planning for Site Backup and Archive
Incorporating Backup and Recovery into the Test Lab

Planning for Minimum Risk and Impact of a Site Failure

The best failure prevention plan can only minimize the risk of failure, but it cannot completely prevent one. After you have developed an effective failure prevention plan, the next step in your recovery planning is developing a plan to minimize the effects of a failure, if one occurs.

To minimize the impact of a site failure, follow these recommendations when planning your sites:

• Invest in resources for the site server.

• Do not share computers running SQL Server between sites.

• Use multiple physical drives on the SMS site database server.

• Allocate multiple domain controllers.

• Set up multiple site systems with similar roles.

• Set up site systems on a computer other than the site server.

Invest in Resources for the Site Server

Site servers are the most important servers in SMS sites. In the event of a site server failure, your ability to manage the site’s clients is extremely limited. Even if you do not need the site server to create new site systems, the other management tasks that are no longer available make it almost impossible to manage the site.

Because of the importance of the site server, and the severe impact on the site in the event of failure, it is recommended that you invest resources in site servers to ensure their continued functionality.

While following the recommendations for site servers’ budget planning in the Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment document, to minimize the risk of a site failure, the budget must also be adequate in order to ensure that:

• The site server is running with high-quality, reliable hardware.

• The site server either has adequate replacement parts available or an identical server to which you can restore the backup snapshot of the site server.

• The site server is backed up frequently.

• The site server has adequate capacity to process data beyond the regular amount. Data accumulates during a backup cycle. When the backup is complete, the site server must be able to process the accumulated data.

• There is staff that is trained to perform live site recoveries so that you can always recover the site server quickly and reliably.

Do Not Share SQL Server Between Sites

SMS sites store data on a computer running SQL Server. Although multiple sites can share a single computer running SQL Server to store data, this is not a recommended configuration. From a recovery perspective, it is especially important for each site to use its own computer to run SQL Server on.

If a site that is sharing a computer running SQL Server with other sites fails, you must ensure that the recovery process of the failed site does not affect the other healthy sites. The recovery process becomes more complicated in this situation because you must isolate the recovery procedures to only the failed site.

Use Multiple Physical Drives on the SMS Site Database Server

Whether the site uses a local SQL Server or a remote SQL Server, it is recommended that separate physical drives be used for the SQL Server log files, the SQL Server data files and the computer’s operating system. If, for example, only the operating system drive fails then there is no need to recover the site, because SQL Server can continue to function properly after the operating system is restored.

Allocate Multiple Domain Controllers

For increased security you can configure SMS to use many accounts. If you configure your site that way, then if your site fails, you must be able to re-create the same accounts to successfully recover the site.

Account data is stored on domain controllers. To ensure that this information is always available to you, it is recommended that you allocate multiple domain controllers in your organization’s infrastructure. When you set up multiple domain controllers, you take advantage of the regular data replication process of domain controllers. If a site fails, you can retrieve the configuration of the site’s accounts from any domain controller on the network, and use that information to help recover the site.

When you set up multiple domain controllers, set each one at a different physical location and on different network segments. This minimizes the risk of all domain controllers in your organization becoming unavailable.

To further reduce the risk of not having account information, or if your site has a single domain controller, it is recommended that you store information about SMS accounts in a safe place, and update that information when you change accounts.

Set Up Multiple Site Systems with Similar Roles

SMS assigns site systems various roles to support different features of SMS. When a site system fails, you have limited use or no use of the feature. A recommended practice to help reduce the impact of site systems failure is to have site systems redundancy in your site.

This relies on the ability of SMS to create and support multiple site systems with the same role and the ability of clients to be able to use any site system to perform client operations. Regardless of recovery considerations, it is sometimes recommended that you set up multiple site systems with the same role in your site.

If a site system fails, having additional site systems that the client can use reduces the impact of failure from the client’s perspective. The client can locate another site system to use and continue to operate without interruption. This approach applies to all site system roles.

There are two ways you can take advantage of having multiple site systems with the same role:

• During the site architecture development stage, plan for multiple site systems with the same role. Also, plan to have an adequate number of site systems so that even if a site system fails at peak use, the remaining site systems have sufficient capacity to adequately support the clients until you recover the failed site system.

• If a site system fails, the load on the remaining site systems with the same role increases. The site continues to function and manage clients, but it might not perform as well because some of its capacity is lost. If the failed site system cannot be repaired quickly, and the site server is working properly, you can create additional site systems that the clients can use. From the client’s perspective, having additional site systems helps avoid delays.

Although there are benefits to adding extra site systems, the added servers will impact the overall load of the SMS hierarchy. You should consider the impact of the added servers on the overall network usage, especially bandwidth usage across WAN links, the impact on individual server performance, and the impact on existing SLAs such as delivering security updates across a WAN link.

If you chose to follow this recommendation, then you must plan for the added systems in the same manner that you plan for the rest of the site structure as outlined in Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment * *on Microsoft TechNet.

Set Up Site Systems on a Computer Other Than the Site Server

For some sites it is adequate to have only one site system with a specific role. For example, you might plan to set up only one CAP or only one distribution point for a site. From a recovery perspective, it is recommended that in this situation, you set up that site system on a computer other then the site server computer.

Setting up the site server and site systems on separate computers minimizes the impact of a site server failure on the site clients. If the site server fails, then site systems running on other computers can continue to provide their respective functionality to the site’s clients.

Planning for the Simplest Recovery Operation Possible

Even if you planned carefully and followed your plan to minimize the risk of failure in your site, the site still might fail. The recovery operation can be complex and can take a long time to complete. By planning ahead, you can simplify the process and reduce the time it takes to complete.

To simplify a potential site recovery operation, follow these guidelines when planning your sites:

• Include reference sites in the site hierarchy design.

• Allocate a server on which to set up the Recovery Expert Web site.

• Document design information, configuration data, and account passwords.

Include Reference Sites in the Site Hierarchy Design

During the planning phase, ensure that all sites, especially critical sites have child sites that can be designated as reference sites in a potential recovery operation.

During a site recovery operation, you restore the site’s backup snapshot. However, there can be objects that were created after the site was backed up. Therefore, even after restoring the backup snapshot, the site will not have those objects. Those objects exist on child sites because SMS regularly replicates objects to child sites; however, you can no longer manage them — you cannot delete or modify these objects, and they are considered orphaned.

In this case, a recovery operation can be simplified if the SMS Site Repair Wizard recovery tool can use reference sites to regain control of these SMS objects.

Allocate a Server to Set Up the Recovery Expert Web Site

To successfully recover a site, you must use recovery and repair tools that guide you through the recovery process and automate some recovery tasks. The Recovery Expert is an essential recovery tool. It collects information about your failure scenario and produces a list of tasks that you must perform to recover your site.

In order to use the Recovery Expert, you must first set up a Recovery Expert Web site. During the site planning phase, you need to allocate a server running Internet Information Services version 5.0 or higher to set up the Recovery Expert Web site on. Site administrators can then use Internet Explorer version 5.5 or later to connect to the Recovery Expert Web site and to run the Recovery Expert.

The number of servers that you allocate for the Recovery Expert Web site depends on the network design and domain security configuration in your organization. Ensure that every site can connect to at least one server that hosts the Recovery Expert Web site.

Document Design Information, Configuration Data, and Account Passwords

To correctly recover a site system, you must have all server configuration data available. You must configure the site system server exactly the way it was configured when it failed. If you do not, site recovery can fail. In this situation, it might be difficult for you to know why the recovery did not work.

To successfully recover a site, account passwords are required. For security reasons, in SMS 2003, accounts such as Client Push Installation Account, Site Address, site system connection accounts, and network access account are encrypted. As a result, when a site fails, these accounts are lost and cannot be retrieved during a recovery. During a site recovery, you will be prompted to re-enter these account passwords.

In order to simplify a potential recovery operation, document and store at a secure location any of the following information which is available during the planning phase:

• The hierarchy design. Include parent-child relationships, primary and secondary site locations, and information about the SMS site database server.

• Site configuration data from each SMS site server in your hierarchy. Include information such as feature settings, site systems, and component settings.

• List of designated reference sites.

• Passwords for the Client Push Installation Account, Site Address Accounts, Package Access Accounts, Site System Connection Account, and Advanced Client Network Access Account.

Not all of that information might be available at this phase. You can gather the rest of the information after the hierarchy is completely deployed.

Planning for Maintenance

In This Section:

• Developing a Maintenance and Monitoring Plan

• Maintenance Throughout The SMS Hierarchy

  • Task Automation

  • Sharing Custom Maintenance Tasks

  • Maintenance Groups

  • Monitoring Maintenance

• Documenting the Maintenance Plan

Developing a Maintenance and Monitoring Plan

There are resources that you can leverage in various ways for site maintenance. Those resources are provided by SMS, the operating system, or an application. Use the various maintenance and monitoring resources, such as predefined site maintenance tasks, and custom maintenance tasks to develop an effective maintenance plan for all sites in the hierarchy.

Besides backing up sites and running other maintenance tasks, a maintenance plan should include tasks to monitor SMS site systems regularly in order to detect software and hardware problems as early as possible. Monitoring hardware and software is usually done by examining status messages and log files. Monitoring the site server for hardware problems is especially important. If you take corrective actions at the first sign of a problem, you can often prevent a site failure.

For best practices of daily, weekly and infrequent maintenance tasks, see Daily, Weekly, and Periodic Tasks - Best Practices.

Custom Maintenance Tasks

SMS provides various predefined site maintenance tasks. SMS also allows you to create custom maintenance tasks by creating tasks that run valid SQL commands directly against the SMS site database. Any command that you can run in SQL Query Analyzer is a valid SQL command.

Custom SQL commands are very powerful because they directly manipulate the SMS site database. Improper SQL commands can corrupt the SMS site database. You should secure the SMS site database by limiting the Manage SQL Commands SMS object security right to the appropriate SMS administrators.

You can use the following SQL commands to create helpful custom maintenance tasks:

• The SQL DBCC (Database Consistency Check) command checks the integrity of the SMS site database. Schedule this task to run on a regular basis to detect database integrity problems early. Also, schedule this task to run before and after every site backup cycle.

• The SQL xp_sqlmaint command runs database maintenance tasks.

• The SQL sp_who command determines the number of SQL Server connections currently in use by SMS, or by any other process.

• The SQL sp_spaceused command displays the number of rows, disk space reserved, and disk space used by a table in the current database, or displays the disk space reserved and used by the entire database.

• The SQL sp_monitor command displays SQL Server activities and statistics.

To run a custom maintenance task, see To create and configure a custom maintenance task.

Maintenance Throughout The SMS Hierarchy

An SMS hierarchy can be very large and include many sites. Developing an individual maintenance plan for each site is not efficient. It is more efficient to consider the entire hierarchy when developing a maintenance plan. Developing a hierarchy-wide maintenance plan, instead of individual maintenance plans for each site, can reduce the overall maintenance workload and the overall maintenance expense.

This section describes strategies that help increase efficiency and simplify maintenance throughout the hierarchy.

Task Automation

You should automate tasks whenever possible by developing and running automation scripts. You can develop scripts that perform various maintenance and monitoring tasks. Those scripts can then notify you if any problems are encountered. You can run similar automation scripts on multiple sites.

You can automate maintenance tasks such as:

• Monitoring performance   Monitoring performance on each site server can be inefficient. Instead, you can configure either Microsoft, or non-Microsoft management tools and performance monitoring tools, to centrally monitor multiple system performance, and to send alerts, e-mails, or other notifications when certain error conditions are encountered.

  For example, you can implement Microsoft Operations Manager (MOM) to assist with monitoring multiple SMS site servers and other systems in your hierarchy. MOM can help you monitor all systems in one console.

• Checking for backlogs   Checking for component backlogs in SMS folders can be time consuming. Instead, you can use a third-party tool or develop a script that automatically scans all SMS folders throughout the entire hierarchy. The tool or script can search for file backlogs, files older than a set date, or files that are not valid. Configure the utility or script to send e-mail or another notification when certain error conditions are encountered.

Sharing Custom Maintenance Tasks

If you created custom maintenance tasks, then you can create similar tasks in other sites. After you have developed and tested the new custom tasks on one site, you can use a similar custom task at other sites.

Maintenance Groups

Define maintenance groups and develop a generic maintenance plan for each maintenance group. For example, you can define a secondary sites group. Develop a maintenance plan for the secondary sites in your hierarchy, and apply that plan to all secondary sites in your hierarchy. Maintenance groups can be based on geographical regions, site role, or site capacity.

Define groups as appropriate in your organization, and assign as many sites as possible to each group. That way, multiple sites can share a single maintenance plan.

Monitoring Maintenance

Develop a maintenance monitoring system to help you monitor the ongoing performance of maintenance tasks on all sites throughout the hierarchy. Especially in large hierarchies, it can be difficult to manually monitor maintenance activity at all sites.

You can use e-mail messages, status messages, or any other method that allows senior SMS administrators to ensure that all sites are getting their regular maintenance. Compare the maintenance activity to the documented maintenance plan for each site to ensure that all sites are well maintained.

Documenting the Maintenance Plan

After you develop a maintenance plan for all sites, document the details of that plan so that it is easy to review and update. Having a maintenance plan document also simplifies the monitoring of maintenance throughout the hierarchy. Documenting the plan is especially important in large hierarchies where there can be many SMS administrators. You can provide the plan document to the SMS administrators that are responsible for site maintenance to ensure that sites are maintained as planned.

For each site, the maintenance plan should include information such as the following:

• Which maintenance and monitoring tasks to perform

• How to perform each task.

• How often to perform each task.

• Who should perform each task

• How and where records about performing the tasks will be kept. Those records should include information about who performed each task, and when.

To help document the plan, you can use the following tracking sheet, or customize it as needed in your organization. You can also use this spreadsheet to later track the on-going execution of the maintenance plan.

MainTasksTracking.xls

Planning for Site Backup and Archive

For a complete site backup and archive plan, you must do the following:

• Plan for backup.

• Plan for archive.

• Develop a backup and archive strategy.

• Document the backup, archive and recovery plan.

Planning For Backup

In This Section:

• Ensure that the site’s data and the backup destination are on two separate physical drives.

• Ensure that the site server has adequate capacity to process backlogs generated during the site backup cycle.

• Scheduling considerations for the Backup SMS Site Server task

• Plan to back up the central site’s site control file frequently.

• Plan to back up files that the backup task does not back up by default.

• Back up throughout the SMS hierarchy.

Ensure That the Site’s Data and Backup Destination Are on Two Separate Physical Drives

When backing up a site, you need to decide if the backup destination will be on the local drive or on a remote drive. If you plan that the backup destination will be on the local site server, then it is beneficial to configure SMS so that the site’s data and the backup destination path are on two separate physical drives.

This ensures that the backup task runs faster because it reads the data that it is backing up from one drive and at the same time, it writes data to another drive. This practice is also safer because if one physical drive fails, then the data on the other physical drive is available.

Ensure That  the Site Server Has Adequate Capacity to Process Backlogs Generated During the Site Backup Cycle

While the backup task is running at the site, some site services are stopped, thus, data is not being processed. Therefore, plan for the site server to have adequate capacity to process the excess data after the backup cycle completes.

Scheduling Considerations for the Backup SMS Site Server Task

SMS is implemented in many different hierarchy structures, so it is not possible to have a single backup strategy that is appropriate for all hierarchies. Sites are different in their capacity, importance, and activity level. There is no single answer to the question, “How often should I back up my site?”

Obviously, when you back up data more often, there is less risk of losing data due to a site failure. However, backing up the site interferes with the site’s regular operations and requires more resources. You must weigh the needs of each site and determine the backup frequency.

Even when the site is backed up on a regular basis, some changes to the site might require additional site backups. Perform out-of-schedule site back-ups as needed.

Use the following guidelines to help you determine how often and when to back up your site.

How often to back up your site

• Back up your site frequently enough to avoid a large difference between the data in the backup snapshot and the site data at the time of a site failure. For example, on large, busy sites where SMS tasks such as site configuration changes and advertising new programs are continually performed, back up the site daily.

• It might be adequate to back up a low-key site once or twice per week. However, if the SMS site database is small, the backup task is completed quickly. Because the backup task in this case has minimal effect on the site while it is running, consider backing up that site on a daily basis, too.

• Back up your site at a frequency that does not cause the site to fall behind on site activities. The frequency depends on the activity level of the site. For example, if the site is busy for almost twenty-four hours every working day, then you might not be able to schedule daily backup tasks. In this case, you might be able to back up the site only on days with less activity.

• Back up your site so it is cost effective to your organization. Weigh the cost of spending resources on backup versus the cost of spending resources to handle partial data loss after a site failure. This applies to all SMS site systems.

When to back up the site

• The backup task must run when the site server and SMS site database are not being used. While the task is running, no process should access the SMS site server or the SMS site database. To avoid the risk of corrupting data, no data should be processed at that time.

• The backup task must run at a time that allows post-backup activities to be completed before the site must continue its regular operation. Schedule the task to run at a time that allows the backup task to be completed, and that allows the site to process any backlog that accumulated while the back up task was running.

• The backup task must run at a time in which it does not conflict with other site activities. Tasks that take a long time to finish, such as database maintenance tasks, should not be interrupted, if possible. Schedule these tasks so they are completed before the Backup SMS Site Server task is scheduled to start.

  Note
The site server computer must be running when backup is scheduled to run. Otherwise, the backup task does not run and there is a big gap between backups. This is especially important if the site backups are not very frequent.

Plan to Back Up the Central  Site’s Control File Frequently

From the perspective of recovery, the central site has two unique characteristics that are important during recovery:

• The central site is the only site in the hierarchy from which you can manage all clients in the hierarchy. Each site contains data of its own clients and of clients of lower level sites. The central site, being at the top of the hierarchy, contains data of all the clients in all the sites of hierarchy. By using the central site, you can target any management task at any client of any site in the hierarchy.

• The central site’s site control file is not stored at any other site’s database. SMS maintains an up-to-date copy of the site’s configuration file at each site’s parent site, providing a built-in mechanism to back up site configuration files. If you need to recover a site, you can get the configuration data of the site you are recovering from its parent site. This, of course, is not the case with the central site, which has no parent site.

The central site is the most critical site in the hierarchy, but if you need to recover the central site, a crucial piece of information for the central site (the site control file) might not be up-to-date because it is not continually copied to a safe location. The most up-to-date copy of the central site control file would be from the most recent backup snapshot of the central site. It is reasonable for you to plan to frequently back up the central site’s site control file.

Even if you back up the central site every day, plan to back up the central site’s site control file a few times during the day. Depending on the activity level at the central site, back up the central site control file often enough that any change to the site’s configuration is backed up.

Plan to Back Up Files that the Backup Task Does Not Back Up by Default

By default, the Backup SMS Site Server task does not back up the following:

• Remote Tools, Network Monitor, package automation scripts, or WMI. These components are not backed up because they are easy to reinstall. Plan to back up those files if there is a specific need for that in your organization.

    Note
  In SMS 2003, software metering data is integrated with the rest of the site’s data. There is no need to separately back up software metering data.

• Custom SMS files, such as custom SMS Administrator console files or custom MOF files, unless they are stored in directories that are being backed up.

• Any files related to site system roles that are set up on the site server. For example, the files related to a distribution point, or to a client access point (CAP).

Ensure that the site’s backup plan includes procedures necessary to back up any such custom files as needed in the site.

Back Up Throughout the SMS Hierarchy

You perform backup and recovery operations on individual sites. The SMS backup task can back up a single primary site or a single secondary site. To protect the entire hierarchy you must implement backup and recovery plans on each site in the hierarchy.

There is no single backup plan that is appropriate for all SMS sites. You must assess each individual site in your hierarchy and determine the backup requirements of that site, such as how often you need to back it up. Using that information, develop a hierarchy backup plan.

When you develop your hierarchy backup plan, consider the following:

• There is no advantage to simultaneously backing up all the sites in the hierarchy. You can back up and restore each site independently.

• Schedule site backups throughout the hierarchy so that the network is not flooded, and so that the backed-up sites continue to operate normally.

• Do not plan to make any changes to the hierarchy while backup is scheduled to run on any site server, because all services on that site server will be stopped when the site backup task starts to run.

Planning for Archive

After planning for site backup, you must also develop an effective archive plan for every site in the hierarchy.

Best practices for archive planning include the following:

• Ensure that a recent backup snapshot is always available by archiving the backup snapshot of every site in the hierarchy every time the site is backed up.

• Create several archives of the backup snapshot on removable media, and store them in different secure locations.

• Ensure ability to quickly retrieve the most recent backup snapshot from the archive location.

• Ensure that the archive plan of the entire hierarchy is cost effective for your organization.

To develop an effective archive strategy for your site, you must make the following decisions:

• Which equipment will you use to archive backup snapshots, tape drives, CD-ROM burners, or other specialized storage technologies, such as storage area networks (SANs).

• Is there adequate capacity in the link between the backup snapshot destination drive and the archive drive?

    Important
  The SMS backup task does not validate the data that it transmits over the network when backing up the site to a remote backup destination. However, when archiving the backup snapshot from the local site to a remote location  (for example, by using the Windows built-in tape backup utility), data validity checking can be incorporated to ensure that the archived backup snapshot is valid.
  This is strongly recommended for configurations with low quality network between the backup destination and the archive location (if the connection fails more than once a month.)

Coordinate the Archive and the Backup Schedules

Be sure to coordinate the archive schedule with the site back up schedule as follows:

• Schedule the archive of the SMS backup snapshots at least as often as the site back up task.

• Schedule the archive of the SMS backup snapshots and the site back up task so they do not run at the same time. If both activities run at the same time, your organization archive might not copy the SMS backup files while they are being written, or the backup task might not be able to write to the backup files while they are being archived.

Developing a Backup and Archive Strategy

After developing separate backup and archive plans,, you need to develop a plan of how the backup and the archive operations will run together to ensure a recent, valid backup snapshot of the site at all times.

Backup and Archive Strategies

When planning the backup and the archive operations for each site, it is important to tie both operations, so that together, they ensure always having a recent, valid backup snapshot of the site. When planning backup and archive throughout the hierarchy, it is sometimes beneficial to include multiple sites in one plan. There are a few parts of the backup and archive operations that you can decide to share between sites to increase efficiency.

With respect to sharing backup and archive between multiple sites, there are three basic backup and archive strategies that you can implement:

• Separate backup and separate archive:

  • Back up each site locally without sharing the backup destination between sites.

  • Archive backup snapshots separately.

• Separate backup and shared archive

  • Back up each site locally without sharing the backup destination between sites.

  • Share an archive destination between sites.

• Shared backup and shared archive

  • Share a backup destination between multiple sites.

  • Share an archive destination between multiple sites.

To choose the backup and archive strategy that is most efficient in your organization, you must assess each site. The following sections describe the decisions that you need to make, and the possible choices. Table 1.1 summarizes the advantages of each choice.

Backup destination on the local drive or on a remote drive

When you configure the SMS backup task, you must specify the backup destination, which is where the backup snapshot is stored. You can specify a local drive or a remote drive.

To make this decision, assess the following:

• The quality and speed of your network.

• The size and speed of the site server local hard drive.

• Security requirements.

• The estimated size of the backup snapshot.

Share a backup destination with other sites

The sites that you plan to back up to a remote drive can share a single backup destination. You can configure the backup task of multiple sites to use the same backup destination.

The SMS backup task uses the backup destination that you specify to create a folder structure that allows multiple sites to safely share the same location as their backup destination. The backup destination is set up so that it:

• Allows several sites to share a single backup destination.

• Prevents one site’s backup snapshot from overwriting another site’s backup snapshot in case there is an error.

Share an archive destination with other sites

Regardless of your plan to share backup destinations or not, you can plan to share archive destinations.

For the advantages of each possible choice, see Table 1.1 below.

Table 1.1 Comparison of Backup and Archive Choices

Backup destination location	Advantages
Local drive	Higher reliability because significantly reduces the risk of a corrupted backup due to network issues. Higher security because data is not transmitted over the network. Faster backup because: It is much faster to write to a local drive. When backing up the site database locally, SQL Server does not create a temporary copy of the database. Faster backups result in a shorter downtime for the site server. Allows you to incorporate data validation checks when archiving the local backup snapshot into a remote location.
Remote drive	Allows sharing of the backup destination. The site’s data and the backup snapshot are located on different drives. If one of those drives fails, the other is still available to retrieve the site’s data.
Share backup destination	Advantages
Shared	Allows sharing of archive. Reduced backup costs because multiple sites use a single high quality backup device such as, a high-capacity, high-speed tape drive. Simplified site configuration because multiple sites are configured to use the same backup destination. Simplified and less expensive archive of the backup snapshots because you archive only one location.
Not shared	Each site administrator has full control over the site’s own backup snapshot, for example over its security. If the disk on which the backup snapshot is stored is damaged, then only one site’s backup snapshot is lost.
Share archive destination	Advantages
Shared	Reduces costs of archive because multiple sites use a single archive device. Simplifies the archive operation.
Not shared	Each site administrator has full control over the site’s own archive, for example over its security.

Decide Which Backup and Archive Strategy to Implement

Each decision on these issues affects each backup and archive strategy differently. The following table illustrates the benefits that you gain, and the benefits that you lose with each decision:

Table 1.2   Benefits of Backup and Archive Strategies

Backup and archive strategy	Benefits of local backup destination	Benefits of shared backup destination	Benefits of shared archive destination
Separate backup & separate archive	Yes	No	No
Separate backup & shared archive	Yes	No	Yes
Shared backup & shared archive	No	Yes	Yes

Develop an effective backup and archive strategy that works in your organization to ensure that a recent backup snapshot is always available. When you do this, you simplify the recovery operation.

Documenting the Backup, Archive, and Recovery Plan

After you decide which backup and archive strategy to implement in your hierarchy, document the details of that plan so that anyone in your organization can review the plan.

Include an outline of the backup and archive plan of each site in the hierarchy deployment plan document. Include information such as:

• Backup and archive procedures and schedules.

• List the backup destinations that are shared between multiple sites, and the sites that share them.

• List the archive destinations that are shared between multiple sites, and the sites that share them.

• Outline the risks you expect, and how you plan to handle them.

• Document for each site its designated reference sites.

You can include other information, such as who decides that a recovery is needed, and who performs them. Include any information that is helpful in your organization.

Incorporating Backup and Recovery into the Test Lab

The best way to be fully prepared for a site recovery operation is to ensure that the site’s recovery plan is adequate, and that administrators are familiar with the recovery process. After you develop a recovery plan for your site, it is recommended that you perform periodic recovery tests.

You can perform recovery tests in the test lab that is used for the hierarchy initial deployment tests. A test lab is ideal for recovery tests because it represents the production environment, and it contains collections, packages, and advertisements similar to the ones at the production environment.

By performing recovery tests at the test lab, you can identify problems with your recovery plan and refine it to ensure that it is possible to successfully recover as many objects as possible in case a site fails. However, if your organization does not maintain a test lab, or if you cannot access a remote test lab, you might consider setting up a local test lab for recovery tests.

While planning for a test lab, ensure that the test lab is also prepared for recovery tests as follows:

• In the test lab, you should be able to use backup and archive procedures that are similar to the procedures which are planned to be used in the production environment. Ensure that the SMSbkup.ctl files at the test lab and in the production environment are similar. Ensure that if the AfterBackup.bat file is planned to be used in the production environment, then a similar file is used in the test lab.

• If you have designated reference sites, then designate reference sites in the test lab so they are similar to the designated reference sites in the production environment.

• In the test lab, allocate a server to set up the Recovery Expert Web Site to be used for the recovery tests, unless you plan to use the Recovery Expert Web site from the production environment.

• Configure site security in the test lab so it is similar to the security configuration in the production environment

For more information about setting up a test lab, see the Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment document.