Just my 2 cts to this discussion.

GBak is one of my problems. I'm a developer, but I do some network
administration for fun (I like networks). I'm a little bit paranoic with
backups, so I spend some time with GBak.

Problem: even if GBak ends ok, we are not sure that we have a workable
backup. We must restore the file, and check for any error in that restore.

One of my problems is that gbak does not return any numeric error codes (I
use to post this problem often in firebird-devel, but no single soul have
take a moment to answer me yet). It's very difficult to parse the result
file for a restore searching for a list of errors, so I check the result log
just for 'Going Home' at the end.

Here is what I do:

- Gbak the database - backup;
- Gbak the database, restore it to a temporary name;
- Parse this log file, if 'Going Home' at he end - ok, if not 'ring some
bells to the administrator';
- If it's ok, I delete this temporary file, and Zip & Ftp the gbk one.

Of course this will give some problems: the restore operation is very slow
comparing to the backup. And it takes lot of resources doing a restore. And
this could be usefull on small databases but not at all on larger ones. Bla
Bla Bla.

I think that we have a problem with GBak. Sean have talk a lot of times of
doing something in gbak that will reproduce a usable database. I will love
that. I know that other people are working in different approaches (Geoff
Worboys is doing a good job with DBak - take a look at
http://www.telesiscomputing.com.au/dbk.htm).

Notice that I never had a problem with a Firebird database. And all my
backups ended ok. This was just paranoia, as I told before. I had to emulate
some problems to help me test my parse application. But some people post
their problems here, and Murphy is always around when the word 'backup' is
mentioned....

Artur