Your database is always subject to the risk of possible damage. There are many reasons why data may be lost or become corrupted. Disks may crash, power may be cut off, users may make mistakes, viruses may infiltrate the system or, in the worst case, a fire or earthquake could totally destroy the system. It is therefore vital to work out a security strategy that protects your system against data loss and enables you to restore it to a correct and consistent state. The most important part of any security strategy is to backup the database and its transaction log at regular intervals. This means the data and log from the database must be copied to another storage medium. When the database is damaged, these data copies can be reloaded in order to restore the database to a correct and consistent state.

A backup can only effectively contribute to safeguarding your database, if it is performed as part of an overall backup and restore strategy. It is therefore important to first carefully work out a strategy and to test it before applying it in a productive system. It should define details such as the frequency of backups, what should be backed up at various times, which media are to be used and how backups are to be verified to ensure that they can be used for a later restore. When a strategy is planned, many different factors play a role. For example, it is important to take into account the transaction workload, the maximum permissible downtime, the available hardware and, in the worst case, the amount of data loss that is tolerable.

Once you have drawn up a backup strategy, you can begin to implement it. Both the MS SQL Enterprise Manager and the R/3 System provide the functions you need to define, schedule and execute backups and to perform other related tasks. Generally the procedure for backing up includes the following phases:

1. Definition and Scheduling of the Backup