So - this is rather rare case when fdb file gets corrupted (there
are error messages like 'wrong page number...', 'gds consistency
check...' and so on) but - anyway - when this occurs then - up to my
knowledge - there is not straighforward and realiable way for data
recovery. 'gfix -mend' cann't always remove all the errors.

From my experience - the only way is try to read as many healthy and
available records from corrupted DB as one can (e.g. usually the
primary key has datatype integer or sorted varchar and if only some
data pages are corrputed then only some records around some special
value of primary key are unavailable but the others are available,
in very lucky case - the unavailable records are rather old and they
can be read directly from some archived fdb files) and then - one
should try to restore the lost records in other tables from already
available data (this requires strong knowledge of underlaying data
structure etc)...

So - is any good design advice available how to design the 100%
reliable solution with FireBird? As I know - Oracle has redo logs
and any recovery can be done automatically. But FireBird hasn't such
an option? So - one should rely on more hacked design choices. One
option is try to implement custom log and then there are 2 choices -
1) write log in the same fdb file as the main data (with hope that
there will be very low probability that both types of data - main
and log - will be corrupted at the same time; 2) write log in other
db file which can be located even in some remote HD. The second
choice is rather expensive as multi-DB transactions are more complex
than single DB. What else options can be?

And at last - is there some ongoing progress in Firebird development
to add more advanced recovery and logging features and are some
activities planned for near future? Sometimes I feel that it would
be nice to participate in development of such features as our
company would be very interested in them.