Gbak vs nBackup: Which minimizes downtime for a small Firebird app migration?

Recommendation

Choose nBackup when the source and target run the same operating system and Firebird major version, or a supported upward ODS path. A physical restore copies database pages directly, so the final cut-over is limited to applying the last incremental and switching the application connection string. Choose Gbak when moving across operating systems, architectures, or Firebird major versions where a physical image is not compatible; accept a longer restore window because it rebuilds metadata and data logically. Neither method guarantees zero downtime by itself; true zero downtime normally requires replication or log shipping.

Confirmed facts versus planning estimates

Confirmed: Firebird databases carry an on-disk structure (ODS) version. Major releases use different ODS versions, and restoring an older database to a newer server normally triggers an ODS upgrade. Gbak is a logical backup and restore tool. nBackup is a physical page-level tool that supports incremental backups.

Planning estimates only, not verified for your hardware: a full Gbak restore of a 10 GB database may take tens of minutes, while a full nBackup restore may take minutes. An nBackup incremental strategy can reduce cut-over to the time needed to apply the final changed pages, but the actual savings depend on how much data changed since the last backup.

Steps for this case

1. Take a full online nBackup on the source (example syntax; verify flags for your Firebird version):

nbackup -B 0 -L /backups/full.nbk /data/source.fdb

2. Copy the backup to the target and repeat incremental backups on a schedule:

nbackup -B 1 -L /backups/incr.nbk /data/source.fdb

3. At cut-over, pause application writes, take one final incremental, stop the source Firebird instance, copy or apply the final incremental on the target, then start the target and update the application connection string.
4. If the source is Firebird 3.0 and the target is Firebird 4.0, open the restored database on the 4.0 server and allow the ODS upgrade. Test this on a non-production clone first because the upgrade adds unmeasured downtime.
5. Run row-count and critical-query checks before re-enabling users.

Verification

• Restore a 10 GB test database on the target hardware with both methods and record the elapsed time.
• Test the Firebird 3.0 to 4.0 ODS upgrade path on a clone and note the additional minutes before scheduling production cut-over.

Missing diagnostic detail

Are the source and target servers running the same operating system and Firebird major version? This determines whether nBackup is safe to use or whether Gbak is required.