Chapter 87: Overviewing Windows NT/Database Backup and Recovery

Overviewing Windows NT/Database Backup and Recovery Introduction
Chapter 87: Overviewing Windows NT/Database Backup and Recovery

Contents
Introduction............................................................................................................................................................................................. 871 Offline and Online Backups ............................................................................................................................................................... 872 Recommendations ............................................................................................................................................................................ 872 Archive Backup....................................................................................................................................................................................... 875 Restoring with SAPDBA: Check (and Repair) Database ....................................................................................................................... 875 Requirements.................................................................................................................................................................................... 876 Reviewing General Rules for Database Recovery.............................................................................................................................. 876 Reviewing Backup Speed....................................................................................................................................................................... 877 Defining Backup Frequency and Schedules.......................................................................................................................................... 877 Defining Oracle Redo Log Management and Archives ......................................................................................................................... 878 Defining Backup and Archive Storage Management............................................................................................................................. 878 Verifying Backup Strategy...................................................................................................................................................................... 879 Choosing and Implementing a Backup Strategy ................................................................................................................................... 879 Backup and Archive Procedures and Polices ......................................................................................................................................8710 Backup.............................................................................................................................................................................................8710 System Environment.................................................................................................................................................................8710 Policies.....................................................................................................................................................................................8711 Procedures ...............................................................................................................................................................................8713 Roles and Responsibilities........................................................................................................................................................8714 Recovery..........................................................................................................................................................................................8714 System Environment.................................................................................................................................................................8714 Policies.....................................................................................................................................................................................8714 Procedures ...............................................................................................................................................................................8715 Roles and Responsibilities........................................................................................................................................................8715
Introduction
Possibly the single most important aspect of the basis implementation is the establishment of an effective backup strategy. You must be able to restore the database in the event of any type of error. The strategy you implement for backups should be manageable. For example, it should be clear to operators what tapes should be mounted and when, so that mistakes are unlikely. The chosen backup strategy should not have an adverse impact on daily business. SAP provides two easy-to-use interfaces for performing a backup: SAPDBA on the operating system level, and CCMS-DBA on the R/3 level. ORACLE also offers two types of backup: online and offline. Backups can be performed at any of the following levels: database - full backup, all data files are saved tablespace - partial backup, data files of one or more tablespaces are saved data file - one or more data files are saved
1996 SAP Technology, Inc.
871
Our recommendation: Whenever downtime has to be minimized, we recommend that you use online backups (only offline backups cause system downtime).
Offline and Online Backups

