Kbase P6585: OS backup cannot be accessed
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2008 |
|
Status: Verified
SYMPTOM(s):
OS backup cannot be accessed
OS backup cannot be accessed -ro
proutil db -C dbrpr gives Error: turnoff ai or use -F command
** Error: turnoff ai or use -F command
proutil db -C dbrpr -F # hangs!
truncate -bi -F does not work
truncate -bi -F gives error 1124
SYSTEM ERROR: wrong dbkey in block. Found <dbkey>, should be <dbkey2> (1124)
SYSTEM ERROR: read wrong dbkey at offset <offset> in file <file>
found <dbkey>, expected <dbkey>, retrying. (1152)
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CHANGE:
Installed file servers to map network drives for OS copy of database to remote site.
CAUSE:
The "backup" is OS copied (xcopy) accross the networks with mapped drives. As a result, any corruption is not detected until users log in the following morning to the database copy and get errors 1124 1152. Any corrective actions to the copied database are unable to proceed, even when using -F (force) syntax.
FIX:
In the first instance, OS copy is NOT supported by Progress. There are too many variables in the process that could cause corruption of the copy:
a) The "source" database itself
b) Network, Hardware
The procedure that should be employed is either probkup which will check each block is valid before it's buffered into memory and then flushed to disc, or even an even better solutions are:
Use after-imaging
Use the Fathom database replication module
Should the customer not be ameniable to these suggestions, refer to: P6586