FAQ FirebirdConsultez toutes les FAQ

GBAK est un outil de backup, mais ses performances sont identiques à celles de tout autre client Firebird. Il lit toute la base de données et la sauvegarde. A la restauration, il restaure la base entière.
si vous recherchez une solution de backup incrémenté, jetez un ?il à l'utilitaire NBACKUP, disponible avec Firebird 2.

Par défaut, GBAK fait un nettoyage de la base au cours du backup. Comme le backup et le nettoyage sont des opérations de maintenance et que les deux parcourent la base entière, c'est une bonne idée de le faire en même temps.
Si la vitesse est votre principal objectif, vous pouvez désactiver le nettoyage avec l'option -G (ou l'option appropriée de votre outil d'administration)
Traduction réalisée depuis http://www.firebirdfaq.org/faq85/

Si vous faites des backups réguliers, vous pourrez remarquer que la taille de la base de données comme celle du fichier de backup change, même si aucune application n'a utilisé la base.
La raison en est le backup lui-même. Quand le backup est initié via les services API ou directement avec GBAK il démarre une transaction 'cliché' pour lire les données.
Chaque transaction est enregistrée en tête de la base de données (dans l'inventaire des transactions), donc le fichier base de données va changer.
De plus, si vous exécutez GBAK sans l'option -g, il exécute un nettoyage de la base (garbage collection , littéralement ramassage des ordures) qui, lui aussi, modifie la base de données.

Si vous voulez empêcher ces changements, utilisez GFIX pour mettre la base de données en mode lecture seule, ainsi :

gfix -mode read_only database.fdb

C'est une combinaison de problèmes avec les anciennes versions de Firebird (1.x).
Le premier est que les utilisateurs peuvent se connecter alors que la base est en cours de restauration.
Le second est qu'il pouvait y avoir des opérations comme la création de clés étrangères requérant un accès exclusif à la base de données. Ainsi, si quelqu'un se connecte à la base alors que vous êtes en train de la restaurer, vous n'êtes plus l'unique utilisateur et la restauration des clés étrangères échoue. Des problèmes identiques peuvent survenir avec d'autres objets, toujours pour les mêmes raisons .

La pratique courante pour éviter cela est de toujours restaurer dans une base temporaire puis de la renommer une fois l'opération terminée.
Effacer ou renommer la base d'origine avant de démarrer la restauration est également recommandé car des utilisateurs peuvent essayer de travailler avec (sur la 'vieille' base) alors que vous restaurer et que les données seront alors perdues.
Désactiver les connexions au serveur en utilisant un pare-feu est également une bonne alternative, sauf si vous avez des connexions locales (à partir d'applications web ou intranet par exemple).

Firebird 2 est bien meilleur car il bloque les utilisateurs pendant que la base de données est en cours de restauration et permet également la création de clés étrangères sans le besoin d'accès exclusif.
Traduction réalisée depuis http://www.firebirdfaq.org/faq172/

Ce switch '-r' n'a jamais causé que des problèmes. L'avertissement général est de ne jamais utiliser le -r, car R est le R de 'Replace' non celui de 'Restore'

Significations de quelques options

• gbak -b backup
• gbak -r replace
• gbak -c create
  
  

Vous avez probablement indiqué la taille du fichier en bits, kilo-bits ou méga-bits, alors que cela aurait du l'être en pages de base de données.
Par exemple, si votre taille de page est de 4kB, alors un fichier d'une taille de 1MB sera égal à 256 pages.
Traduction réalisée depuis http://www.firebirdfaq.org/faq146/

Lors de la restauration de grosses bases de données sous Linux, vous pouvez obtenir ce genre d'erreur :

1
2
3
I/O error for file "/tmp/fb_sort__xxxxxx"<br/> 
-Error while trying to read from file<br/> 
-No such file or directory<br/>

Généralement, vous pouvez copier le fichier base de données. Mais, attention

Si vous le copiez quand le serveur Firebird est éteint, il n'y aura aucun problème, c'est juste un fichier comme un autre. Même chose si aucun utilisateur n'est connecté.

Copier la base de données en cours d'utilisation , par contre est une mauvaise idée. Firebird peut très bien écrire de nouvelles transactions pendant le process de copie, votre copie risque d'être corrompue.
Il est toujours préférable de faire un backup/restore.

Si le backup/restore est trop lent à votre goût, ou si vous voulez utiliser un outil tiers ne supportant que la copie de fichier, vous pouvez résoudre le problème en utilisant l'outil nBackup de Firebird.

• Verrouillez la base avec nbackup
• Copiez le fichier
• Déverrouillez la base
  
  

Vous pouvez le faire avec l'outil open source FBExport (valable pour Windows et Linux)
http://www.firebirdfaq.org/fbexport.php

Traduction réalisée depuis http://www.firebirdfaq.org/faq280/