Offline During an offline backup, either the whole database or parts of it won t be available for use. Offline backups are usually done at the database level. Therefore BRBACKUP (the SAP backup utility) only supports offline backups at the database level. Once the database is closed, a full backup is done that is, all data files, all online redo log files and at least one control file are backed up. Offline backups at the tablespace level are not advisable in an integrated environment like R/3, because the application modules require access to data in several tablespaces. If one tablespace is not available, most application modules will not be able to continue. The advantage of performing an offline backup is that the data can be restored and the database opened without performing a recovery. The major disadvantage is that the database cannot be used while the backup is running. Online An online backup is more appropriate for large databases. An online backup may be a full or a partial backup. The backup includes all or some of the data files and a control file. The offline redo log files generated while the backup was done need to be available as well in order to use the backup. The advantage is that the database is available for normal use while the backup is taken. Two disadvantages of the online backup are: 1. Deterioration in performance: The DBMS performance deteriorates because more redo log information is generated while the backup is running. For example, an online backup running alongside a background job with batch input causes the run time of the background job to increase considerably. Therefore, you should perform online backups during times of low system load. 2. Backed up data files without the redo log files are inconsistent: If used for a recovery, the online backup must be supplemented with the redo log files archived during the backup. To ensure that the last online redo log file from the backup is safely archived, you should perform a redo log switch immediately after the backup. An online backup done with SAP's BRBACKUP tool does this automatically. You can perform an online backup as follows: First, run BRBACKUP to save data files. Then run BRARCHIVE immediately afterwards to save the archived redo log files belonging to the backup.
Recommendations
Determine whether offline or online backups or both will be used Backup at the tablespace level Increase frequency of backups
872
Increase backup frequency of heavily used tablespaces Do backups in parallel Adjust backup frequency by carrying out tests Skip index tablespaces to reduce backup downtime Back up to disk first Backups with mirrored disks can be made offline Use hardware compression with the backup Assess your tape devices Verify that your backup tapes are readable Determine whether offline or online backups or both will be used You should carefully consider whether you need to use offline or online backup. Use online backup if downtime cannot be tolerated or if your database is very large and would take too long to back up offline. Backup at the tablespace level If you have decided that a complete backup takes too long, use backups at the tablespace level. For example, if the database is comprised of 20 tablespaces, back up 4 every nights Monday through Friday (which is equivalent to one full backup a week). Here, the worst case would be that a tablespace damaged on Sunday would have to be recovered from last Monday's backup. Increase the frequency of backups More frequent backups lead to a shorter recovery time and therefore shorter downtime. One compromise would be to make less frequent full backups, (for example, one full backup on Sunday) and more frequent partial backups (for example, backup one third of all tablespaces Monday, another third on Tuesday, the last third on Wednesday, and start over for Thursday, Friday, Saturday). Here, the worst case would be to have to use a backup which is 3 days old. Increase backup frequency of heavily used tablespaces It is wise to back up heavily used tablespaces more often (for example, by including them twice in a backup cycle). The reason behind this is that heavily used tablespaces put more of a load on disk drives, thus increasing the frequency with which they fail. The more often such tablespaces are backed up, the more likely a recent backup is available to be used in a recovery. Do backups in parallel Offline and online backups can be done in parallel to increase throughput. For example, if partial online backups of tablespaces are done (see example above), you can also schedule the backups of several groups of tablespaces to run in parallel, utilizing multiple devices. BRBACKUP supports parallel backups. Adjust backup frequency by carrying out tests There is no rule of thumb to determine the backup frequency. Suppose, for example, a test showed that to apply 3 redo log files to a restored full backup took 15 minutes (that is, 5 minutes recovery time per archived redo log file) and assuming 20 redo log files are archived on average a day, then a recovery from a 3 day old full backup would take 3 * 20 * 5 minutes = 300 minutes (or five hours). If, as in this example, a
873
recovery time of five hours is too long, more frequent backups can be taken (or other techniques such as mirrored disks can be used). Skip index tablespaces to reduce backup downtime To improve backup performance, consider skipping index tablespaces completely from your backups. An index tablespace contains only indices, which can always be rebuilt if required. If index tablespaces are not backed up, the Reorganize tablespace and data files function of SAPDBA should be used to generate the scripts needed to create the tablespaces and indexes if they have to be rebuilt (this function can be stopped after the scripts have been generated, before the actual reorganization takes place). The scripts should be recreated every time that index structures or index tablespace structures have changed. You should monitor to make sure that no tables are accidentally residing in an index tablespace. If a table resides in an index tablespace it should be reported by SAPDBA during the creation of the reorganization scripts. If a table has been 'misplaced', you should move it back to the appropriate data tablespace. The recommendation to omit index tablespaces from backups is only valid if no tables reside in these tablespaces. Back up to disk first If sufficient disk space is available, consider backing up to disk first. A disk backup is usually faster than a tape backup because disk devices are generally faster. You can then copy your backups from disk to tape without incurring downtime. If possible, retain the disk backup copy since a restore from disk is faster than from tape. Note that this assumes that the disks are not mirrored: with mirrored disks other options are available (see the next recommendation). Backups with mirrored disks can be made offline In the case of mirror disks, online backups are no different from backups of non-mirrored disks. If you wish to do offline backups in a mirrored disk environment, we recommend the following approach: First, shut down the database and split the disk mirror. Then restart the database on just one disk set. Finally, mount the second disk set onto another system on which you will perform the offline backup. If the database is backed up this way, it is not recommended to use BRBACKUP, because the BRBACKUP log information will be incomplete on the original system. After the backup is done, the two disk sets have to be re-synchronized. The downtime incurred with this method is the time taken to shut down the DBMS, split the mirror and then restart the DBMS. It may take a substantial amount of time to re-synchronize the two disk sets, leading to severe degradation of performance. This method has the disadvantage that the database is not mirrored during the backup. If it is considered a high priority to have disk mirroring all the time (for protection against disk failures), this technique can be safely deployed if three-way mirroring is used. Use hardware compression with backups You should consider using hardware compression with backups. It cuts down backup time by as much as 50%. If the backup must go to tape directly and be done online, consider using multiple tape drives for parallel backups to shorten backup time.
874
Overviewing Windows NT/Database Backup and Recovery Archive Backup
Assess your tape devices It pays to think about what kind of tape devices you are using for backing up your database since this will determine the downtime in the case of offline backups. To give you some idea of this, the capacity of tapes currently ranges from 2 to 30 GB and the speed of data transfer ranges from 1 to 10 GB per hour. Verify that your backup tapes are readable You should verify that your backups can indeed be successfully used for a restore. Use a separate system from the live production system. To carry out a test, you may want to restore the data files of the system tablespace, rollback segment tablespace, temporary tablespace and a tablespace of your choice, plus control files, online redo log files and archived redo log files. Mount the database, take offline all data files that were not restored, recover the database and then open it. If successful, this is proof that the restored files can be used.
Archive Backup
You should regularly (weekly, for example) perform a full backup of the off-line archived log files. These files are crucial to the recoverability of the database should a database failure occur. Because these files are so important, SAP recommends that two copies of the archive logs be saved to tape. The archive utility (called BRARCHIVE) supports this process. If you have configured your system according to the SAP recommendations, the ORACLE system will save the online redo log files (where the changes made to the database are recorded) automatically (offline redo log files are written). If you have not changed the standard profile init<DBSID>.ora, the offline redo log files are contained in the archive directory <ORACLE_HOME>\saparch. To perform a recovery of the database, the redo log entries must be available in their original, uninterrupted sequence. Therefore, it is essential that you protect the offline redo log files written by the ORACLE system against loss. Moreover, a database shutdown may occur when no more space is available for new offline redo log files in directory <ORACLE_HOME>\saparch (archive stuck). For this reason, you should regularly archive the offline redo log files to a volume (tape). The SAP utility BRARCHIVE is provided for this purpose. When you select Backup archive logs, SAPDBA calls the SAP program BRARCHIVE. You can, of course, directly archive the offline redo log files by simply calling BRARCHIVE. You can also use the Computing Center Management System of R/3 to plan an archive of the offline redo log files, start it, and then view its log. See the online help for the Computing Center Management System.
Restoring with SAPDBA: Check (and Repair) Database

