Zero‑Downtime Backups in Firebird with nbackup: How It Works and What to Watch For

The Problem: Consistent Snapshots Without Locks

Production Firebird databases often serve read‑write workloads around the clock. A traditional file‑copy backup either forces a full lock (blocking all transactions) or risks an inconsistent snapshot because pages change while they are being copied. Administrators need a way to capture a point‑in‑time image while the database stays online.

How nbackup Achieves Online Backups

Firebird ships with nbackup, a physical backup utility that uses a brief backup‑mode lock. The sequence is:

1. Acquire an exclusive lock for a few milliseconds and switch the database into backup mode. This flushes dirty pages to disk and prevents further page writes until the lock is released.
2. Release the lock. The database continues to serve transactions; new changes are written to a separate delta file while the original database files remain static.
3. Copy the now‑static database files (the level‑0 backup) to the backup destination. Because the files are not changing, the copy is a consistent snapshot.
4. When the copy finishes, nbackup notifies the engine, which merges the delta file back into the main database and removes the delta.

The lock window is typically sub‑second, so applications see no interruption.

Worked Example: Level‑0 and Incremental Backups

Assume a database file /opt/firebird/data/mydb.fdb owned by the firebird user. You have SYSDBA privileges (or the database owner) and run commands on the same host where the database files reside.

# Level‑0 (full) backup while users stay connected
nbackup -b 0 /opt/firebird/data/mydb.fdb /backups/mydb_level0.nbk

During the copy you can verify the database is still online:

# In another terminal, run a simple query
isql -q -u sysdba -p masterkey localhost:/opt/firebird/data/mydb.fdb -exec "SELECT COUNT(*) FROM MY_TABLE;"

After the level‑0 file exists, create an incremental (level‑1) backup later in the day:

nbackup -b 1 /opt/firebird/data/mydb.fdb /backups/mydb_level1.nbk

To restore, apply the base backup first, then each incremental in order:

nbackup -r /opt/firebird/data/mydb.fdb /backups/mydb_level0.nbk /backups/mydb_level1.nbk

Restored database reflects the state at the moment the level‑0 backup started; the level‑1 adds changes up to its start time.

Trade‑offs and Limitations

• I/O bandwidth: The copy phase reads the entire database file set. On a busy system this can contend with the workload. Schedule backups during lower‑traffic windows or throttle the copy with OS tools (e.g., ionice on Linux).
• Incremental dependency: Each level‑1 backup relies on the integrity of its level‑0 ancestor. Corruption in the base file propagates to all later increments. Verify the level‑0 backup immediately after creation (see verification below).
• No logical selectivity: nbackup copies whole database files. You cannot exclude tables or schemas; for selective extracts you still need gbak logical dumps.
• Platform‑dependent files: Backup files are tied to the Firebird architecture (32‑bit vs 64‑bit) and OS page size. Moving a .nbk file to a different platform requires a full restore on the target system.
• No built‑in compression: The utility writes raw pages. Pipe the output through gzip or use filesystem‑level compression if storage savings are needed.

Verifying the Backup

After a level‑0 backup finishes, run a quick restore to a temporary location and compare row counts or checksums:

# Restore to a test file
nbackup -r /tmp/mydb_test.fdb /backups/mydb_level0.nbk
# Check a known table
isql -q -u sysdba -p masterkey localhost:/tmp/mydb_test.fdb -exec "SELECT COUNT(*) FROM MY_TABLE;"

If the count matches the production database at the backup start time, the snapshot is consistent. Also watch the Firebird log (firebird.log) during the backup; you should see a line like Database "mydb.fdb" switched to backup mode followed shortly by Database "mydb.fdb" left backup mode with no shutdown messages.

For ongoing confidence, script the verification step and alert on mismatches. This turns the backup from a "fire‑and‑forget" operation into a monitored part of your reliability pipeline.

Actionable Closing

Use nbackup for fast, physical, zero‑downtime backups when you can tolerate the I/O load and need whole‑database recovery points. Pair it with periodic gbak logical dumps for schema‑level portability and table‑level restores. Schedule a verification restore after every level‑0 run, and monitor the brief backup‑mode lock in the server log to confirm the database never went offline.