Had a few reports recently of corrupted indexes while doing a restore. Very
troubling. Restore was done with the same version (4.25 4) as backup.

The backup file itself was corrupted, the restore failed apparently because
one of the files could not be restored. The error was reported by the
restore program, not by DBISAM.

Robert

Robert,

<< Had a few reports recently of corrupted indexes while doing a restore.
Very troubling. Restore was done with the same version (4.25 4) as backup.
>>

The backup file itself was corrupted, the restore failed apparently because
one of the files could not be restored. The error was reported by the
restore program, not by DBISAM. >>

I'm not sure I understand - was the error a DBISAM error or something else ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:92452114-F028-47EA-9AD5-AB7EE4144856@news.elevatesoft.com...
> Robert,
>
> << Had a few reports recently of corrupted indexes while doing a restore.
> Very troubling. Restore was done with the same version (4.25 4) as backup.
> >>
>
> The backup file itself was corrupted, the restore failed apparently
> because one of the files could not be restored. The error was reported by
> the restore program, not by DBISAM. >>
>
> I'm not sure I understand - was the error a DBISAM error or something else
> ?
>

It was reported by DBISAM during the restore, not afterwards while trying to
open a table, which indicates that the file corruption occured during the
backup itself. If the database was already  corrupted BEFORE  it was backed
up, it seems to me the restore would have finished with no problems, but the
table open would have failed.

I'll research this problem some more, but I wanted to know if anybody else
was experiencing similar issues.

Robert

Robert,

<< It was reported by DBISAM during the restore, not afterwards while trying
to open a table, which indicates that the file corruption occured during the
backup itself. If the database was already  corrupted BEFORE  it was backed
up, it seems to me the restore would have finished with no problems, but the
table open would have failed. >>

What was the exact error message - a "header corrupt" error message ?  The
issue reported recently by Clive has to do with the backup itself not being
valid.   What you're describing is a successful backup and restore that
results in a table that can't be opened.  Such a case is caused by the
source table being corrupted prior to the backup.  The restore operation
does not actually open any tables, so such an error message can only occur
*after* the restore is completed and the table is trying to be opened.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:682D90D0-4650-4728-9DFA-719AF5E56DEC@news.elevatesoft.com...
> Robert,
>
> << It was reported by DBISAM during the restore, not afterwards while
> trying to open a table, which indicates that the file corruption occured
> during the backup itself. If the database was already  corrupted BEFORE
> it was backed
> up, it seems to me the restore would have finished with no problems, but
> the table open would have failed. >>
>
> What was the exact error message - a "header corrupt" error message ?  The
> issue reported recently by Clive has to do with the backup itself not
> being valid.   What you're describing is a successful backup and restore
> that results in a table that can't be opened.

I don't know how in the world you can read that from the paragraph you quote
above. What part of "It was reported by DBISAM during the restore" is so
unclear? How can you possibly read into that that I had a "successful
restore"?

1. System is running fine.
2. We do a backup, which completes OK (or so it seems, no error reported).
3. We do a restore and, in the middle of the restore, it crashes.

The only explanation I have is that the backup process itself is corrupting
the backup file.

Such a case is caused by the
> source table being corrupted prior to the backup.  The restore operation
> does not actually open any tables, so such an error message can only occur
> *after* the restore is completed and the table is trying to be opened.
>

Exactly my point. The restore is not checking the logical integrity of the
tables, just the integrity of the files as an aggregation of bytes. If the
backup was good, then the restore should also be good. But apparently the
backup created a bad file, and the error was not caught at the time the file
was created.

Robert

Hi Tim,

The actual restore fails and stops as soon as it finds a corrupt table, is this how it should work?, or should it restore all tables regardless of whether they are corrupted or not.

This does sound pretty much like whats happening to me.
The backup runs and appears to be successfull, Im pretty sure the tables in the database are not corrupted after the backup, as I have spoken with my users to gauge exactly what
they are doing.
When restoring the backup the restore command stops halfway through as it can not read one of the tables, this table then appears corrupt and no more tables are restored.

"Clive" <dd@dd.com> wrote in message
news:58A0F725-7ADF-4117-A028-6A996F7EAD73@news.elevatesoft.com...
> Hi Tim,
>
> The actual restore fails and stops as soon as it finds a corrupt table, is
> this how it should work?, or should it restore all tables regardless of
> whether they are corrupted or not.

I don't think the restore is looking at logical integrity of tables, the way
verify would do. It's probably more along the lines of a ZIP extract, just a
hash total or something along those lines.

>
> This does sound pretty much like whats happening to me.
> The backup runs and appears to be successfull, Im pretty sure the tables
> in the database are not corrupted after the backup, as I have spoken with
> my users to gauge exactly what
> they are doing.

Same thing here. After the backup, they continue processing, log off and on
again opening all tables, etc. with no problem. The backup has written some
garbage into the backup file, which makes the restore fail.

Robert

> When restoring the backup the restore command stops halfway through as it
> can not read one of the tables, this table then appears corrupt and no
> more tables are restored.
>
>
>

Robert,

<< I don't know how in the world you can read that from the paragraph you
quote above. What part of "It was reported by DBISAM during the restore" is
so unclear? How can you possibly read into that that I had a "successful
restore"? >>

I know what you wrote, so you can stop with the snarky response.  If you
would answer my question regarding the error message, I can then help you
further.  Otherwise, I'll just assume that you don't need any further help.
You also wrote this in your first message:

"The error was reported by the restore program, not by DBISAM."

followed by this in your second message:

"It was reported by DBISAM during the restore, not afterwards while trying
to open a table.."

I could have responded in kind like you did with:

"How in the hell could the error be from the DBISAM restore and not be
reported by DBISAM ?"

But I didn't.  Maybe if you were a little more clear in your posts, I
wouldn't have to ask these types of follow-up questions.

And, this is the last time I'm going to say this Robert - if you cannot
respond to my posts in a respectful manner, then I'm going to have no other
choice but to ignore your posts.

<< The only explanation I have is that the backup process itself is
corrupting the backup file. >>

Which is exactly what Clive reported.  Of course, I still don't know what
the error message is in your case, so this is just a general assumption.

--
Tim Young
Elevate Software
www.elevatesoft.com

Clive,

<< The actual restore fails and stops as soon as it finds a corrupt table,
is this how it should work?, or should it restore all tables regardless of
whether they are corrupted or not. >>

There are two separate concepts here:

1) Is the table being backed up corrupted ?
2) Is the table being corrupted during the backup and/or restore due to an
issue with the compression ?

1) Cannot be dealt with by the backup/restore without increasing the time it
takes to backup quite significantly.  It is something that we leave to you
to do via the Verify/Repair facilities.  At any rate, it doesn't really
apply in your case and I don't think it applies in Robert's case.

2) Appears to be somehow related to what version of Delphi being used and
how DBISAM is compiled.  Using DBSYS to do the backup/restore works fine
every time.

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

<< I don't think the restore is looking at logical integrity of tables, the
way verify would do. It's probably more along the lines of a ZIP extract,
just a hash total or something along those lines. >>

Correct.

--
Tim Young
Elevate Software
www.elevatesoft.com