The task of the SAPDBA recovery function is to remedy certain media and user errors. When such an error occurs, it usually involves the loss of database files, which can contain many different types of objects: ORACLE Dictionary segments, temporary segments, rollback segments, or user segments (tables and indices). SAPDBA supports restoring the database after the loss of the following files: Data files of the SAP tablespaces (PSAP<name>D/I) Files of the system tablespace (SYSTEM) Files of the rollback tablespace (PSAPROLL) Files of the temporary tablespace (PSAPTEMP)
875
Overviewing Windows NT/Database Backup and Recovery Restoring with SAPDBA: Check (and Repair) Database
The menu item Check (and repair) database only enables recovery of the database up to the current time. If you want to restore an older version of the database or perform a point in time recovery, please use the Restore/Recovery function.
Requirements
The SAPDBA recovery function works closely with the BRBACKUP and BRARCHIVE programs. In the restore phase, the copies of the database files and archive logs created by these programs are restored by BRRESTORE. The BRBACKUP and BRARCHIVE logs contain information on the directories or data media in which these files are stored. In addition, if you used a non-SAP backup utility (connection via BRBACKUP/BRARCHIVE), SAPDBA is also provided with the backups required for a recovery. The following requirements must be met to run an SAPDBA-assisted database recovery successfully after media or user errors: The complete, undamaged BRBACKUP and BRARCHIVE logs must be available for SAPDBA to determine the location of the database files and archived redo log files. (Always make sure that a sufficiently large number of logs are available, i.e., do not delete the logs too soon.) Undamaged copies of the lost database files must be available. Undamaged copies of all redo logs that were written between the point when the database copy used for the recovery was created and the point when the media error occurred must be available. The control file and all copies of this file must be available in undamaged form. If this is not the case, you will have perform the actions necessary to bring about the required situation. In each case at least one member of the online redo log groups must be available in undamaged form. In other case you have at first to perform the corresponding actions to rebuild the necessary redo logs. SAPDBA determines whether any copies of the online redo log files are missing or damaged. If so, you receive a corresponding warning message, but can still execute the recovery. It is important to deal with this at an appropriate time. Refer to the ORACLE documentation. If these requirements are met, recovery can often be executed automatically using the SAPDBA recovery function. The recovery option should only be used by an experienced database administrator on his or her own responsibility. Make sure that only the database administrator is authorized to use the expert mode (see SAPDBA: Expert mode). If in doubt, please contact an experienced coworker or SAP directly if your database requires recovery.
Reviewing General Rules for Database Recovery

