Firebird almacena y mantiene todos los metadatos para sus propios objetos y los del usuario en -una base de datos de Firebird! Más precisamente, las almacena en relaciones (tablas) directamente en la base de datos. Los identificadores de las tablas de sistema, sus columnas y varios otros tipos de objetos de sistema comienzan con los caracteres RDB$.

Debido a que son objetos de bases de datos ordinarios, pueden ser consultados y manipulados de la misma manera que los objetos definidos por un usuario. No obstante, el que pueda no implica que deba hacerlo. El motor de Firebird implementa un subconjunto de alto nivel de SQL (DDL) para el propósito de definir y operar sobre objetos de metadatos, típicamente a través de las sentencias CREATE, ALTER y DROP.

Nunca es poca la recomendación de que utilice DDL -no operaciones directas SQL sobre las tablas de sistema- cada vez que necesite alterar o eliminar metadatos. Difiera las operaciones “caseras” hasta que su nivel en SQL y su conocimiento del motor de Firebird se vuelva muy avanzado. Una base de datos retocada no es linda de mantener ni barata de reparar.

Firebird se instala con la escritura forzada (escritura sincrónica) habilitada por defecto. Los datos modificados y agregados son escritos a disco inmediatamente luego de ingresados.

Es posible configurar una base de datos para que utilice escritura de datos asincrónica -donde los datos modificados o nuevos son mantenidos en memoria intermedia para ser volcada a disco periódicamente por el subsistema de E/S del sistema operativo. El término común para esta configuración es escritura no forzada (forced writes off) (o deshabilitada). A veces se recurre a esta configuración para incrementar el rendimiento durante operaciones largas.

La gran advertencia aquí es: no deshabilite la escritura forzada en un servidor Windows. Ha sido observado que las plataformas de servidor Windows no vacían el caché de escritura hasta que el servicio Firebird sea detenido. Aparte de interrupciones de poder, hay demasiadas otras cosas que pueden ir mal en un servidor Windows. Si se detiene, el sistema de E/S queda fuera de alcance y el trabajo de sus usuarios se perderá en el proceso de reinicio.

Una de las opciones de la utilidad gbak (gbak -r[estore]) le permite restaurar un archivo gbak sobre una base de datos existente. Es posible que este tipo de restauración se ejecute aún sin advertir que hay usuarios conectados a la base de datos: la corrupción de la base de datos está prácticamente asegurada como resultado.

Si es posible, se recomienda que restaure el respaldo a un lugar vacío del disco usando la opción gbak -c[reate] y verifique la base de datos restaurada usando isql o su herramienta de administración preferida. Si la base de datos restaurada es correcta, desactive (shutdown) el servidor. Haga una copia del archivo de la antigua base de datos y luego copie el archivo (o los archivos) de base de datos restaurados sobrescribiendo los existentes.

Si Ud. no bloquea el acceso a los usuarios mientras realiza una restauración usando gbak -r[estore] entonces los usuarios serán capaces de conectarse e intentar operar sobre los datos. En este caso, el resultado serán estructuras corruptas.