Using Prorest utility for an incremental backup

H

HFP

New Member
Hi, I have had a search so am hopefully not repeating a question.

We have a master progress database and a 'mirror' of it on another server acting as a backup and for running reports against.

Currently this is done so that once a week a full backup is performed via the probkup and the incrementals via probkup with an incremental flag. Each day the .bak file is restored to the mirrored d/base using prorest. On each backup the bi files are truncated prior to the backup being taken.

Now this has been running fine for months however (out of turn) 36hours ago I needed to do a full backup (and thus restore to the mirrored d/base) instead of an incremental. This was all successful.

This morning though the incremental bak file failed to restore, in the dos window the message showed the following:

database has been updated, incremental restore not possible. (6773)
Restore failed. (1618)
!!! Error - Database restore utility FAILED !!! (8564)
Click to expand...

Please can anyone help explain why and what I can do to resolve this? It's an important snapshot (month end) so I would like to incrementally restore only the data contained in the bak files rather than going back to the live system and taking another full backup.

Many thanks in advance,
HFP
 
I've followed the link off this site and found the following:

ID: P44526
Title: "Error 6773 when restoring an incremental backup"
Created: 09/26/2003Last Modified: 09/26/2003Status: Unverified
WME('Symptoms: ');

Symptoms:
Error 6773 when restoring an incremental backupWME('Symptoms: ');
sports2000 has been updated, incremental restore not possible. (6773)WME('Symptoms: ');
<database name> has been updated, incremental restore not possible. (6773)
WME('Cause: ');

Cause:
A broker has been started for the target database before the attempt to restore the incremental backup into the database.WME('Fixes: ');

Fixes:
Restore a full backup of the source database and start applying incremental backups to the restored version of this full backup.WME('Notes: ');

Notes:
When a broker has been started for the database Progress will perform crash recovery. From this moment on the database will be considered to have changed. This is the reason the restoration of the incremental backup will fail.
Click to expand...

This suggests that I have made a change to the database, the only time this was done was prior to the full back which was why the full backup+restore was performed!

Arrgh!
 
Hi all,

I have established the cause of this error - the ODBC connection is definitely to blame. I have setup the database with two data configurations, one 4GL Only and one SQL Only.

If a database query is passed through the SQL ODBC connection (using the SQL Only configuration) it works fine, it is purely a read, uncomitted query. However when it comes to perform the incremental restore it throws the above error.

If in the database properties of the defaultConfiguration I disabled the "Apply crash protection" checkbox would this work in the future?

THis database is a copy of our live db so doesn't really need to be there I don't think.

All advice gratefully received!
 
Disabling crash protection won't help. It will just mean that any little glitch on your system might hose the database (or make Progress suspect that it is hosed).

Are you using the -RO parameter to start your clients? That might help.

What version of Progress are you running? An upgrade might improve things.
 
Hi Tom, thanks for the reply.

I'm not using the read only parameter, I will certainly give it a go. :)

As for the version - I wish!! We are currently running 9.1D, I'd love to upgrade however the application that sits on it can't handle the newer versions and likely never will. :(

I'll try the ro parameter and see how I get on. Fingers crossed!!!
 
the application that sits on it can't handle the newer versions

That is highly unlikely.
 
It is unfortunately true that some misguided application partners encourage the idea that only certain very specific (and almost always ancient) releases of Progress can be used with their code.

It is hardly ever actually true. Especially if you have the ability to compile code.

They usually try to enforce this by threatening to withhold support in some way. I don't really understand why they think that that is an effective threat :rolleyes: Or worse, why any customer would ever fall for it :confused:
 
tamhas said:
the application that sits on it can't handle the newer versions

That is highly unlikely.
Click to expand...

It is the way that it is for exactly why Tom said unfortunately. It was before my time and the system is up for being replaced in the very near distant. It is not a situation that I hope to be repeated!
 
Not being allowed to by the vendor is not the same thing as "cannot handle".

Have you pointed out to the vendor that the choice is to support the newer version or be replaced?
 
Thanks for the suggestion Tom, unfortuantely it didn't solve the issue and the database still thinks it's "been changed". I guess a full backup+restore would be the way to go, unfortunately there isn't enough time in a weekday night to allow for this.

tamhas - Yes and they know we are, doesn't seem to make them care anymore unfortuntely.
 
Then I would guess that either something really is changing the db and you need to find that something or you are dealing with a bug. If it is a bug your only effective recourse is going to be to upgrade.
 
You must log in or register to reply here.
Back
Top