Use the items in the following list as a rule of thumb for database recovery: A detailed discussion of the subject of backup and recovery can be found in the ORACLE Backup & Recovery Handbook by Rama Velpuri, published by ORACLE Press. As long as you have adhered to a proper data backup strategy, it should always be possible to restore your database to a complete and consistent status. Depending on the knowledge and experience of your administrator, you may need to call on external help. The CHECK AND REPAIR scenario of the sapdba process supports the normal case for restoring the database. You should note that R/3 operation is not possible while the database is being restored.
876
Overviewing Windows NT/Database Backup and Recovery Reviewing Backup Speed
Any recovery options that lie outside the scope of the CHECK AND REPAIR scenario should be attempted only after careful checking and preparation.
Reviewing Backup Speed

How long will a backup take (and what can I do to speed it up)? The following table of various tape devices should give you a rough idea of backup rates for certain common devices. Tape size DAT (DDS-2) IBM 3490 DLT IBM 3590 Capacity 2-7 2 GB GB Rate 1-2 GB/h 5-10 GB/h 3-6 GB/h 5-10 GB/h
10-15 GB 20-30 GB
Note that due to various system limits (system bus, cpu, controllers), you cannot expect perfect scalability from these devices (that is, you cannot expect 10 DLT drives to backup 60GB/h). Certainly hardware speed is one area in which the customer should work with hardware vendors to obtain an optimal solution.
Defining Backup Frequency and Schedules

How often should backups be performed? The ideal solution here is to perform a complete backup on every day in which there is activity in the database. An SAP customer should only step back from this solution if absolutely necessary (because the database is too large and the "backup window" too small, for example). The following list shows you the ideal strategy for backup activities: 1. Backup up your complete database every day on which you have online activity. 2. Make double copies of your redo logs. 3. Keep redo logs going back to your last complete backup (or oldest of your partial backups) available on disk. 4. Use an expiration date of at least 28 days on all tapes (database backups and redo log archives). 5. Keep at least 5 backup generations (but more is better). 6. Store tapes at a secure off-site location. All backup strategies are either implementations of the Ideal Strategy or variations of that strategy forced by the given conditions at the customer site (VLDBs or very high availability demands, for example). The questions you must answer here are: What (if any) periods in the week is the system fully available for administrative activities? During which (if any) periods can the system, though online, handle the added load of backup being performed? How long does it take to backup my entire database?
877
Overviewing Windows NT/Database Backup and Recovery Defining Oracle Redo Log Management and Archives
Do I have the media capacity for unattended backups? How much redo log volume is expected between backups? Do I have ample (at least double) disk capacity for handling this redo log volume in my archive directory?
Defining Oracle Redo Log Management and Archives

