Firebird speichert und verwaltet alle Metadaten in speziellen Tabellen, genannt Systemtabellen, die ebenfalls in der Datenbank abgelegt sind. Die Bezeichner für diese Tabellen, dessen Felder und einigen anderen Systemobjekttypen beginnen mit der Zeichenfolge RDB$.

Da es sich hierbei um normale Datenbankobjekte handelt, können diese, so wie jede andere benutzerdefinierte Tabelle, abgefragt und geändert werden. Nichtsdestotrotz, nur weil Sie das können, heißt das nicht, dass Sie das tun sollen. Die Firebird Engine implementiert hierfür eine höher angesiedelte Teilmenge von SQL genannt DDL, um die Definition und die Arbeit mit Metadatenobjekten zu ermöglichen. Typischerweise handelt es sich hier um CREATE, ALTER und DROP Anweisungen.

Es kann nicht streng genug darauf hingewiesen werden, dass Sie DDL und nicht direkte SQL Operationen auf Systemtabellen verwenden sollen, wann immer Sie Metadaten ändern oder entfernen. Verschieben Sie daher die „Hot Fix“ Aktivitäten bis Sie fit in SQL und Ihr Wissen über die Firebird Engine entsprechend groß ist. Eine zerstörte Datenbanken ist weder hilfreich, noch günstig zu reparieren.

Firebird wird per Default mit Forced Writes (Synchrones Schreiben) installiert. Geänderte und neue Daten werden hiermit sofort auf die Festplatte geschrieben.

Es ist jedoch möglich, eine Firebird Datenbank so zu konfigurieren, dass ein asynchrones Schreiben verwendet wird, wo Änderungen und neue Daten vorerst im Cache gehalten werden, um diese dann durch das I/O Subsystem des Betriebssystems, periodisch auf die Festplatte zu schreiben. Die allgemeine Bezeichnung für diese Konfiguration ist Forced Writes Off (= deaktiviert). Auf diese Konfiguration wird manchmal zurückgegriffen, um große Batch-Operationen zu beschleunigen.

Die große Warnung ist nun: Deaktivieren Sie Forced Writes auf einem Windows Server nicht. Es wurde beobachtet, dass auf Windows Server Plattformen der Schreibcache nicht auf die Festplatte geschrieben wird, bis der Firebird Dienst gestoppt wird. Neben Stromausfällen gibt es einfach zu viele Situationen auf einem Windows Server, die schief gehen können. Bei einem Absturz bekommt das I/O System keine Möglichkeit die Änderungen noch auf die Festplatte zu schreiben und somit sind diese Änderungen bei einem Neustart verloren.

Eine der Wiederherstellungsoptionen des gbak Tools (gbak -rep[lace_database]) erlaubt Ihnen eine Wiederherstellung einer gbak Datei über eine existierende Datenbank. Für diese Art der Wiederherstellung ist es möglich, dass der Wiederherstellungsprozess ohne Warnungen durchgeführt wird, obwohl Benutzer mit der Datenbank verbunden sind. Mit großer Sicherheit kann dies eine beschädigte Datenbank als Ergebnis haben.

Besser ist es, wenn Sie das Restore unter Verwendung der gbak -c[reate] Option auf einer Festplatte mit genügend freien Speicherplatz durchführen, und im Anschluß die wiederhergestellte Datenbank mit isql oder Ihrem bevorzugten Administrationstool testen. Falls die wiederhergestellte Datenbank in Ordnung ist, stoppen Sie den Firebird Server. Erstellen Sie danach eine Kopie der alten Datenbank auf Dateisystemebene und kopieren Sie die wiederhergestellte(n) Datenbankdatei(en) über die existierende(e) Datenbankdatei(en).

Falls Sie den Zugriff für Benutzer während einer Wiederherstellung unter Verwendung von gbak -rep[lace_database] nicht unterbinden, kann dies ebenfalls zur Folge haben, dass dies in einer beschädigten Datenbank endet.