> From a quick search, I suspect that will be the "pag_scn" 4 byte value.

I don't recall exactly, if you want to pursue this you should ask on the Devel list for confirmation.

> That would mean that I could relatively easily write my own sync code that
> could also read all those values and decide which page would need to be
> transferred while the file is locked.

I don't think that it will be advisable (see below), but why duplicate what nbackup is already doing?

> The disadvantage would be that I would need to keep close control of these
> files as nbackup could not come to help to prevent incorrect ordering while
> merging...

There are many other factors to consider:

- backup/restore of source database using gbak -- this would reset all page "version" values

- correctly detecting the database page size value -- which can be changed via gbak backup/restore.

- the ODS (on disk structure) for database pages can change from version to version*. You would need to factor these changes in your own code.

> Does NBackup do any other magic than that?

It ensures that a backup file is being applied to the correct target database -- it does not blindly restores backup files on top of database.


Sean

* A change to the header layout would be part of a major ODS update. Such updates have (historically) only occurred with major Firebird releases (though this may change in the future)