Firebird Online Backup with nbackup: How, Why, and Trade‑offs

Problem: Backing up a live Firebird database without downtime

Most relational databases lock the entire file during a backup, forcing applications to pause or queue writes. For a 10‑GB Firebird instance that receives hundreds of writes per second, even a few minutes of lock time can be costly. The question is: how can we capture a consistent snapshot while the system continues to serve traffic?

Thesis: nbackup’s two‑stage, delta‑based strategy keeps writers running and readers unaffected

Firebird’s nbackup utility implements an online backup that preserves a consistent point‑in‑time view by copying the database file and recording all changes that occur during the copy in a separate delta file. When the backup finishes, the delta is merged to produce a usable backup file. This approach requires no exclusive lock and allows concurrent DML operations throughout the process.

How nbackup Works – The Two‑Stage Process

1. Lock and copy – nbackup -l 0 <database> <backup_file> runs with lock level 0. It acquires a shared lock that blocks writers only from acquiring new exclusive locks, then copies the database file to backup_file. A delta file backup_file.delta is created to record all changes made after the copy starts.
   • Run as a user with read/write access to the database and filesystem.
   • Check that backup_file and backup_file.delta are created immediately; the copy can take minutes, but no writes are blocked.
2. Release and merge – nbackup -l 1 <database> <backup_file> drops the lock and finalizes the backup. It reads the delta file and applies the recorded changes to the copied database, producing a single, consistent backup file.
   • The delta file is now no longer needed and is deleted automatically.
   • After this step, the backup file can be used for restoration or replication.

Concrete Example: Backing Up and Restoring a Test Database

Assume you have Firebird 3.0 or newer installed on a Linux machine. Create a test database, then perform an online backup and restore it to verify correctness.

# 1. Create a test database
isql-fb -i create_testdb.sql

# 2. Start a background load to generate writes
./load_generator.sh &

# 3. Initiate the backup (stage 1)
# Run as a user that owns the database files
nbackup -l 0 testdb.fdb testdb.backup

# 4. Perform some DML while the backup is in progress
isql-fb -q "INSERT INTO orders VALUES (1, '2026-10-09', 100);"

# 5. Finish the backup (stage 2)
nbackup -l 1 testdb.fdb testdb.backup

# 6. Verify the backup exists
ls -lh testdb.backup

# 7. Restore to a new database file
nbackup -r testdb.backup restored_testdb.fdb

# 8. Compare the restored state with the original
isql-fb -i compare.sql

In step 3, testdb.backup is created almost instantly. The load generator continues to write to testdb.fdb without waiting. Step 5 merges the delta file; the resulting testdb.backup now contains all rows up to the moment the lock was released. Restoring it in step 7 recreates the database exactly as it existed then.

Trade‑offs and Limitations

• Disk space – You need enough free space for both the base copy and the delta file. If the delta grows large (e.g., heavy write traffic), the backup window can stretch and the temporary file can consume a significant portion of storage.
• Uncommitted changes after lock release – nbackup captures all committed transactions up to the moment the lock is dropped. Any transaction that starts after the lock is released and commits later will not be part of the backup, leading to a slightly older snapshot.
• Performance impact – While writers are not blocked, the I/O overhead of copying a large file and logging changes to the delta file can affect overall throughput, especially on slower disks.
• Compatibility – The online backup feature is available from Firebird 2.0 onward. Verify your version’s release notes to ensure nbackup supports the online mode you plan to use.

When to Use nbackup vs. Alternatives

Choose nbackup when you need a consistent snapshot without stopping the database and can tolerate a brief period of extra I/O. If your workload is extremely write‑heavy, consider:

• Offline backup – copy the database file while the server is stopped. Simpler but requires downtime.
• Database archiving – use Firebird’s backup SQL command in a maintenance window for a quick copy that may block longer.
• Third‑party replication – set up continuous replication to a standby server; the standby can be used for reads and backups without affecting the primary.

Actionable Takeaway

To implement an online backup strategy with Firebird:

1. Ensure you have at least double the size of the database available on the backup target.
2. Schedule nbackup -l 0 during periods of lower write activity to keep the delta file manageable.
3. Monitor the delta file size with du -h or a filesystem monitor; if it grows beyond a threshold, consider aborting the backup and retrying later.
4. Automate the two‑stage command sequence in a shell script, capturing logs and sending alerts on failure.
5. Periodically restore a backup to a test environment to verify integrity and validate your restore process.

With these steps, DBAs can achieve near‑zero‑downtime backups while maintaining application availability.