Firebird Online Backups with nbackup Incremental Snapshots for Large Production Databases

Problem: large Firebird databases need online snapshots without gbak downtime

Logical backups with gbak lock the database for extended periods on large files and generate large I/O. For production systems that must stay online, nbackup provides physical page-level online backups. The useful takeaway is an initial full nbackup followed by incremental nbackup snapshots reduces I/O and storage while keeping the database accepting connections, provided the backup chain is retained and verified.

Desired outcome

A repeatable backup chain that can be restored to a consistent point in time with minimal production impact. Full plus incremental nbackup gives a base image and smaller deltas, and when combined with Firebird transaction log archiving it supports point-in-time recovery.

Prerequisites

• Server host access where the Firebird server runs. Run commands as an OS user with read access to the database files and write access to the backup directory, typically the firebird service account.
• nbackup utility matching the server major version. nbackup is physical, so restore requires the same or a newer Firebird major version and a compatible platform.
• Database alias or absolute path reachable by the server, e.g., localhost:/path/to/db.fdb.
• Backup directory with enough free space for the full backup plus all incrementals in the retention window.
• Metadata store for backup identifiers, timestamps, and chain order.

Procedure

Keep the backup directory separate from data files and avoid long-running transactions during backup windows.

Create initial full backup

Run on the server host. This creates a consistent physical snapshot while the database stays online.

nbackup -B <backup_dir>/full_<date>.fbk <db_alias>

Record the backup file name and creation time. The file is the base for all later incrementals.

Create incremental backup

Incremental backups capture pages changed since the base backup identified by nbackup. Use the same base until you start a new full cycle.

nbackup -I <backup_dir>/full_<date>.fbk -B <backup_dir>/inc_<date>.fbk <db_alias>

Schedule incrementals on a regular cadence. The chain is fragile: loss of the base or any intermediate backup makes later incrementals unusable.

Retention and metadata

Store a manifest with base file, incremental files in order, and timestamps. Retain the full backup for the duration of the incremental chain and enforce integrity checks before reuse.

Expected checks

• Backup completion: check nbackup exit status and confirm the backup file exists with non-zero size.
• Chain integrity: verify the base file is present before creating a new incremental.
• Verification restore: restore the chain to a non-production database using the same nbackup version and confirm the database mounts.
• Structural consistency: compare header information from gstat -h between source and restored copy to ensure page counts and ODS are consistent.

Limitations and risks

nbackup is physical, not logical. Restores require compatible Firebird major version and OS architecture. Cross-version restores can fail.

Online backups still depend on Firebird configuration and transaction activity. Long-running transactions can increase backup time and size.

Incremental chains are fragile. Any missing file breaks the chain. Keep backups immutable and test restores regularly.

Recovery options

Restore requires applying the full backup followed by incrementals in order. Restore is a state-changing operation and should be performed on a separate instance.

nbackup -R <backup_dir>/full_<date>.fbk <restore_path>/db.fdb

Then apply each incremental in sequence with the restore mode. After restore, bring the database online and, if transaction logs are archived, perform point-in-time recovery to the desired timestamp.

Always test restores to a non-production database before relying on the chain for production recovery.