When should redo log archives be performed? How can I guarantee that I will never lose a redo log? How can I prevent an archive stuck situation? How can I reduce recovery time? Redo log management overshadows almost all other DBA activity: every day hundreds of megabytes of redo log information gets written and must be saved. If redo logs are lost, there is danger of real loss of data in a restore situation. If they are not backed up and cleared from the archive directory, the archive directory can fill up completely and cause the entire database to freeze, resulting effectively in down time for all users. On the other hand, by holding the redo logs going back to the last backup on disk, one can speed up a recovery, since only damaged datafiles need then to be restored from the backup media. The following is a simple and effective redo log archive strategy: 1. Provide generous disk capacity for your archive directory (at least double your expected redo log volume between backups). Depending on the amount of activity on the customer system, this could be several gigabytes of space. 2. Provide capacity in your backup media for unattended archives of your redo log files. Ideally you should be able to schedule a complete backup of your system followed by saving two copies of the redo log files. 3. Using brarchive options, you can set up a strategy which leaves one day s worth of redo logs on disk after they have been backed up. To help ensure that you will never lose redo logs, use the brarchive option which creates double copies of each log. 4. Using the alert monitors and training measures for MIS personnel you must guarantee that the archive directory never fills up, whether due to unexpectedly high change volume in the database or errors in the last archive run. Note that there are other equally valid strategies available. You can start brarchive in continuous mode, for example: the program then runs and archives each offline redo log as soon as it has been written to the archive directory. You may also prefer to run your archives manually at regular times each day.
Defining Backup and Archive Storage Management

How long should the customer keep backups? How many generations should the customer keep? How should the tapes be labeled? Where should the tapes be kept? 1. Expiration dates and generations We recommend an expire date of at least 28 days for both database backups and redo log archives. We have had customers ask us whether they really need to keep more than two generations of tapes. We remind them of the issue, namely: what we are trying to avoid is a complete and irreversible loss of your business data. There is no SAP customer so small that their business data is less valuable than a month s worth of DAT tapes.
878
Overviewing Windows NT/Database Backup and Recovery Verifying Backup Strategy
2. Volume labeling A good strategy for volume labeling can provide you with increased security, especially if relatively untrained operators will be mounting tapes. With proper planning, for example, you can label your tapes with the day of the month (C11B24A, C11B24B, and C11B24C, for example, for the C11 Backup on the 24th of each month, volumes A, B and C). Such a strategy helps guarantee, for example, that the correct tapes are retrieved from off-site for the daily backup. (These considerations do not apply to users of backup management software, such as ADSM, Omniback, Legato and others.) 3. Off-site storage Plan offset storage for the case of fire or other major catastrophe in your computer room.
Verifying Backup Strategy

How does the customer know that the backup tapes are OK? How can the customer be sure that they will be able to recover their database? Everyone who manages a database system must be aware of the possibility of absolute catastrophic data loss. One SAP customer, for example, performed an operating system upgrade without re-testing their backup strategy. Several days later it became necessary to restore the backup, and the customer discovered that the tapes written since the operating system upgrade were unreadable. Only the fact that they still had generations from before the upgrade saved this customer from a true catastrophe; nonetheless, many days of business data were lost. 1. Test restore before productive start An absolute minimum verification strategy is to perform a complete restore and recovery before your production system goes live. Once your system has gone live, you should continue to verify your backups regularly, at a minimum of, say three month periods and after every change to the backup infrastructure (new operating system, new database release, new hardware). 2. Backup verification after productive start With version X.X of brbackup you can perform a verify your backup: brbackup restores the files from tape and compares them to the productive versions. For an online backup only the size of the files can be compared; for an off-line backup the contents of the files are checked.
Choosing and Implementing a Backup Strategy

It is very important to set up a proper procedure to backup the valuable information of an R/3 System. These items should be defined before as early as possible to prevent any possible loss of data in the future. Followings is a list of Backup issues which should be resolved before going live: Decide how often to perform complete database backups (preferably on every day in which there is activity in the database) Decide whether partial backups are necessary: if so, plan for their implementation Decide when to perform redo log archives Decide if you will make double copies of redo logs before deletion Decide if you will hold redo logs on archive directory going back to latest complete backup Provide ample disk space for the archive directory
879
Overviewing Windows NT/Database Backup and Recovery Backup and Archive Procedures and Polices
Decide on how to schedule redo log archives Create a volume labeling scheme to ensure smooth operations Decide on backup retention period (recommended at least 28 days) Determine tape pool size Initialize tapes Determine physical tape storage strategy (off-site) Decide whether or not to use unattended operations If unattended operations, in CCMS or elsewhere? Document backup procedures in operations manual Train operators in backup procedures Implement a backup strategy Perform a test restore and recovery
Backup and Archive Procedures and Polices

