Backing Up a Site

Published : September 1, 2004

Backing up your site on a regular basis is the main step when preparing for recovery. To simplify the backup operation and to ensure having a valid backup snapshot of the site, SMS provides the Backup SMS Site Server task.

On This Page

How the Backup SMS Site Server Task Works
Backing Up a Site Using the Backup SMS Site Server Task
Backing Up a Secondary Site
Backing Up the Central Site
Using Non-Microsoft Backup Tools to Back Up SMS Sites

How the Backup SMS Site Server Task Works

When the Backup SMS Site Server task backs up your site, it relies on input. It reads the configuration settings that you specified in the Backup Task Properties dialog box. These values determine when and how often the task runs.

The backup task also reads input from two files, the SMSbkup.ctl control file, and the AfterBackup.bat batch file. The first file is used for the backup operation itself, and is mandatory; the second file is used for after backup operations and is optional. You can edit both files to customize the backup operation to fit your site backup needs.

SMSbkup.ctl Contains site-specific information that the backup task requires. This file contains the names of the files, registry keys, and databases that need to be backed up. It also contains commands that run during the backup operation to gather configuration information. The SMSbkup.ctl file contains tokens that it uses during run time, such as the SITE_BACKUP_DESTINATION token. When the backup task runs and uses the default SMSbkup.ctl file, it backs up all data necessary for recovery. You can customize this file to address specific backup needs of your site, for example you can customize the file so the \SMS\inboxes folders are not backed up. SMSbkup.ctl is referred to as the backup control file.

AfterBackup.bat Allows you to archive the backup snapshot at the end of every backup operation. By default, the AfterBackup.bat file does not exist and therefore has no effect on the backup operation. You can create this file and add commands that run after the SMS backup task has finished.

For detailed information about the backup task, see Appendix C: The Backup SMS Site Server Task.

SMS_SITE_BACKUP Service

The SMS_SITE_BACKUP service runs on the site server to accomplish the backup task operation. For detailed information about the service, and how it works to back up a site, see Appendix C: The Backup SMS Site Server Task.

Effects of Backup SMS Site Server Task

When the Backup SMS Site Server task runs, it interferes with regular site server activity. To properly back up a site, the Backup SMS Site Server task stops the following basic site services:

• SMS_SITE_COMPONENT_MANAGER

• SMS_EXECUTIVE

• SMS_SQL_MONITOR

Without these services running on the site server, data arriving from clients is not processed. Also, you cannot perform some regular site operations, such as:.

• Troubleshoot client computers.

• Advertise new programs.

• Distribute new packages.

• Create new software licenses.

However, you can view reports.

When the backup operation is completed, the backup task restarts the basic site services that were stopped, and the site server returns to the state that it was in before the task started.

To follow backup best practices, it is recommended that you do not make any site configuration changes or initiate any site activity while the SMS backup task runs. This is because any site activity that you initiate is likely to slow down the backup operation, and your changes will be processed only after the backup operation is completed.

Effect on clients

The backup task running on the site server has very little effect on clients. Clients do not interact directly with the site server for most of their activities. They continue to interact with site systems such as client access points and distribution points, which are not affected by the backup operation. However, the site server does not process status messages and inventory data from clients until after the backup operation is completed.

Backing Up a Site Using the Backup SMS Site Server Task

By default, the SMS backup task is disabled. To successfully back up your site on a regular basis using the SMS backup task, you need to perform some manual tasks.

You need to initially prepare for the task before you enable it for the first time. After the task is configured and runs on a recurring schedule, there are tasks you need to perform every time the backup task runs, and then there are tasks you should perform periodically.

Initial Preparation Tasks

To initially prepare and to enable the Backup SMS Site Server task, do the following:

1. Customize the backup control file, SMSbkup.ctl, if needed.

2. Create and customize the backup batch file, AfterBackup.bat, to archive the backup snapshot, or to perform any other post-backup operations.

3. Enable, configure, and schedule the SMS Backup Site Server task.

4. Enable logging for the SMS Backup Site Server task.

Ongoing Tasks

After the Backup SMS Site Server task is enabled, you should perform the following tasks every time the task runs:

• Verify that the site is healthy every time before the backup operation starts

• Verify Success of the Backup SMS Site Server Task

• Manually back up any custom SMS-related files that are not backed up automatically by the backup task

• Document account passwords

• Archive the site’s new backup snapshot  (if you have not used AfterBackup.bat to do so automatically)

Periodic Tasks

Perform the following tasks on an in-frequent basis, as often as needed, depending on the implementation of backup and archive processes in your organization:

