All, Historically, GBAK has two features:
1) Ability to make a backup regardless of the database ODS. This can be used for downgrading, e.g. when the v2.5 GBAK attaches to the v3 engine and makes a backup that can be restored on version 2.5. And of course it can be used for upgrading too -- e.g. if a backup is done using the v3 GBAK and then restored into a v3 database.
2) Ability to restore any backup format into any database ODS. This feature is less known and supposedly used rarely. It was supposed to work mostly backwards -- e.g. if you have only a backup done with GBAK v3, you can use GBAK v3 to restore it into the v2.5 database. The "redundant" system tables/fields are just ignored in this case.
If restoring forward, we have new system tables/fields that doesn't have corresponding data in the backup. Perhaps some of them may be cleverly initialized by the GBAK or by the VIO layer of the engine, but generally I'd say it's not guaranteed to work.
But anyway, when Claudio had refactored GBAK in this regard, we seemed to agree to keep both these features.
The problem is that the second feature seems broken in v3. RDB$AUTH_MAPPINGS appeared in ODS12 and can be partially restored into ODS11.2 but cannot be ignored when restoring to the older ODS. Backups containing RDB$DB_CREATORS and RDB$PACKAGES cannot be restored to ODS < 12.
From one side, this looks like a broken feature. From another side, some newer data may be required for the database to remain workable. For example, I see no harm in skipping database creator's grants because they cannot be used by the older engine anyway. But packages are an essential part of the business logic. And some stored procedures may reference these packages. So creating the database without packages is likely to be pointless. And basically speaking, if some "newer" SQL-level feature was used in a database, it's unlikely to be down-gradable at all -- due to newer BLR verbs being unknown for the older engine version.
IMO, we need to clearly decide whether we intend to support restore into the non-native ODS. Such a support requires noticeable efforts when extending GBAK with new system tables/fields.
If we decide to drop it, then it's time for a major cleanup in the GBAK code. And let's also decide whether we do that in v4 only or in v3 too.
If we keep it, let's decide what new tables can be ignored when restoring backwards and what ones are mandatory and thus should raise an error. We may also consider going half-way and limiting the backward restore to the one prior ODS version -- this will also simplifies the code a lot.
Opinions, please. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
