Kbase P56232: Steps to consider when taking an OS backup of Progress database.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/9/2006 |
|
Status: Verified
GOAL:
Steps to consider when taking an OS backup of Progress database
GOAL:
How to OS backup a Progress Database
FIX:
The following provides a summary of what needs to be considered when creating an OS copy of the production database (prod.db)
BASIC METHOD:
"To OS copy the production database to another directory"
(Please note, if you'd like to first test this strategy with the ?sports? database, start by creating the prod.db as follows:
prodb p sports
)
STEPS:
1.) Shut down prod.db, OS copies of the Production database /must/ be taken offline:
> proshut p ?by -F
Verify that the production database is indeed shut down with the:
> proutil p -C busy
qualifier or parse the prod.lg file for the (334) shutdown message.
Truncate the bi file:
> proutil p -C truncate bi -G 0
Take a current reflection of the prod.st file as recorded in the prod.db:
> prostrct list p prod.st
2.) D:/bak is the directory that we're going to put the OS prod.db in.
3.) xcopy prod* D:/bak/prod* /V /F
4.) cd D:/bak
Make sure that EVERY database file for the production database is in the "D:\bak" directory and is the same size as the original.
The md5 freeware utility is very useful to this end. The MD5 routine creates 2 files from the copy (one at source, then at target after the copy) the contents of the two files, ?source? and ?target?, should be identical. There is a third file created called md5diff. This is a file which will hold any discrepancy between these two files. If md5diff is blank there is no difference in the two check files, however, of course the two check files can be scrutinised manually to be sure.
Otherwise WINZIP the OS files at source and unzip them when they're copied to the target directory across the network drives.
As an aside, the probkup utility is the only supported backup strategy.
The greater advantage of probkup, is that it can be done while prod.db is online and you can make both full and incremental backups, which saves both time and space. Furthermore, unlike OS copy, probkup will check the source database for corruption at block level before completing.
> probkup p NUL
will NOT back the database up, but will verify the database integrity at block level and give you an idea of how much disk space is needed for the OS prod backup. You could consider at least including this in the step 1 after bi truncation.
As with any recovery plan, these need to be fully tested and documented to suit your particular needs.