On 6/11/2015 11:05 AM, Jack Mason jackma...@mindspring.com
[firebird-support] wrote:
However, that won't help us. Our concern is that we have been backing
up our databases for years and it has been a fruitless exercise. We
cannot restore them. We did not have that problem with Interbase 6
but switched to Firebird because it was touted as being "modern,
safer" etc. Now we find it is virtually worthless unless we can
restore a database it has backed up.
OK. First, there's a -o switch that you should use on the restore if
the normal restore gets an error. That
switch tells gbak to commit after creating the metadata and after
loading data for each table. That will
get you through most problems in backup files. In this case, it will
get you all of your data, indexes, and
constraints.
Second, the problem is somewhere in the privileges you've defined ... I
can't tell which from the
error message.
Third, IBSurgeon has tools that will allow you to fix most broken gbak
backups.
Fourth, in the future, restore one out of ten backups to be sure that
the backup procedure is actually working. That's a good precaution on
any kind of backup. Once in ancient history, we realized after a crash
that we'd been backing up to /dev/null - great optimization, not so good
for recovery.
Nbak has its strengths and weaknesses as well.
Good luck,
Ann