• Review the SMSbkup.ctl and the AfterBackup.bat batch file.

• Manually back up updated site data that the backup task does not back up. This includes data such as account data, and recovery tasks.

• Perform out-of-schedule site back-ups, as needed.

SMS Backup Task: Initial Preparation Tasks

There are some tasks that you typically need to perform only one time, before enabling the Backup SMS Site Server task for the first time. These tasks are as follows.

Use SMSbkup.ctl to Control the Backup SMS Site Server Task

This control file is required and a default file is included with SMS. It contains site-specific information that the backup task requires when backing up a site. This file contains site specific information about the data that needs to be backed up, and commands that gather configuration information during the backup operation.

When the backup task runs and uses the default SMSbkup.ctl file, it backs up all data necessary for recovery. You can customize this file to address specific backup needs of your site. SMSbkup.ctl is referred to as the backup control file.

Use AfterBackup.bat to Archive a Backup Snapshot

This batch file is optional and does not exist by default. It allows you to automatically run commands after the backup task is complete. An important use of this control file would be to archive the backup snapshot. To leverage the functionality of this file, you must create it first.

Enable and Configure the Backup SMS Site Server Task

By default, the Backup SMS Site Server task is disabled. To start backing up your site, you must enable and configure the task. You need to specify values, such as how often you want the backup task to run, and where to store the backup snapshot.

To enable and configure the SMS backup task

1. Navigate to Tasks in the SMS Administrator console.

