Reducing Downtime with Firebird nbackup Incremental Backups

For large Firebird databases, the traditional logical backup (gbak) can become a bottleneck, requiring significant time and resources that often force administrators to schedule backups during narrow maintenance windows. When a database reaches several gigabytes, the time required to export and import the entire structure can lead to unacceptable downtime.

The solution is nbackup. Unlike logical backups, nbackup performs a physical, page-level backup. This allows the database to remain online and accessible for read-write traffic while the backup process runs in the background. By using incremental levels, you can avoid the cost of a full backup every day, capturing only the pages that have changed since the last run.

The Mechanics of Page-Level Backups

Firebird organizes data into pages. nbackup reads these pages directly from the disk. A Level 0 backup is a full physical copy of the database. A Level 1 backup is an incremental copy; it identifies which pages have been modified since the last backup and saves only those specific pages.

Because this happens at the physical layer, the backup is generally faster than a logical export. However, it is important to note that nbackup captures the state of the pages at the moment the backup starts. It does not track logical transaction boundaries, meaning any uncommitted transactions at the time of the backup will be handled by Firebird's standard recovery process upon restoration.

Implementing a Backup Strategy

To use nbackup, you must run the utility on the server host where the Firebird engine is active. You require permissions to read the database file (.fdb) and write permissions for the destination backup directory. It is recommended to run these commands as the Firebird service user.

Step 1: Establish the Baseline (Level 0)

Run the following command to create your full physical backup. Replace MYDB with your database alias or the absolute path to the file.

# Run on Firebird server as the service user
nbackup -B 0 MYDB /backups/full_baseline.fbk

Check: Verify the exit code of the process. An exit code of 0 indicates success. Ensure the full_baseline.fbk file size roughly matches your current .fdb file size.

Step 2: Capture Changes (Level 1)

After data modifications have occurred, run a Level 1 backup to capture only the changed pages.

# Run on Firebird server as the service user
nbackup -B 1 MYDB /backups/incremental_day1.fbk

Check: The resulting file should be significantly smaller than the Level 0 backup, as it only contains modified pages.

Restoring the Backup Chain

Restoration is a sequential process. You cannot apply a Level 1 backup without first applying the Level 0 baseline. To restore to a new instance or a test environment, use the -R flag followed by the backup files in the exact order they were created.

# Restore to a new database alias TESTDB
nbackup -R TESTDB /backups/full_baseline.fbk /backups/incremental_day1.fbk

Risk: If any file in the chain (e.g., incremental_day1.fbk) is deleted or corrupted, you cannot restore any subsequent increments. The chain is broken, and you must revert to the last known good full backup.

Trade-offs and Verification

While nbackup minimizes downtime, it introduces different risks than logical backups:

• Chain Dependency: Logical backups (gbak) are standalone. nbackup increments are dependent.
• Physical State: Because it is a physical copy, it doesn't "clean" the database of fragmentation the way a gbak restore does.
• I/O Impact: While the DB stays online, the physical read process increases disk I/O, which may impact performance during peak hours.

To verify the result, perform a row count on a high-activity table in the restored TESTDB. Compare this count to the production database at the time the incremental backup was taken. If the counts match and the database is accessible, the physical chain was successfully applied.