Backup policies and procedures should be defined as early as possible so that you will be prepared in the event of data loss. The following is an example of backup and archive procedures and polices for a three system landscape (where DEV is a development system, QAS is a consolidation/quality assurance system, and PD1 and PD2 are production systems).
Backup
System Environment
Software Components
The following tools are used to perform the backup/restore tasks: System Name DEV QAS PD1 PD2 Backup Software SAPDBA 3.0E SAPDBA 3.0E/HIBACK 3.02 SAPDBA 3.0E/HIBACK 3.02 SAPDBA 3.0E/HIBACK 3.02
Hardware Components
The hardware listed in the table below is used for backup and restore: System Name DEV QAS PD1 PD2 Backup Hardware 1 x 4mm DAT 4/8GB DDS-2 1 x DLT 15/30 GB 1 x ADIC Autoloader (5 DLT parallel) 2 x DLT 15/30 GB
8710
Policies
Tape Retention Period
The tape retention period is chosen in such a way that even if one tape (backup/archive) is damaged or lost, the ability to recover the database is assured. System Name DEV QAS PD1 PD2 Regular Backup 15 days 30 days 30 days 30 days Month End Backup Year End Backup Archives 15 days 30 days 30 days 30 days
36 months 36 months
5 years 5 years
Backup Frequency (DB + Archives)
Use a schedules similar to the ones below in order to ensure that you will be able to quickly and easily restore the database. Database Schedule System Name DEV QAS PD1 PD2
Archives
Mon Full Online Full/ Online Full/ Online Full/ Online
Tue
Wed Full/ Online Full/ Online Full/ Online Full/ Online
Thu
Fri Full/ Online Full/ Online Full/ Online Full/ Online
Sat
Sun
Full/ Online Full/ Online
Full/ Online Full/ Online
Full/ Offline Full/ Offline
A backup of the archives (former online redo logs) is necessary to be able to perform either a recovery of the database from an online backup or to perform point-in-time recovery. The CDS backup option of the BRARCHIVE program ensures that from each archive there will be stored two copies on two different tapes before the archive is automatically deleted. System Name DEV QAS PD1 PD2 S: Save Mon CDS CDS CDS CDS Tue CDS CDS CDS CDS Wed CDS CDS CDS CDS Thu CDS CDS CDS CDS Fri CDS CDS CDS CDS Sat Sun
CDS CDS
SD: Save & Delete
DS: Delete Saved
CDS: Copy, Delete, Save
8711
Supplementary Backups
Supplementary backups are made at special dates (month end, year end) so that you can restore the database to a previous state if needed. System Name DEV QAS PD1 PD2
Storage Location
Month End Backup None None Full Offline with Verification Full Offline with Verification
Year End Backup None None Full Offline with Verification Full Offline with Verification
For safety reasons, the backup media must be stored in a safe place. The production system copies of the tapes should be stored in a remote (external) location. System Name DEV QAS PD1 PD2
Tape Labeling
Data Safe Yes Yes Yes Yes
Additional Location No No Yes Yes
Choose self explanatory names to indicate the type and source of the backup. For further differentiation, use sequential numbers. System Name DEV QAS PD1 PD2 Regular Backup DEV_R_<NNN> QAS_R_<NNN> PD1_R_<NNN> PD2_R_<NNN> Month End Backup Year End Backup Archives DEV_A_<NNN> QAS_A_<NNN> PD1_A_<NNN> PD2_A_<NNN>
PD1_M_<NNN> PD2_M_<NNN>
PD1_Y_<NNN> PD2_Y_<NNN>
<NNN>: Sequential Number
Verifying Backups
To guarantee the integrity of the backups, perform checks on the tapes according to the schedule below. System Name DEV QAS PD1 PD2 Frequency of Backup Verification Every 2 weeks Every 2 weeks Every 2 weeks Every 2 weeks
8712
Checking Database integrity
To avoid backing up a hidden, inconsistent database (e.g. bad blocks), the database must be checked at least once within one retention period. System Name DEV QAS PD1 PD2 Frequency of DB-checks Every 2 weeks Every 2 weeks Every 4 weeks Every 4 weeks
Procedures
Backup
The backup is performed unattended according to the backup frequency table. The scheduling functionality of the R/3 CCMS is used for scheduling the backup. For systems running plain SAPDBA the required tapes can be listed with the VOLUMES Needed button on the backup scheduling screen within the CCMS. On systems running SAPDBA in combination with HIBACK, the HIBACK Volumemanager must be used to list the required tapes. Extra backups such as the monthly and yearly backup have to be performed offline and will be performed either with SAPDBA interactive or prepared BRBACKUP script files with a special tape pool.
Archiving
Archiving (Backing up of Archives) is performed after successfully backing up the database according to the archiving frequency table. Archiving is performed during normal operation of the system (no performance impact). With plain SAPDBA the needed volumes can be find using the query only option in the backup archive menu of SAPDBA. If HIBACK is installed, the HIBACK Volumemanager must be used for finding the correct tape. For the extra backups there is no special archiving required, because these backups are performed offline, so the database is in a consistent state.
Verifying of Backups
Backups must be verified following the schedule. The verify and list tape contents option of SAPDBA will be used to perform this task. In addition checks can be performed with mt and cpio on the operating system level. On systems running with Hiback, Hiback is used to verify the tapes
Monitoring/Controlling
After the backup of the database and the archives is finished, all logs must be printed and placed in the folder for each system.
8713
Database Check
An integrity check of the database must be performed within one retention period, in order to ensure that there are no corrupted blocks in the database. This is not recognized during backup. An export to the null device (dummy export) is one way to perform this check running ORACLE analyze script another way to check the database.
Roles and Responsibilities

