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