Backing Up Firebird Without Downtime: A Practical Look at nbackup

If you run a Firebird database that serves users around the clock, the classic backup question becomes awkward fast: how do you take a consistent, restorable backup without shutting anything down? Firebird's answer is nbackup, an online incremental backup tool that has shipped with the engine since version 2.0 and is genuinely useful once you understand what it actually does — and what it doesn't.

The short version: nbackup freezes the database file's physical state momentarily, redirects new writes to a delta file, and lets you copy the main file at your leisure. Because Firebird uses a multi-generational architecture (MVCC), readers and writers keep working against row versions while this happens. The result is a backup strategy with no real downtime, plus the option of incremental levels that only capture changed pages.

How nbackup actually works

nbackup operates at the page level, not the record level. That distinction matters. A logical backup tool like gbak reads the database through the engine and writes out a portable, compressed logical dump. nbackup instead works with the physical database file itself, which makes it fast and makes incremental backups possible — but the output is tied to the same platform and page size.

The flow for a full (level 0) backup looks like this:

1. nbackup briefly locks the database and copies the header page. This is the only moment of contention, and it's short.
2. The engine sets an internal flag. From this point, any page that would be modified is first written to a delta file (by default alongside the database, with a .delta suffix).
3. While the database runs normally, nbackup copies the main database file to your backup destination.
4. When the copy finishes, nbackup "unlocks" the database: the delta file is merged back into the main database file and deleted.

What you end up with is a full physical image of the database as of the moment the backup ended. Restoring it is a file copy, not a replay — which is why nbackup restores are dramatically faster than gbak restores on large databases.

Incremental levels: the real engineering win

Where nbackup earns its keep for 24/7 systems is the levelled incremental chain. A level 0 backup is a full image. A level 1 backup captures only pages changed since level 0. A level 2 captures pages changed since level 1, and so on. Each level is much smaller and faster than a full backup.

A common pattern is a weekly level 0, a daily level 1, and an hourly level 2 — giving you fine-grained restore points without paying the cost of a full file copy every time. Restoring means reconstituting the chain: restore level 0, then apply each subsequent level in order with nbackup -r.

A worked example

These commands run on the database server (or against it via the Services API), and the operating-system user needs read/write access to the database file and the backup destination. Replace paths and credentials with your own. Assumes Firebird 3.0 or later; the -user/-password options are needed when connecting through the service manager rather than running embedded.

# Level 0: full physical backup
nbackup -B 0 /data/app.fdb /backups/app_level0.fbk \
  -user SYSDBA -password 'your_password'

# ... normal workload continues ...

# Level 1: pages changed since level 0
nbackup -B 1 /data/app.fdb /backups/app_level1.fbk \
  -user SYSDBA -password 'your_password'

# Restore: reconstruct the chain into a new file
nbackup -R /restore/app_restored.fdb \
  /backups/app_level0.fbk /backups/app_level1.fbk

Verification is straightforward and worth doing every time: after restoring, connect with isql and run a couple of sanity queries — a row count on a busy table, a check of the most recent transaction timestamps — to confirm the restored database reflects activity that occurred after the level 0 backup was taken. Also confirm the restored file opens cleanly with gfix -v -full if you want a deeper validation pass. Don't assume a backup is good because the command exited without error.

One operational detail people trip over: while a backup is in progress, the database is in a "backup state" (you can see this with gstat -h, which reports the database's attributes). If the server crashes mid-backup, the database stays in that state with a live delta file. You must resolve it — either with nbackup -N (merge the delta back and return to normal) or nbackup -F (forget the backup state) — before the database is fully healthy again. Monitoring for a lingering .delta file is a cheap and effective alert.

Trade-offs and limitations

nbackup is not a universal replacement for gbak, and pretending otherwise causes pain:

• Not portable. The output is a physical image. You can't use it to move a database between operating systems, change page size, or upgrade the on-disk structure. gbak remains the tool for that.
• The delta file is a risk window. During any backup, all writes flow through the delta. If that file is corrupted, or the server dies before merge, you need to recover the backup state manually, and an interrupted backup set may be incomplete. Keep the delta on reliable storage and verify backups regularly.
• The header lock is brief but real. For the vast majority of workloads it's imperceptible, but if you have genuinely latency-sensitive transactions, schedule level 0 backups for quieter windows.
• Chain discipline matters. Lose one level in an incremental chain and everything after it is useless. Treat the chain as a unit: store, checksum, and retention-manage the levels together.

Choosing between nbackup and gbak

The practical answer for most production Firebird shops is "both." Use nbackup for fast, frequent, low-impact operational backups and rapid restores. Use gbak periodically for a portable logical backup that doubles as a database health check (a successful gbak backup/restore cycle exercises the data through the engine) and as your migration path when you upgrade or move platforms. If you can only pick one and your database is large with strict uptime requirements, nbackup is usually the right primary tool — just build the restore-chain rehearsal into your routine so the first time you test it isn't during an incident.