Task Backup Database Backup Archives Verifying Backups Monitoring/Controlling Database check Role Operator Operator Operator/DBA Operator/DBA DBA
Recovery
System Environment
Software Components
For a database recovery, use the same software tools that you used for the backup. System Name DEV QAS PD1 PD2 Backup Software SAPDBA 3.0E SAPDBA 3.0E/HIBACK 3.02 SAPDBA 3.0E/HIBACK 3.02 SAPDBA 3.0E/HIBACK 3.02
Hardware Components
System Name DEV QAS PD1 PD2
Backup Hardware 1 x 4mm DAT 4/8GB DDS-2 1 x DLT 15/30 GB 1 x ADIC Autoloader (5 DLT parallel) 2 x DLT 15/30 GB
Policies
Testing Recovery
The restore procedure is one of the key issues of the R/3 system. Therefore, the procedures for recovering a database must be maintained and tested regularly. System Name DEV QAS Regularly Tests every 2 months every 2 months Supplemental Tests when any of the involved components changes (e.g. SAPDBA) when any of the involved components changes (e.g. SAPDBA)
8714
PD1 PD2
every 2 months every 2 months
when any of the involved components changes (e.g. SAPDBA) when any of the involved components changes (e.g. SAPDBA)
Procedures
Recovery procedures are based on SAPDBA or on SAPDBA plus Hiback. It is also absolutely advisable, to be able to recover the database by hand, which means retrieving the backed up datafiles with native tools like mt and cpio, if you are using a Backint compliant tool like Hiback with plain Hiback. After retrieving the datafiles, the database must be recovered with database tools. It is essential to be familiar with this procedure too.
Roles and Responsibilities

Task Developing Restore Procedures Testing Restore Procedures Training Operators Perform Restores For further details refer to R/ 3 System Administration Made Easy Introducing R/3 System Architecture (Ch. 1) R/ 3 Basis Knowledge Products DBA Oracle CD: R/ 3 System Online Help Database Administration Oracle Basis Courses Database Administration ORACLE (BC505) Reference Implementation Data Backup & Data Recovery Role DBA DBA DBA Operator/DBA
8715

Chapter 87: Overviewing Windows NT/Database Backup and Recovery

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 87: Overviewing Windows NT/Database Backup and Recovery

Uploaded by

Copyright:

Available Formats

Overviewing Windows NT/Database Backup and Recovery Introduction