Firebird stocke et maintient toutes les métadonnées de ses propres objets ainsi que ceux que vous définissez dans : une base de données Firebird ! Plus précisément, il stocke ceux-ci en relations (tables) directement dans la base elle même. Les identifiants pour les tables système, leurs colonnes ainsi que plusieurs autres types d'objets système commencent avec les caractères RDB$.

Puisqu'ils sont des objets de base de données ordinaires, ils peuvent être interrogés et manipulés comme les objets que vous définissez. Cependant, ce n'est pas parce que vous le pouvez que vous le devez. Le moteur de Firebird implémente un ensemble d'outils SQL de haut niveau (DDL) dans le but de définir et maintenir les métadonnées, classiquement à l'aide des commandes CREATE, ALTER et DROP.

On ne peut jamais recommander assez de n'utiliser que DDL – pas d'opérations directes en SQL sur les tables systèmes – pour modifier ou supprimer des métadonnées. Evitez les « trucs et astuces » tant que votre connaisance du SQL et du moteur Firebird ne sont pas à un niveau très élevé. Une base de données sabordée coûte cher en réparations.

Firebird est installé avec le paramêtre forced writes (ecritures synchrones) activé par défaut. Les modifications ou les nouvelles données sont immédiatement écrites sur le disque dès leur signalement.

Il est possible de configurer une base de données pour qu'elle utilise l'écriture des données asynchrone – ce qui permet de garder en mémoire cache les nouvelles données ou modifications. La mémoire cache est vidée périodiquement sur le disque par le sous-système d'entrée sortie du système d'exploitation. Le terme commun pour cette configuration est forced writes off (ou désactivé). Il est quelquefois intéressant d'y avoir recours afin d'améliorer les performances pendant de grandes operations en lots.

Le mot d'ordre ici est : ne désactivez pas les écritures forcées sur un serveur Windows. On a observé que les serveurs Windows ne vident pas le cache tant que le service Firebird n'est pas arrété. Indépendament des coupures de courant electrique, il y a trop de choses qui peuvent mal fonctionner sur un serveur Windows. Si votre serveur plante, le système d'E/S ne fera pas son travail et vos utilisateurs perdront leur travail au redémarrage.

Une des options de restauration de l'utilitaire gbak (gbak -r[eplace]) vous permet de restaurer un fichier gbak par dessus une base de données existante. Il est possible d'effectuer ce style de restauration sans même avertir les utilisateurs connectés à la base de données. Dans un tel cas, il est presque certain que la base de données sera endommagée.

Si cela est possible, il est recommandé de restaurer sur un autre espace disque en utilisant l'option gbak -c[reate] et tester la base restaurée en utilisant isql ou votre outil préféré d'administration. Si la base restaurée est bonne, arrêtez le serveur Firebird. Faites une copie de votre ancienne base puis copiez le ou les fichiers de la base restaurée en lieu et place des fichiers originaux.

Si vous ne bloquez pas l'accès des utilisateurs pendant le processus de restauration en utilisant gbak -r[eplace] alors les utilisateurs peuvent se connecter et tenter de faire des opérations sur les données. La structure sera alors endommagée.