The use of 3rd Party database file copy, although possible, can be error prone - 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 the OS copy.
The preferred Progress solution is to use the PROBKUP [(online | offline) , (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 to the 8019 error during 'rfutil -C roll forward' against non-Progress database copies. For further explanation, refer to Article 000011441, Why is it necessary to run rfutil -C aimage sequence on an OS copy ?
The following procedure is fitted to best practice from the Progress perspective from Progress 9.1E and OpenEdge 10.0B01 onwards. Assuming that the necessary checks are in place, it will work. For previous versions please refer to: Article 000026549, How to use offline OS backup with after imaging enabled - pre Progress 9.1E?
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.
NOTE: This scenario is based with the understanding that AI is already enabled for the database.
STEPS:
# OFFLINE_db_OS_backup:
1.) Shutdown the database gracefully, should a forced shutdown be necessary, the success of Step 2 serves as a sanity checkpoint.
$ 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. It is imperative that the database is not touched otherwise until Step 5 of this procedure is complete.
4.) Switch to a new AI extent (this is to make sure that for the next couple of steps that we are not in the middle of an AI file)
$ rfutil <db> -C aimage new
5.) Take the 3rd party 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 necessary after "rfutil -C aimage begin"
$ rfutil <db> -C mark backedup
7.) Restart the database server
$ proserve <db> <parameters>
# ONLINE_db_OS_backup
Step: 1 : Raise Quiet Point
1.) Issue a quiet point, which will automatically force a "rfutil -C aimage new" switch to the next AI extent.
$ proquiet <db> enable
2.) Once the proquiet command has indicated that the quiet point has been enabled, 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.) Disable the database quiet point
$ proquiet <db> disable
# roll_forward_OS_backup:
1 ) Restore the OS backup and remove or rename the .lk file if it was included in the backup.
2) After ensuring that the dbname.st contains FULL paths to every OS backup database extent (including the AI files), repair the Control Area.
$ prostrct repair <db> dbname.st
3) If the OS copy was taken from a replication enabled database, first disable replication.
$ proutil <db> -C disablesitereplication [source | target]
4) Re-set the expected AI sequence to the current AI sequence counters aligned in the database master block.
$ rfutil <db> -C sequence
5) Roll-forward AI extents starting with the AI file numbered from Step 3 from the offline OS backup manual RFUTIL switch or Step 1 from the online OS backup PROQUIET enable switch above. The first roll forward command will automatically disable after-imaging and related features. Once after-imaging is disabled on the database, the rfutil -C sequence command cannot be run.
$ rfutil <db> -C roll forward -a <name>
If step 5 fails then try using "roll forward retry qualifier "
$ rfutil <db> -C roll forward retry -a <name>
WARNING: ROLL FORWARD disables after-imaging. (663)
After this is complete, you should re-enable it. (648)
If you desire continued after-image protection (659)
After-image Extent Management has been disabled for the database. (13292)
After-image disabled. (846)
