Limits of Firebird 4.0 RESTORE DATABASE WITH CHECKSUM Validation

Direct Answer

WITH CHECKSUM in Firebird 4.0 validates data pages only—it does not verify transaction log (WAL) pages or other auxiliary structures. When restoring a backup created without gbak --checksum, the restore will either fail immediately with a checksum-mismatch error or skip validation for those pages, depending on the exact backup format version. It does not silently truncate data.

Confirmed Behavior

• Page-level verification: Each data page in the backup stream carries a stored checksum when gbak --checksum was used. RESTORE ... WITH CHECKSUM recalculates and compares it during restore.
• No post-facto checksum generation: If the backup lacks checksum metadata, Firebird cannot invent it. The restore either aborts on the first page that should have had a checksum but does not, or (in some format versions) proceeds without page validation.
• Transaction log is separate: The write-ahead log is reconstructed from the restored database state; it is not part of the backup stream and therefore not covered by WITH CHECKSUM.

Likely Explanation for Reported Symptoms

Users seeing "silent truncation" or "abrupt failure with generic errors" are likely encountering one of two scenarios:

1. Format mismatch: A Firebird 2.5/3.0 backup restored on 4.0 with WITH CHECKSUM may trigger a legacy-format error that surfaces as a generic I/O or corruption message.
2. Partial checksum presence: Some page types (e.g., header pages) may carry checksums even in a non-checksum backup, causing the validator to fail on those specific pages while others pass silently.

Recommended Practice

1. Always create backups with gbak --checksum if you intend to use RESTORE ... WITH CHECKSUM.
2. For existing non-checksum backups, restore without WITH CHECKSUM, then run gfix -validate -full on the restored database to catch logical corruption.
3. After restore, check firebird.log for lines containing "checksum" or "page" to confirm validation actually ran.

Verification Steps (Run Once)

# 1. Create test DB
isql -q -c "create database 'test.fdb' user 'sysdba' password 'masterkey';"

# 2. Backup WITHOUT checksum
gbak -b -user sysdba -pas masterkey test.fdb test_no_csum.fbk

# 3. Attempt restore WITH checksum (expect failure or warning)
gbak -c -user sysdba -pas masterkey test_no_csum.fbk test_restored.fdb -v -checksum 2>&1 | tee restore.log

# 4. Inspect firebird.log for checksum-related entries
grep -i checksum firebird.log

# 5. Compare with checksum-enabled backup
gbak -b -checksum -user sysdba -pas masterkey test.fdb test_with_csum.fbk
gbak -c -checksum -user sysdba -pas masterkey test_with_csum.fbk test_restored2.fdb -v

One Diagnostic Detail Needed

What exact Firebird 4.0 sub-version (e.g., 4.0.0, 4.0.3) and backup format (gbak -v output shows "OIT"/"OAT" numbers) are you using? The behavior for non-checksum backups changed between early 4.0 point releases.