6\VWHP $GPLQLVWUDWLRQ 0DGH (DV\

Chapter 3: Backup and RecoveryBackupTransaction logs are critical to the database recovery. These logs contain a record of thechanges made to the database, which is used to roll forward (or back) operations. It iscritical to have a complete chain of valid log backups. If you have to restore and one log iscorrupted, you cannot restore past the corrupt log.Weekly Full BackupsIf the system crashes on Thursday, a log on Tuesday is corrupt. You can only recover tothe last good log on Tuesday. Everything after that is lost.Transaction log is stored in a directory, which must not be allowed to become full. If thetransaction log fills the available filespace, the database will stop, and no further processingcan be done in the database (and consequently) in R/3. It is important to be proactive andperiodically back up the transaction logs. Refer to the chapter specific to your database formore information.The frequency of the log backups is a business decision based on: Transaction volume Critical period(s) for the system Amount of data senior management is willing to lose Resources to perform the backups and take them offsiteAlso see the examples in the database section above.If your transaction volume is high, decrease the time interval between log backups. Thisreduced time interval decreases the amount of data that could be lost in a potential datacenter disaster.To back up transaction logs:1. Backup the transport log to disk.2. Copy the backup of the transaction log to an offsite backup file server.This backup file server should ideally be in another building or in another city. Aseparate location increases the chance that the log files will be preserved if the primarydata center (containing the R/3 servers) is destroyed.3. Back up the backup of the transaction logs on both servers (the R/3 server and theoffsite backup file server) to tape each day along with the other operating system-levelfiles.System Administration Made Easy3–5