Kbase P2862: How to use offline OS backup with after imaging enabled - pre Progress 9.1E?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/14/2009 |
|
Status: Verified
GOAL:
How to use offline OS backup with after imaging enabled?
GOAL:
When to use rfutil -C mark backedup when AI is already enabled on the database?
GOAL:
Where to rfutil -C aimage new for offline OS backup baseline ?
GOAL:
How to avoid "Expected ai file number 1 but file specified is X in sequence. (8019)"
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.1D
Progress 9.1C
Progress 9.1B
Progress 9.1A
Progress 9.0X
Progress 8.x
FIX:
The purpose of this Solution is not to discuss the OS copy ai recovery plan, merely to provide a template. The use of 3rd Party database file copy, although possible can be quite error prone in our experience - simply because there are so many points of potential failure in the OS copy part (eg incomplete file copy, ftp failure, database being accessed during copy routine) and when used with after-imaging, there is the additional requirement to ensure that the ai switch is exactly paired to the OS copy and does not span OS copy. The preferred Progress Solution is to use the probkup [(online | offline) or (full | incremental)] utility which automatically pairs the backup with ai file switching and keeps the expected AI sequence and current AI sequence counters aligned in the database master block. It is exactly the misalignment of these counters that leads the 8019 error during rfutil -C roll forward. The following procedure is fitted to best practice from the Progress perspective, assuming that the necessary checks are inplace, it will work.
The following detail pertain to all versions supporting after-imaging up to and including Progress 9.1D09. Although not ALL steps are entirely necessary, they are considered best practice. As with any Disaster Recovery Plan, it should be fully tested and documented before rolling out to Live. # OFFLINE_db_OS_backup:
1.) shutdown the database gracefully
$ proshut <db> -by
2.) Truncate the database before-image file
$ proutil <db> -C truncate bi
3.) Ensure that all cron jobs running against the database have stopped, no access to the db must be allowed during copy.
4.) Switch to a new aimage extent
$ rfutil <db> -C aimage new
5.) Take the 3rd party OS copy of all the database files (including necessary ai files) and verify completion.
6.) Mark the database as backed up - this step is only absolutely needed prior to rfutil -C aimage begin
$ rfutil <db> -C mark backedup
7.) Restart the database server
$ proserve <db> <parameters>
# ONLINE_db_OS_backup
1.) Issue a quiet point
$ proquiet <db> enable, this Progress utility automatically forces a "rfutil -C aimage new" switch
(once the proquiet command has indicated that the quiet point has been enabled)
2.) use operating system commands to split mirrors, then/or
3.) Take the 3rd party OS copy of all the database files (including necessary ai files) and verify completion.
4.) proquiet <db> disable
# roll_forward_OS_backup:
1.) restore the OS backup # ensuring that dbname.st contains FULL paths
$ prostrct repair <db> dbname.st
2.) disable after-imaging
$ rfutil <db> -C aimage end
3.) roll-forward the AI extents numbered from step 3 above.
$ rfutil <db> -C roll forward -a <name>
NOTE: prostrct unlock should not be necessary and indeed if executed will not work as it causes the database to skip crash recovery.
If using Progress 9.1E, OpenEdge 10.0B01 or 10.1A (and beyond) please refer to Progress Solution P115048, "How to use offline OS backup with after imaging enabled - post Progress 9.1E?"