Show TOC

Backup TypesLocate this document in the navigation structure

This section introduces the different types of backups to protect your database data and log files, as well as the Windows configuration and objects from loss. It gives general recommendations for your backup strategy, which should comprise both the database and Windows backups. Keep in mind that the frequency and type of backups required vary widely. You need to find a solution that best fits your environment.

Database Backup

There are three main types of an SQL Server backup: Full database backup, differential database backup and transaction log backup. You can do all these backups when the database is online and you do not have to stop the SAP system.

The following subsections describe these database backup types in detail:

Full Database Backup

A full database backup contains all used data pages and the log files written during the backup. The transaction log is nottruncated when you perform a full database backup.

You always need a full database backup to restore the database. You cannot restore a differential database backup or a transaction log backup without a full database backup.

Full database backups may result in a significant amount of disk I/O and should therefore be performed at a time when the workload is low.

The data of the SAP, master, and msdb database must be backed up at regular intervals. These backups are essential to enable restore operations, if the database is damaged. In general, the SAP database <SAPSID> should be backed up once a day. It is sufficient to backup the master and msdb databases once a week or month, depending on the amount of database activity in your system. For administrative reasons, it is however easier to backup the master and msdb databases whenever you backup the SAP data. This hardly has an impact on system throughput as these backups do not require much additional space or time.

For backups that are regularly scheduled, use theDBA Planning Calendar of the SAP system.

For exceptional backups that are not part of the normal backup routine use theSQL Server Management Studio.

Differential Database Backup

A differential database backup contains only those data pages that have been modified since the last full database backup. Apart from this, a differential database backup is identical to a full database backup.

The size of a differential database backup is much smaller than the size of a full database backup. Differential database backups are optional. The backup strategy will become more complicated if it includes differential database backups. An example of integrating differential database backups in a backup strategy is to perform a full database backup only once a week and to perform differential database backups daily.

Note

Advantage of Differential Database Backups

Performing differential database backups after a full database backup has advantages.

It can reduce the number of full database backups that have to be performed. For example, a schedule requiring a daily full database backup could be replaced by a schedule requiring 1 full database backup at the beginning of the week followed by 6 differential database backups on other days of the week.

You can also use differential database backups to reduce the time necessary for a restore operation. By performing additional differential database backups between full database backups, the number of transaction logs that have to be applied in the event of a restore operation is reduced. Restoring data with a differential database backup is considerably faster than restoring data by applying logs.

Transaction Log Backup

The transaction log of the SAP database records all changes made to the database. It may never be deleted and must be backed up separately.

Transaction log backups save the log files. They are mandatory when you use the Full or Bulk-Logged Recovery Model since they are needed totruncate the log. Two subsequent transaction log backups do not contain redundant information.

Transaction log backups have almost no impact on performance and can therefore be performed when the workload is high.

SAP recommends that you schedule a transaction log backup every 30 to 60 minutes on a normal workday. If your SAP system(s) are used productively at weekends, schedule additional backups for weekends.

Note

When the disk system containing the transaction log crashes, it is impossible to backup the log that was in use at the time of crash. However, a backup of this log is necessary to restore the database to the state it had prior to the failure. It is only possible to return the database to the state it had at the time of the last transaction log backup. For this reason, SAP strongly recommends very frequent transaction log backups (every 30 to 60 minutes).

To work out the frequency of transaction log backups, also take the fill rate of the log into account. This depends on the size of the transaction log and the transaction rate on your system. Whenever a transaction log is backed up, it is truncated. This means old entries are deleted so that enough space is available for new entries. Consequently, if the log is not backed up frequently enough, it will grow until the disk is full and no more changes to the SAP database are possible.

To perform the transaction log backups, you use theDBA Planning Calendar in the SAP system, or alternatively, theSQL Server Management Studio.

Log Shipping

You can use log shipping to feed transaction logs from one database to another on aconstant basis. Continually backing up the transaction logs from a source database and then copying and restoring the logs to a destination database keeps the destination database synchronized with the source database.

You can use the Database Maintenance Plan Wizard to configure log shipping as a maintenance task that can be scheduled to run automatically at defined intervals.

Log shipping enables you to run a backup server and provides high availability as required by large enterprise systems. Log shipping requires extra administration and well-defined procedures to monitor the status of all log-shipping servers.

For details refer to SQL Server Books Online and SAP Note 493290.

Caution

Do not use log shipping to replace a robust and validated disaster recovery plan. It merely provides a high availability solution for large enterprise systems.

Full Windows Backup

A full Windows backup backs up the entire system including the database, SQL Server and Windows files. A Windows backup is only possible when the SQL Server is stopped because open files cannot be backed up. The database must be offline and the SQL Server shut down.

The backup of these files is necessary for a restore operation when the disk on which SQL Server and SAP executables are located crashes. In addition, it serves as an additional backup that may play a vital role in dealing with emergency situations where other routine backups have been damaged.

The Windows, SAP and SQL Server files need to be backed up:

  • After installing a Windows or SQL Server Service pack
  • Before special actions such as an SAP Upgrade

To perform a full Windows backup, you use the Windows Backup tool.

Note

For more information about backing up your SAP system on Windows, see Backing Up and Restoring Your SAP System on Windows, which is available in the SAP NetWeaver Library for your SAP release at:

Application Help   → System Administration and Maintenanace Information → Function-Oriented View   → Solution Life Cycle Mangemen → Backup and Recovery → Backing Up and Restoring Your SAP system on Windows

Caution

Never use a full Windows backup for regular database backups that are part of a predefined backup and restore strategy. When you restore such a Windows backup, the database and transaction log files are restored to the state they were at the time you ran the Windows backup. No subsequent differential or log backups can be applied. Therefore you cannot do a point-in-time database recovery. This means that the changes you made to the database since the last Windows backup are lost and cannot be redone. Instead, always use SQL Server-based backups for regular database and log backups.