How to OS copy a production database to another directory and then rename the database.
Considerations when using OS copy to backup a Progress database.
OS copy recovery strategy.
How to verify an OS backup of the database.

The following provides a Summary of what needs to be considered when creating an OS copy of a production database to another directory and then rename the database, using an example to describe the method. 

BASIC METHOD: 

0.   Test this method with the sample DLC/sports database, start by creating the prod.db as follows:
If using Progress 8.x, convert the database a multi-volume database:
1.   Before taking an OS copy, shut down the database.

1a.  If an Enterprise Database license is used, the database does not necessarily need to be shutdown beforehand. It can be quiesced and once the quiet point has been raised the database files can be copied.
$   proquiet prod enable   
For further information refer to Article   What are Database Quiet Points?   

1b.  Otherwise, shutdown the database
Verify that the production database is shut down with: or parse the prod.lg file for the message: (334) Multi-user end.

Truncate the bi file:
Take a current reflection of the Control Area by creating a prod.st file as recorded in the prod.db:
2.   OS copy all production database files, including the .st file to another directory:
This is a Windows example, where "D:/bak" is the directory that the OS copy of the prod.db will be placed.
** IMPORTANT NOTE: It is imperative that nothing touches the database files during this operation and that all extent files are copied **

It is strongly advisable:

• To preserve the date and time stamps of the copy, refer to your OS documentation as necessary.
• To compress the copy of the database files before transferring these to another machine

Ensure that every database file for the production database has been copied to the "D:/bak" directory and is exactly the same size as the original, including AI files (this is often overlooked when taking an OS copy)

The md5 freeware utility is very useful to this end:

• The MD5 routine creates 2 check files from the copy (one at source, then at target after the copy). The contents of the two files, “source” and “target”, must be identical.
• There is a third file created called md5diff. This is a file which will hold any discrepancy between these two files. When md5diff is blank there is no difference in the two check files. The two check files can be scrutinized to be sure.

Otherwise WINZIP | tar and GZIP the database files at source and then once they have been copied to the target directory across the network drives, unzip the archive as appropriate to the method used.

3.   With your favourite editor, edit the database structure file: D:/bak/stat.st to reflect:

• The new physical location of every database extent file: D:/bak/
• The new database name: stat to replace “prod”

Pay special attention to every line in the structure file, an example of one such edited line in D:/bak/stat.st:
 
4.   Repair the database structure specifying the modified structure file:
5.  Open the database by running a single user connection to test.
If the OS copy was taken while the database was quiesced, the first time the database is opened will go through bi recovery. As an alternative before accessing the renamed database, explicitly instruct bi redo/undo:

The greater advantages of PROBKUP

The Progress probkup utility is the only supported backup strategy. 

• A PROBKUP can be taken while prod.db is either offline or online without the need to quiesce the database
• Online OS copies can only be used when an Enterprise Database licenses is used and only once quiescense has been guaranteed to have been raised with the PROQUIET utility.
• Both full and incremental backup strategies can be employed, which saves both time and space.
• The backup volume can include redundancy to add to the backup for error correction and overlap between incremental backups
• For large databases, the backup volume can be spit into multiple volumes which improves file transfer times between systems and the time to restore as each volume can be transferred and restored as it is closed.
• Unlike OS copy, PROBKUP will check the source database for block level corruption.

A ‘dummy’ PROBKUP can be run prior to the OS copy to ensure there are no block header corruption. This will not back the database up, but will verify the database integrity at block level and additionally provide an idea of how much disk space will be needed for the OS backup from the BACKUP messages in the database lg file. Consider including this check in Step 1.
 
As with any recovery plan, it needs to be fully tested and the procedure documented to suit particular site needs. We offer a consultancy service to this end, if you would like to make use of it, please contact your Account Manager.