Using Firebird nbackup for Online Incremental Backups

The problem: backing up a busy Firebird server without downtime

Production Firebird databases often run 24/7, and taking a traditional backup with gbak requires either shutting down the engine or placing the database in a read‑only state, which blocks applications. Administrators need a method that creates a usable copy while the server continues to accept writes, with minimal impact on performance.

How nbackup enables near‑zero‑downtime incremental backups

Firebird’s nbackup utility works by creating a temporary snapshot of changes (a delta file) rather than copying the whole database each time. A level‑0 backup captures the entire database file. Subsequent level‑1 (or higher) backups store only the pages that have changed since the last backup of the same or lower level. To restore, the engine merges the base file with the applicable delta files in order.

Because the delta file is written while the database remains online, there is no table lock. The trade‑off is that heavy write activity can cause the delta to grow large, consuming extra disk space and I/O bandwidth.

Worked example: setting up a level‑0 base and a level‑1 incremental

Assume the database file is located at /var/lib/firebird/data/mydb.fdb and you have a backup directory /backups/firebird with sufficient free space (at least the size of the database plus expected delta). The Firebird service runs under the firebird OS user, so the backup commands must be executed by a user that can read the database file and write to the backup directory.

1. Take the initial level‑0 base backup:

# Run as a user with read access to /var/lib/firebird/data/mydb.fdb
# and write access to /backups/firebird
nbackup -l 0 /var/lib/firebird/data/mydb.fdb /backups/firebird/mydb_level0.nbk

This creates mydb_level0.nbk, a copy of the entire database at that moment.

1. After some period (e.g., six hours), take a level‑1 incremental backup:

nbackup -l 1 /var/lib/firebird/data/mydb.fdb /backups/firebird/mydb_level1.nbk

The resulting mydb_level1.nbk contains only the pages that changed since the level‑0 backup.

1. To restore to a test point, merge the base and the incremental:

# Choose a test directory, e.g., /tmp/fb_test
mkdir -p /tmp/fb_test
nbackup -r /tmp/fb_test/mydb_test.fdb /backups/firebird/mydb_level0.nbk /backups/firebird/mydb_level1.nbk

The command creates mydb_test.fdb by applying the delta to the base file.

Trade‑offs and limitations

• Disk space: You need space for the base file plus each delta. If write volume is high, delta files can approach the size of the full database.
• Backup chain integrity: Mixing levels incorrectly (e.g., taking a level‑2 without a preceding level‑1) breaks the restore chain. Keep a clear labeling scheme and retain all required files until a new base is established.
• I/O impact: While nbackup does not lock tables, the delta file is written synchronously with database page changes, which can increase I/O load during peak write periods.

Monitor the size of delta files with ls -lh and track I/O with tools like iostat or the Firebird MON$ tables.

Verification steps

After restoring the test database, confirm it is usable and not corrupted:

1. Connect with isql and run a simple metadata query:

isql -u SYSDBA -p masterkey /tmp/fb_test/mydb_test.fdb
SQL> SELECT COUNT(*) FROM RDB$RELATIONS;

The query should return a non‑zero count without error.

1. Run a full validation:

gfix -v -full /tmp/fb_test/mydb_test.fdb

No output indicates a clean verification.

1. Check that the On‑Disk Structure (ODS) version matches the original:

gstat -h /var/lib/firebird/data/mydb.fdb   # note ODS value
 gstat -h /tmp/fb_test/mydb_test.fdb      # should be identical

Actionable closing

If your Firebird server is version 2.5 or newer, adopt nbackup for online incremental backups by:

1. Scheduling a weekly level‑0 backup during a low‑traffic window.
2. Taking level‑1 (or level‑2) backups at your desired frequency (e.g., every 4‑6 hours).
3. Retaining the base and all delta files until a new level‑0 is created, then pruning the old chain.
4. Regularly verifying restore capability on a test server using the steps above.

By monitoring delta growth and I/O, you can catch potential space or performance issues before they affect production, ensuring that your backup strategy provides both safety and near‑zero downtime.