Firebirdは自身のオブジェクトとユーザーが作成した全てのオブジェクト
のメタデータをデータベース中に格納して管理しています。もっとはっきり言えば、
それらのオブジェクトはデータベース自身の関連テーブルに正しく格納されています。
システムテーブルとそれらのカラムやその他の幾つかのシステムオブジェクトの識別子は
RDB$で開始されています。

これらは通常のデータベースオブジェクトであるため、ユーザー定義のオブジェクト
と同様にクエリーをかけたり操作したりすることが出来ます。しかしながら、これらの操作
をすべきではありません。Firebirdのデータベースエンジンはメタデータオブジェクトを
定義し操作するために、高いレベルでSQL(DDL)のサブセットを実装しています。それらは、
CREATEやALTER、またDROP
文として実行することが可能です。

システムテーブルの直接的な操作をSQLでやることはもちろん、メタデータを変更したり
削除したりする時に、DDLを使うことはあまり強くお勧め出来ません。SQLの技術とFirebirdエンジン
に関する知識が十分なレベルに到達するまで、その「衝動」を先延ばしした方がよいでしょう。
大破したデータベースはちょっとした注意や簡単な修理で何とかなるものではないからです。

Firebirdはデフォルトでforced writes(同期書込モード）をONにしてインストールされています。
データの変更や新規の挿入はディスクへ即座に書き込まれています。

データベースを非同期書込モードに変更することは可能ですが、それによってデータの変更や
新規のデータはメモリキャッシュ中に保持され、オペレーティングシステムのI/Oサブシステムが定期
的にその内容をディスクへ書き込むことになります。こうした変更は、forced writes off
(又はdisabled)の設定をすることで可能です。この設定は
大規模なバッチオペレーション等でパフォーマンスの向上を図るためになされることがあります。

しかし重大な警告をしなくてはなりません。Windowsサーバー上では、forced writesを
disableに絶対にしてはいけません。Windowsサーバーでは、Firebirdサービス
をシャットダウンするまで書込キャッシュがフラッシュされなかったという事が報告されています。
電源異常による中断は別として、Windowsサーバーの行いはかなり酷いものです。もし、OSがハングして
I/Oシステムにまでそれが及んだ場合、ユーザーの行った操作はリブートプロセスによって全て失われて
しまいます。

gbakのリストアのオプションの一つに(gbak -r[eplace])
があり、gbakが既存のデータベースを上書きすることを認めることが出来ます。この時、ユーザーがデータベースに
ログインしていても警告すること無しにリストアが実行されてしまいます。結果として、データベースの破壊が
たいていの場合は確実に起きてしまします。

実際上どうすればよいのかということでは、スペアのディスクスペースにgbak -c[reate]
オプションを使用してリストアを行い、isql等のツールを使用して十分にテストを
行うことを推奨します。リストアされたデータベースが問題なければ、サーバーをシャットダウンして、古いデータベース
のコピーをファイルシステム上で行い、リストアしたデータベースで既存のデータベースを上書きして下さい。

gbak -r[eplace]によってリストア中のデータベースにユーザーの
ログインを認めてしまった場合、ユーザーのデータ操作によって、データベースが壊れてしまうでしょう。