Systems Management Server  ( Site Database   ( Site Hierarchy    ( <site code>-Microsoft     ( Site Settings      ( Site Maintenance       ( Tasks

2. In the right pane, double-click Backup SMS Site Server.

3. In the Backup SMS Site Server Properties dialog box, enable the backup task, and then specify the following:

   Schedule

   Specify the schedule for the backup task. Specify the day of the week and the time period for the task to start. The time period is the time interval in which the task can start, and it is defined by Start after and Latest start time.

     Note
   The time period must be at least one hour long, and it must start and end within a single day.

   The schedule that you specify is a recurring schedule. The task runs every week, on the day and in the time period that you specify.

   For information about scheduling considerations, see Scheduling Considerations for the Backup SMS Site Server task.

   Backup destination

   Enter a folder in which the backup task stores the backup snapshot. You can specify a local path or a remote path for the backup destination. In either case, the backup destination must exist, or be such that SMS can create it.

   The backup destination must be in one of the following formats:

   • A UNC path, such as \\Central\BackupSMS

   • A drive letter path, such as F:\\BackupSMS

   You cannot specify the backup destination to be within the SMS folder. Also, you must ensure that the backup destination folder has sufficient disk space and is secure, so that the site data stored at that location is protected.

Enable logging for the SMS Backup Site Server task

Use the SMS Service Manager to enable logging for the Backup SMS Site Server task. Check the SMSbkup.log file after every site back up to ensure that the site was backed up successfully.

SMS Backup Task: Ongoing Tasks

After the Backup SMS Site Server task is enabled and configured to run on a regular basis, you should perform the following manual tasks every time the task runs:

Verify that the Site is Healthy Before Site Backup Starts

To reduce the risk of corrupting the backup snapshot, before backup starts, verify that the site is healthy.

Review status messages, and log files if necessary to ensure that the site is properly functioning. To check the status of the SMS site database, you can schedule the following Database Consistency Check (DBCC) tests in SMS, or in SQL Server. On large, busy sites, the database tests might take a significant amount of time to be completed, so it is recommended that you schedule them to run on an opposite cycle from backup:

• DBCC checkdb

• DBCC checkcatalog

To find out if the DBCC tests encountered any problems, you must read the DBCC output file.

Verify Success of the Backup SMS Site Server Task

After the Backup SMS Site Server task is completed, verify that it was completed successfully. When it is successful, the backup snapshot that was generated is valid, and you can successfully use it if recovery becomes necessary.

Verify that a backup snapshot is valid by:

• Verifying that the time stamp of the backup destination folder, and the files in that folder, is the time that the backup task ran.

• Verifying that there are no errors logged in the SMSbkup.log file.

• Checking status messages for backup. The success status message reads, “Backup completed successfully.”

• Running DBCC checks from SQL Server after backup has been completed to verify that the database is intact. The assumption is that if the database is valid before the backup and after the backup, then the backup snapshot is most likely valid.

Manually Back Up Any Custom SMS-Related Files that Are Not Backed Up Automatically by the Backup Task

Manually back up any custom SMS-related files that are not backed up automatically by the backup task. Examples include custom SMS Administrator console files (.msc files) custom MOF files (such as SMS_def.mof), and any supplemental reports that are stored at reporting points under \Reporting Point\Supplemental, or under any other folder. If you use system tools to customize SMS site security, then you need to back up the security data of the site.

  Important
If the site server is configured with the Advanced Security mode and SQL Server is running on an operating system in the Windows Server 2003 family, then you need to manually gather configuration information from SQL Server. For more information about this issue, see article number 316360 in the Microsoft Knowledge Base Web site.

If the software update management feature is used, it is very important to back up the Definitive Software Library. The Definitive Software Library is valuable because it contains package source folders of software updates that have already been downloaded, tested and authorized for distribution. In addition, it contains the list of authorized updates for each software update package (in the Patchauthorize.xml file).

When recovering a site, if a backup of the Definitive Software Library exists, then you can easily restore it. If the package source folders for software updates are not backed up, you must use the Distribute Software Updates Wizard to recover software update management packages after recovering the site.

To automate the backup of any files that are not backed up by default, you can do either of the following:

• Store custom files under directories that are automatically backed up, for example, the SMS\Bin or the SMS\inboxes directories.

  -or-

• Add file commands where <source> is the path to the custom files to the SMSbkup.ctl file.

It is not necessary to manually back up data from site systems such as distribution points, management points, reporting points, and server locator points that are set up on the site server. This is because the site server can easily recreate them.

Document Account Passwords

For security reasons, SMS 2003 encrypts accounts such as the Client Push Installation Account, Site Address account, Package Access Accounts, site system connection accounts, and network access accounts. You need to document these account passwords so you can re-enter them during a site recovery operation.

Archive the Site’s New Backup Snapshot

Archive the site’s new backup snapshot (if you have not used AfterBackup.bat to do so automatically) to a removable media, and then store the removable media in a secure location. Ensure that you can quickly retrieve the archive in case it is needed for a recovery operation.

SMS Backup Task: Periodic Tasks

Although the backup task runs on a regular basis, there are a few manual steps that you need to perform on an infrequent basis. Those tasks are listed in this section.

Review SMSbkup.ctl and AfterBackup.bat

Review the SMSbkup.ctl backup control file, and the AfterBackup.bat file to ensure that they are still adequate and conform to the organization’s backup and archive guidelines.

Manually Back Up Updated Site Data That the Backup Task Does Not Back Up

The frequency of such backups depends on the frequency of updates to that data.

After updating information such as the following in the respective documents, back up those documents:

• Account information. Update the respective document with changes to accounts such as the Client Push Installation Account, Site Address account, site system connection accounts, or network access account. Back up that information. This is important so you can re-enter these passwords during a site recovery operation.

• Recovery tasks. If you store prepared recovery tasks from the Recovery Expert, then whenever there are changes to the site configuration, you should rerun the Recovery Expert with updated answers. Back up the resulting recovery tasks in a safe location

• New passwords. Whenever there is a change to the password of accounts such as the Client Push Installation Account, Site Address account, site system connection accounts, or network access account, you should note that change. This is important so you can re-enter these passwords during a site recovery operation.

• Back up the security data of the site If you use system tools to customize SMS site security, then you need to back up the security data of the site.

Perform Out-of-Schedule Site Backups

An out-of-schedule site backup might be necessary when performing certain operations on the site. For example, backing up the site server is a required step when swapping the site server computer. For the following site operations, backing up the site is not a required step, but it is important to back up the site before and after performing these operations.

Regardless of how you schedule the backup task, you should always have a recent backup snapshot before starting these operations. If the site’s backup snapshot is not recent, then before starting these operations, back up the site and ensure that the backup task has been completed. After completing these operations, back up the site again.

Occasionally, you might need to perform a major upgrade to a system on which an SMS site is running. Backing up the site prior to the upgrade ensures that you can revert the system to its previous state, in case the upgrade fails. An out-of-schedule backup operation might result in a backup snapshot that is not archived. This can happen if the archive has a set schedule. In this case, you should manually archive the backup snapshot.

These operations include:

• Upgrading the site’s database server or making configuration changes in SQL Server to items such as user connections, locks, and device allocation information (such as device size and type).

• Upgrading the operating system of the site server.

• Upgrading SMS. If you need to upgrade SMS, it is important to back up the site before and after the upgrade. Ensure that any custom files that the backup task does not back up, such as custom report files, are backed up as well.

    Important
  You cannot restore an SMS 2.0 backup snapshot to an SMS 2003 site. Use the SMS 2.0 backup snapshot only if the upgrade failed, and you plan to revert the system back to SMS 2.0.

• Modifying the site hierarchy.

• Running site reset.

• Upgrading the site from Standard Security to Advanced Security.

• Modifying the site’s accounts.

After you schedule the backup task in the SMS Administrator console, it can take up to 24 hours for the schedule change to take effect. In this situation, you can initiate a manual backup cycle by starting the SMS_SITE_BACKUP service on the site server.

Start the service to initiate a manual backup cycle after running SMS Setup, or to run an unscheduled backup when performing important configuration changes to the site. Such manual backup has no effect on the schedule of the backup task.

  Important
A manual backup cycle fails if Backup destination is not set in the Backup SMS Site Server Properties dialog box. You can set this entry even if the backup task is disabled for the site.

You can start the SMS_SITE_BACKUP service remotely by using the operating system services tool, or by using the SMS Service Manager if you have administrator-level access to the server.

Backing Up a Secondary Site

Secondary sites can be as significant as primary sites. Because secondary sites can also fail, you need to back them up. You back up a secondary site in the same manner that you back up a primary site, by using the Backup SMS Site Server task.

The main difference between backing up a secondary site and a primary site is the lack of an SMS site database at the secondary site.

When you back up a secondary site, the following differences apply:

• When you perform the steps in the “Backing Up a Site Using the Backup SMS Site Server Task” section, ignore the step that verifies database integrity.

• The backup task ignores the following entries in the backup control file when backing up a secondary site:

  • Database related commands: smssqlinfo and sitedbdump.

  • All backup commands in the [Tasks] section, in which the <source> is a database server.

  If you customize the backup control file, you do not need to remove the unnecessary database-related commands. When the backup task runs on a secondary site, it ignores these entries.

• When the backup task runs on a secondary site, it does not stop the SMS_SQL_MONITOR service because it does not exist on a secondary site.

Backing Up the Central Site

Backing up the central site is unique in the following ways:

• It is the busiest site in the hierarchy, leaving less time available to back it up.

• It has the largest amount of data that needs to be backed up, which increases the length of the backup operation.

As a result, you might attempt to reduce the risk of backlogs resulting from backup operations on the central site by planning to back up your central site less often. Because the central site is the most critical site in the hierarchy, this is not recommended.

Recovering the central site is unique in the following ways:

• On the central site, many configuration changes can be constantly made, and it might be impossible to repeat all of them.

• The central site does not have a parent site from which to obtain a copy of the site control file.

To resolve these issues, and to ensure that it is possible to recover all the data of the central site, follow these recommendations:

• Back up the central site frequently.

• Have a reference site for the central site, so that recovery tools can recover packages and advertisements created after the site is backed up.

• Have a copy of the central site control file that is as recent as possible.

  • Between site backup cycles, back up the central site control file frequently. You can use system tools or batch files to automatically back up the site control file frequently. To back up site control files, you can use the Hierarchy Maintenance tool (PreInst).

  • Store the site control file backup at the designated reference site.

  • Store the site control file with a *.CT0 format so that during recovery it is sufficient to rename the file, and drop it on the recovering central site.

If you follow these recommendations, then you will be able to recover most of the configuration when recovering the central site. You will be able to recover configuration data and software distribution objects definition from the reference site. The administrative data that is lost if the central site fails is less critical, and is regenerated after the central site regains functionality.

Using Non-Microsoft Backup Tools to Back Up SMS Sites

You can use a non-Microsoft backup tool, or you can write a custom script to back up your site. However, to successfully back up your site using such non-SMS backup tools, they must interoperate with SMS recovery functions by complying with the following guidelines.

To produce a valid backup snapshot, any custom tool or script must:

• Carry out the exact same tasks in the exact same order as they appear in the default SMS backup control file (SMSbkup.ctl).

• Back up the site as a snapshot of all data, at a time when the SMS site database is not actively accessed. Stop all processes that might access the site’s database, such as SMS services.

  If processes access data while it is being backed up, partially completed tasks can be in the backup. As a result, the data in the registry, the files, and the database might not be synchronized with each other. This can lead to problems after a site recovery.

• Produce a backup snapshot, identical in its directory structure and file names to the one produced by the default SMS backup task.

• Include, at a minimum, all the data produced when using the default SMS backup control file, SMSbkup.ctl.

The simplest and most reliable plan actually allows you to benefit from both the SMS backup task and a third-party archive tool. Use the SMS backup task to create a backup snapshot, and use a third-party tool to archive the backup snapshot to a secure location.