Guide rapide pour la sauvegarde-restauration Gbak

Qu’est-ce que gbak ?

Gbak est un outil standard en ligne de commande de Firebird (voir sa documentation officielle ici), conçu pour effectuer 1) la sauvegarde complète de la base de données : il lit chaque enregistrement de la base de données et les stocke dans le fichier de sauvegarde, 2) la restauration de la sauvegarde vers une nouvelle base de données.

Pour les développeurs et administrateurs ayant de l’expérience avec d’autres SGBD, le terme « sauvegarde » peut être un peu déroutant, car gbak ne produit pas une copie exacte de la base de données, mais un fichier dans un format non-base de données, contenant uniquement les données (les index sont stockés sous forme de déclarations).

Pour créer une base de données à partir du fichier de sauvegarde gbak, le processus de restauration avec gbak doit être effectué.

1. Maîtriser les sauvegardes avec Gbak

1.0. Préparation

Créons le dossier C:\data et plaçons-y une base de données. Nous utiliserons une base de données de 5 Go issue du test Firebird OLTP-EMUL, mais vous pouvez bien sûr utiliser votre propre base de données.

Pour les utilisateurs Linux - créons le dossier /db et changeons son propriétaire en « firebird », puis copions la base de données (assurez-vous que son propriétaire est également firebird).

Code

mkdir /db
chown firebird -R /db

1.1 La sauvegarde Firebird la plus simple avec la commande gbak

Windows

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Dans cet exemple, l’outil gbak accède au fichier de base de données en utilisant un accès local ou embarqué.

Firebird 3.0 : L’accès embarqué dans la configuration par défaut de Firebird 3.0 (avec le paramètre ServerMode = SuperServer dans firebird.conf) tentera de placer un verrou exclusif sur la base de données, de sorte que les autres connexions ne pourront pas accéder à la base de données (ou la tentative de gbak échouera en raison des connexions actives).

Firebird 2.5 : Avec Firebird 2.5 sur Windows, la commande fonctionnera correctement via le protocole XNET (si vous n’avez qu’une seule instance de Firebird en cours d’exécution, bien sûr). Sur Linux, Firebird tentera d’utiliser l’accès embarqué ; s’il n’est pas accessible, il essaiera automatiquement (et implicitement) de se connecter via TCP/IP. (Si vous ne savez pas ce que signifient XNET, INET, etc., veuillez consulter l’aide-mémoire des chaînes de connexion Firebird).

Remarque 1 : Cette commande s’exécute sous le compte de l’utilisateur du système d’exploitation (c’est-à-dire le vôtre) et utilise ses autorisations pour accéder aux fichiers de sauvegarde et de base de données.

Normalement, le service Firebird sur Windows s’exécute avec le compte LocalSystem, et sur Linux sous l’utilisateur « firebird », mais la console est généralement exécutée sous votre propre compte utilisateur.

Si ce compte utilisateur n’a pas accès au chemin de la base de données ou au chemin de sauvegarde, gbak échouera avec l’erreur « Cannot open backup file » (voir l’exemple dans l’Annexe A. Erreurs, #5).

Remarque 2 : gbak -b écrase silencieusement le fichier de sauvegarde. Donc, si vous avez déjà backup1.fbk, il sera écrasé.

Remarque 3 : Sur Linux, cette commande gbak créera un fichier de sauvegarde dont le propriétaire sera l’utilisateur de la console.

Temps de sauvegarde pour cette commande : 120 secondes

1.2. Sauvegarde locale avec gbak qui peut être effectuée en ligne sur Windows

Cette section est réservée aux utilisateurs Windows ! En général, nous devons effectuer une sauvegarde alors que nous avons des connexions actives à la base de données. Il est donc préférable de spécifier explicitement le protocole local au lieu d’une connexion embarquée, afin d’éviter que gbak lui-même ne place un verrou exclusif sur le fichier de base de données dans Firebird 3, c’est-à-dire XNET.

Pour Firebird 3.0 :

Code

gbak -b xnet://c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Pour Firebird 2.5, nous pouvons utiliser une chaîne de connexion locale, et elle utilisera également XNET :

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Sur Linux, Firebird ne prend pas en charge un protocole local spécifique comme XNET sur Windows, il est donc nécessaire d’utiliser une chaîne de connexion TCP/IP (voir la section 1.3).

De plus, XNET ne fonctionne que pour une seule instance de Firebird. Si vous exécutez plusieurs instances de Firebird sur Windows, il pourrait être plus facile d’utiliser une chaîne de connexion de style INET pour spécifier l’instance serveur cible.

Temps de sauvegarde : 139 secondes

1.3. Sauvegarde avec gbak avec chaîne de connexion TCP/IP

C’est la commande gbak la plus universelle pour effectuer une sauvegarde en ligne.

Windows

Code

gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Dans ce cas, en spécifiant localhost: au début du chemin de la base de données, la connexion est effectuée via le sous-système réseau de Firebird.

C’est légèrement plus lent que l’accès local mais fonctionne dans tous les cas où nous avons un serveur en cours d’exécution qui accepte les connexions.

Port non standard pour Firebird

Si Firebird fonctionne sur un port non standard (par exemple, 3051 au lieu de 3050), vous pouvez effectuer la sauvegarde de cette manière :

Windows

Code

gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Temps de sauvegarde : 182 secondes

1.4. Sauvegarde plus rapide avec gbak avec Service Manager

Comment pouvons-nous obtenir l’universalité de la connexion TCP/IP, avec le support d’un port non standard, et une sauvegarde locale rapide ? Utilisons Service Manager ! Service Manager, en termes simples, est le moyen d’exécuter des outils standard via le moteur Firebird. Veuillez noter que dans le cas de Service Manager, il n’est pas nécessaire de spécifier le nom du serveur dans le chemin de la base de données, seulement dans le paramètre -se.

Windows

Code

gbak -b -se localhost:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Cette commande utilise l’option -service pour spécifier que nous voulons utiliser le Service Manager de l’instance Firebird sur le port 3050 pour effectuer la sauvegarde.

Dans ce cas, la sauvegarde sera effectuée directement à l’intérieur du processus Firebird (il contient une copie du code de gbak), et comme la communication intra-processus est beaucoup plus rapide, la sauvegarde sera nettement plus rapide dans ce cas.

Si Firebird fonctionne sur un port non standard (par exemple, 3051), la commande peut ressembler à :

Code

gbak -b -se localhost/3051:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Remarque : Il y a une limitation importante dans Firebird 2.5 et Firebird 3.0.0-3.0.5 (supprimée seulement en 3.0.6) : la ligne de commande (tous les paramètres et chemins pour la base de données et pour la sauvegarde) doit être inférieure à 256 symboles.

Si vous atteignez cette limite, par exemple en raison de chemins longs pour la base de données et la sauvegarde, vous pouvez déclarer un alias pour la base de données dans databases.conf (3.0 et supérieur) ou aliases.conf (2.5) :

Code

mydb1=c:\Data\test1.fdb #Windows

Code

mydb1=/db/test1.fdb  #linux

puis l’utiliser dans notre commande :

Windows

Code

gbak -b -se localhost:service_mgr mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

Temps de sauvegarde : 115 secondes

1.5. La sauvegarde la plus rapide avec gbak avec collecte des déchets inhibée

Pour rendre la sauvegarde encore plus rapide, ajoutons l’option -g

Code

 -G(ARBAGE_COLLECT)    inhiber la collecte des déchets

Ainsi, la commande de sauvegarde sera la suivante

Windows

Code

gbak -b -se localhost:service_mgr -g mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr -g mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

L’option -g force le moteur Firebird à désactiver la collecte des déchets pour le processus de sauvegarde dans le fichier de base de données.

Cela ne signifie pas que les versions d’enregistrements orphelines seront stockées dans le fichier de sauvegarde ; cela signifie que le serveur n’essaiera pas de nettoyer les déchets existants dans la base de données pendant la sauvegarde, et la sauvegarde sera plus rapide.

Nous recommandons fortement d’utiliser cette option, car nous pensons que la collecte des déchets et le nettoyage associé doivent être effectués par sweep (gfix -sweep ou autosweep). Il est donc préférable de ne pas considérer gbak comme une quelconque alternative au sweep.

Temps de sauvegarde : 105 secondes

1.6. Sauvegarde vers un partage réseau ou un emplacement réseau

Que faire si nous devons placer le fichier de sauvegarde sur un partage réseau ?

Sur Windows

La confusion fréquente des nouveaux utilisateurs de Firebird : la sauvegarde manuelle (lorsque vous lancez la commande depuis une invite de commandes), avec un simple gbak -b, vers un partage réseau fonctionne correctement, mais la version rapide de gbak avec -se localhost:service_mgr ne fonctionne pas.

La raison est que Firebird sur Windows s’exécute sous le compte LocalSystem, qui n’a pas accès aux emplacements réseau (sauf si ces partages réseau ont configuré l’accès pour le groupe « Everyone », mais c’est très très dangereux à notre époque de rançongiciels).

La solution est d’exécuter le service Firebird sur Windows sous un compte disposant de droits suffisants pour accéder au partage réseau et, simultanément, de droits suffisants pour accéder aux fichiers de base de données locaux et aux fichiers système dans C:\ProgramData\Firebird. De plus, une bonne idée est de configurer le paramètre RestrictAccess dans firebird.conf.

Sur Linux

Comme Firebird sur Linux s’exécute sous le compte « firebird », montez le partage réseau avec un mappage vers l’utilisateur « firebird », afin que le service Firebird puisse accéder à l’emplacement réseau de la même manière qu’un lecteur local.

1.7. Sauvegarde simple du serveur distant vers la machine locale

Il est possible de sauvegarder la base de données du serveur distant vers la machine locale.

La commande d’exemple ci-dessous démarre sur un ordinateur Windows, accède à la base de données sur un serveur Linux (avec l’adresse IP 192.168.0.108, mais le nom d’hôte du serveur peut également être utilisé, bien sûr), et le fichier de sauvegarde est stocké dans le dossier C:\Data sur Windows) :

Code

gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb c:\data\remotebackup1.fbk

Temps de sauvegarde : 568 secondes

Cette commande sera généralement beaucoup plus lente que la sauvegarde locale, car gbak lit les données du serveur distant et transfère les enregistrements via le réseau.

1.8. Sauvegarde plus rapide du serveur distant vers la machine locale avec Service Manager

La commande ci-dessous est plus rapide que la sauvegarde traditionnelle du serveur distant vers la machine locale, décrite dans #1.7

Code

gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb stdout > C:\Data\remoteback1.fbk

Elle utilise Service Manager pour effectuer la sauvegarde sur le serveur distant, mais la sortie est envoyée vers le flux stdout, puis redirigée vers le fichier local.

Cette commande est généralement 15 % à 20 % plus rapide que celle du #1.7 (Sauvegarde simple du serveur distant vers la machine locale), pour les raisons suivantes :

elle effectue la sauvegarde via Service Manager sur le serveur distant, de sorte que toutes les opérations de lecture et de compression sont réalisées de la manière la plus rapide,
elle ne transfère via le réseau que le fichier de sauvegarde résultant, dont la taille est inférieure aux données de la base de données.

Cependant, avec cette commande, il n’est pas possible d’activer le mode verbeux et de stocker la sortie détaillée dans le fichier journal.

Temps de sauvegarde : 473 secondes

1.9. Sauvegarde de la base de données Firebird sur le serveur distant vers le même serveur distant à l’aide de Service Manager

Avec Service Manager, il est possible d’invoquer la sauvegarde gbak de la base de données sur le serveur distant et de la stocker également sur le même serveur distant.

Code

gbak -b -se  192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb /db/back12.fbk

Cette commande, via Service Manager, invoque la sauvegarde sur le serveur distant, avec l’instruction de stocker le fichier de sauvegarde également sur le même serveur réseau.

Bien sûr, l’emplacement de sauvegarde doit être accessible par le service Firebird (sur Linux, il s’exécute sous l’utilisateur « firebird », sur Windows sous le compte LocalSystem).

1.10. Sauvegarde de la base de données Firebird 6 fois plus rapide avec la sauvegarde multi-thread dans Firebird 5 (ou HQbird 2.5/3.0/4.0/5.0)

Si vous n’êtes toujours pas satisfait des performances de sauvegarde de gbak Firebird, envisagez de migrer vers Firebird 5 (ou utilisez la distribution Firebird d’entreprise : HQbird pour les autres versions).

Elle prend en charge la sauvegarde multi-thread, ce qui permet des opérations de sauvegarde jusqu’à 6 fois plus rapides avec gbak.

Code

gbak -b -par 8  -se localhost:service_mgr -g C:\Data\testbigdb1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Comme vous pouvez le voir, il y a un nouveau paramètre -par 8, qui fait utiliser à gbak 8 threads pour créer une sauvegarde.

HQbird effectue les tâches de maintenance (sweep, sauvegarde, restauration) beaucoup plus rapidement (les résultats sur la figure ci-dessous proviennent d’une base de données différente, bien sûr) :

2. Restauration avec l’outil Gbak

Nous avons le fichier de sauvegarde backup1.fbk, créé par l’une des commandes ci-dessus, et nous devons le restaurer, de manière rapide et efficace.

Supposons que le fichier se trouve dans C:\Data\backup1.fbk dans le cas de Windows, ou /db/backup1.fbk dans le cas de Linux.

2.1. La commande de restauration la plus simple

Sur Windows

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Sur Linux

Code

gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey

Tout d’abord, veuillez noter que gbak -c n’écrase pas le fichier de base de données, et s’il existe un fichier C:\data\new1.fdb ou /db/new1.fdb, gbak renverra une erreur indiquant que la base de données existe déjà.

Ensuite, cette commande fonctionne en réalité très différemment sur 2.5/3.0+ et Windows/Linux.

Sur Linux, cette commande utilisera l’accès embarqué à la base de données créée (si vous n’avez pas modifié l’ordre des fournisseurs Firebird dans firebird.conf, bien sûr) pour 3.0 et 2.5.

Sur Windows, avec Firebird 3.0 et l’ordre par défaut des fournisseurs, ce sera un accès embarqué, sur 2.5 - XNET.

Ensuite, cette commande crée un fichier avec les droits de l’utilisateur qui a lancé gbak, c’est particulièrement important sur Linux - si vous exécutez ce gbak sous root, le propriétaire du fichier de base de données sera root, et le processus Firebird, qui s’exécute sous l’utilisateur « firebird », ne pourra pas accéder au fichier restauré.

Note pour les utilisateurs Linux

Beaucoup de personnes, afin de « corriger » la propriété, appliquent des permissions pour que tout le monde puisse accéder à la base de données restaurée, c’est-à-dire quelque chose comme « chmod 777 database », mais c’est très peu sécurisé ; la bonne méthode consiste à changer le propriétaire de la base de données en firebird, avec la commande suivante

Code

chown firebird /db/new1.fdb

En général, cette commande est suffisante pour la restauration simple de bases de données non destinées à la production (utilisées pour les tests ou en développement).

Temps de restauration : 275 secondes

2.2. Restauration avec la chaîne de connexion localhost

L’option de restauration la plus universelle, mais pas la plus rapide, est la suivante :

Windows

Code

gbak -c C:\Data\backup1.fbk localhost:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Port non standard

Si Firebird s’exécute sur un port non standard, par exemple 3051, il peut être spécifié dans la commande de restauration :

Windows

Code

gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey

Temps de restauration : 1225 secondes

2.3. Restauration avec XNET sur Windows

Pour rendre la restauration un peu plus rapide, sur Windows, nous pouvons utiliser XNET (pour Firebird 3.0 et supérieur) :

Code

gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey

Sur Firebird 2.5 sur Windows, l’accès XNET sera utilisé avec la simple ligne de commande (s’il n’y a qu’une seule instance Firebird en cours d’exécution) :

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Temps de restauration : 585 secondes

2.4. Restauration plus rapide avec Service Manager

Et la manière la plus rapide de restaurer est d’utiliser Service Manager

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Avec l’option -se, nous invoquons Service Manager sur l’adresse localhost et lui demandons d’exécuter le code de restauration à l’intérieur du moteur Firebird.

Lorsque la restauration est effectuée par Service Manager, le fichier de base de données créé appartiendra au compte de l’instance Firebird en cours d’exécution (processus) - c’est « firebird » sur Linux, et LocalSystem sur Windows.

Temps de restauration : 244 secondes

2.5. Option non recommandée

À un moment donné, vous pourriez être tenté d’utiliser l’option suivante :

Code

   -R(ECREATE_DATABASE) [O(VERWRITE)] create (or replace if OVERWRITE used)                               database from backup file (restore)

Code

afin de forcer le remplacement de la base de données existante par la nouvelle.

D’après notre expérience, cette option augmente considérablement les risques d’écraser accidentellement la base de données de production.

Nous recommandons fortement de restaurer la base de données à chaque fois avec un nouveau nom et de la renommer, ainsi que de supprimer l’ancienne base de données, explicitement.

Nous ne fournirons même pas d’exemple de commande avec cette option.

2.6. Restauration de la base de données à l’aide d’un alias

Il est possible de restaurer la base de données à l’aide de l’alias, déclaré dans databases.conf (ou aliases.conf dans Firebird 2.5)

Par exemple, nous avons la déclaration suivante

Code

restdb=c:\Data\newrest1.fdb  #Windows

restdb=/db/newrest1.fdb  #Linux

Nous pouvons donc exécuter la commande suivante pour restaurer la sauvegarde vers le chemin spécifié par l’alias

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk restdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk restdb -user SYSDBA -pass masterkey

2.7. Restauration d’une sauvegarde locale vers le serveur distant

Il est possible de restaurer le fichier de sauvegarde local vers le serveur Firebird distant.

Dans cet exemple, nous restaurons le fichier de sauvegarde stocké sur Windows, vers le serveur Linux (son adresse IP 102.168.0.108) :

Code

gbak  -c C:\Data\backup1.fbk 192.168.0.108:/db/newdb1.fdb -user SYSDBA -pass masterkey

Temps de restauration : 7009 secondes

Comme vous pouvez le remarquer, le processus de restauration à distance fonctionne très lentement, pouvons-nous l’accélérer avec Service Manager ?

2.8. Restauration de la sauvegarde locale vers le serveur distant avec Service Manager

Pour restaurer la sauvegarde locale sur le serveur distant avec Service Manager, il est nécessaire d’utiliser l’astuce du flux d’entrée stdin :

Code

gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin /db/new3.fdb <  C:\Data\backup1.fbk

Cette commande invoque la restauration sur le serveur distant avec l’entrée standard stdin comme source de la sauvegarde - et fournit l’entrée en utilisant la partie < C:\Data\backup1.fbk de la commande.

Cela semble un peu astucieux ? Mais c’est un moyen facile d’augmenter de 10 fois les performances de gbak pour restaurer vers le serveur distant !

Temps de restauration : 450 secondes

2.9. Restauration de tables extrêmement longues

Si vous avez une très grande base de données avec un nombre total de lignes supérieur à 2 milliards, il est nécessaire de spécifier l’option -o[ne_at_a_time], pour restaurer chaque table dans une transaction séparée, afin d’éviter un débordement interne.

Code

gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user SYSDBA -pass masterkey

3. Ajustement et journalisation des processus de sauvegarde et de restauration

3.1. Gbak avec sortie verbeuse

Par défaut, gbak est un outil très silencieux, il ne renvoie rien en cas d’exécution réussie. Pour le rendre verbeux, nous pouvons ajouter l’option -v[erify]

Code

gbak -b -se localhost/3050:service_mgr -g mydb1  c:\Data\backup1.fbk -v -user SYSDBA -pass masterkey

En conséquence, il y aura plus de détails. Le problème mineur mais ennuyeux est que l’impression de la sortie sur la console peut rendre la sauvegarde verbeuse considérablement plus lente que la variante silencieuse, donc une bonne idée serait d’enregistrer le journal dans le fichier avec l’option - y logfile :

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1  c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Note : gbak n’écrasera pas le fichier journal existant ! Si vous avez déjà C:\data\backuplog1.txt dans cet exemple, la sauvegarde générera une erreur (voir #3 dans l’Annexe A).

Note 2 : il existe l’option -verbint pour contrôler l’intervalle de rapport du nombre d’enregistrements traités pendant la sauvegarde ou la restauration.

3.2. Ajouter des statistiques de performance à la sortie verbeuse

Dans la sortie verbeuse de gbak pour la sauvegarde et pour la restauration, nous pouvons voir des messages comme ceux-ci :

Code

gbak:    writing data for table COUNTRY
gbak:16 records written

pour chaque table et autres objets de base de données.

Il est intéressant de déterminer quelles tables/objets prennent le plus de temps, n’est-ce pas ?

Pour cela, il est nécessaire d’utiliser l’option -st(atistics) :

Code

 -ST(ATISTICS) TDRW    show statistics:
     T                 time from start
     D                 delta time
     R                 page reads
     W                 page writes

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -st tdrw c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Une fois appliquée, elle ajoutera au journal les colonnes suivantes :

Code

gbak: time   delta  reads  writes

afin que nous puissions voir le temps et les E/S consacrés à chaque ligne.

3.3. Exclure des tables de la sauvegarde et/ou de la restauration

Si vous pensez que certaines tables peuvent être exclues de la sauvegarde (un bon exemple est une table de journal très longue), vous pouvez les spécifier dans le paramètre SK[IP_DATA], avec une expression régulière comme paramètre.

Dans l’exemple ci-dessous, nous excluons les données des tables COUNTRY et JOB de la sauvegarde :

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -SKIP_D ‘(COUNTRY|JOB)’ c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Et, dans l’exemple ci-dessous, nous excluons la table CLIENT de la restauration :

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new33.fdb -user SYSDBA -pass masterkey -SKIP_D "CLIENT"

Veuillez noter que le paramètre de SKIP_DATA doit être transmis comme un paramètre unique, il doit donc être entre guillemets !

Sous Linux, les guillemets doivent être simples, sous Windows - doubles.

Précautions concernant l’exclusion de tables de la sauvegarde et/ou de la restauration

Nous recommandons fortement de vérifier la condition d’expression régulière avant de l’utiliser, avec la requête suivante - elle retournera une liste des tables qui correspondent à la condition du filtre (dans la requête, les guillemets sont toujours simples)

Code

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME) SIMILAR TO '(COUNTRY|JOB)';

RDB$RELATION_NAME
===============================
COUNTRY
JOB

Veuillez noter que les tables de la sauvegarde ou de la restauration seront exclues indépendamment des contraintes existantes (clés étrangères). Ainsi, si vous n’avez pas planifié soigneusement cette exclusion, il est très facile d’obtenir l’erreur « Cannot commit foreign key index » pendant le processus de restauration.

3.4. Récupérer le mot de passe pour la sauvegarde ou la restauration depuis un fichier

Si vous n’êtes pas un grand fan de l’idée d’exposer le mot de passe à tous ceux qui voient vos commandes, vous apprécierez l’option suivante : -fetch passwordfile

Créons le fichier contenant le mot de passe dans C:\Data\passfile.txt et utilisons-le (nous utilisons ici une variante embarquée très simple ; bien sûr, l’option fonctionnera aussi avec le Service Manager) :

Code

gbak -b c:\Data\test1.fdb c:\Data\backup5.fbk -user SYSDBA -fetch C:\Data\passfile.txt

Il y a 2 avantages pratiques :

Si nous stockons le mot de passe dans un fichier unique, nous pouvons garantir que tous nos fichiers de commandes utiliseront toujours le mot de passe actuel.
Nous n’exposons pas le mot de passe dans chaque fichier de commandes.

4. Sauvegarde-restauration en une seule étape

Souvent, l’objectif de la sauvegarde est d’effectuer une restauration immédiate, afin d’obtenir une nouvelle base de données fraîche, par exemple, pour appliquer une nouvelle taille de page pour la base de données, ou pour migrer la base de données existante de 2.5 vers 3.0.

Dans ce cas, il est possible d’effectuer la sauvegarde-restauration avec une seule commande, en utilisant l’entrée standard et la sortie standard comme sources pour les commandes appropriées, afin d’éviter la création du fichier de sauvegarde intermédiaire, de réduire les besoins en espace libre et d’accélérer le processus.

La commande est la suivante :

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout | gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

En substance, nous exécutons ici 2 commandes, unies par le symbole |,

la première pour la sauvegarde vers stdout :

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout

et la seconde, pour la restauration depuis stdin :

Code

gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

Cette commande est le moyen le plus rapide d’effectuer une sauvegarde-restauration sur la même instance Firebird.

Veuillez noter : pour convertir des bases de données de 2.5 vers 3.0 avec la sauvegarde-restauration en une seule étape, il est nécessaire d’utiliser 2 instances de Firebird, voir les détails ici.

5. Résumé des performances

La figure suivante contient des informations sur la vitesse des différentes commandes de sauvegarde locale de la base de données de test :

Comme vous pouvez le voir, le moyen le plus rapide d’effectuer une sauvegarde locale est d’utiliser le Service Manager (option -se[rvice]) et d’inhiber le ramasse-miettes (option -ig).

Pour la sauvegarde depuis un serveur distant vers la machine locale, le Service Manager est également la meilleure option :

La situation concernant les performances de restauration est similaire : le Service Manager est le moyen le plus rapide de restaurer.

Quant au cas assez rare où la restauration est effectuée depuis une sauvegarde locale vers un serveur distant, l’utilisation du Service Manager avec l’astuce stdin est le seul choix viable :

Question très fréquemment posée sur les machines virtuelles et les sauvegardes Firebird

Pourquoi devrais-je utiliser les outils de sauvegarde Firebird, alors qu’il existe des outils de sauvegarde populaires qui promettent de tout sauvegarder ?

Ou bien, je sauvegarde l’image complète de la machine virtuelle, pourquoi devrais-je me soucier de la sauvegarde de la base de données Firebird ?

La réponse est ici.

Annexe A. Erreurs pendant la sauvegarde/restauration

Une tentative d’exécuter gbak sans paramètres, ou avec un utilisateur non propriétaire de la base de données/non-SYSDBA, conduira à l’erreur suivante :

Code

gbak: ERROR:Unable to perform operation.  You must be either SYSDBA or owner of the database
gbak:Exiting before completion due to errors

Si vous spécifiez un mauvais mot de passe, l’erreur suivante apparaîtra :

Code

gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
gbak:Exiting before completion due to errors

Une erreur se produit lorsque le fichier existant est spécifié comme destination du journal détaillé

Code

gbak: ERROR:cannot open status and error output file C:\data\backuplog1.txt
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Une erreur se produit si la base de données existante est spécifiée dans la commande de restauration gbak comme destination

Code

gbak: ERROR:database C:\data\new1.fdb already exists.  To replace it, use the -REP switch
gbak:Exiting before completion due to errors

Une erreur se produit lorsque gbak tente d’écrire une sauvegarde à un emplacement où il ne dispose pas des droits d’écriture suffisants.

Code

gbak: ERROR:cannot open file  /db/test1.fbk
gbak:Exiting before completion due to errors

Lorsque gbak tente d’accéder au fichier sans autorisation - par exemple, le fichier a un autre propriétaire que l’utilisateur « firebird » sous Linux

Code

gbak: ERROR:no permission for read-write access to database /db/test1.fdb
gbak: ERROR:    IProvider::attachDatabase failed when loading mapping cache
gbak:Exiting before completion due to errors

Tentative d’utiliser la sortie détaillée

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -user SYSDBA -pass masterkey /db/test1.fdb stdout  >
 c:\data\rembackup2.fbk
gbak: ERROR:standard output is not supported when using split operation or in verbose mode
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Tentative de sauvegarde avec le Service Manager sur le serveur distant avec le mode détaillé activé et l’enregistrement dans le fichier journal.

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -y lg1.txt  -user SYSDBA -pass masterkey /db/test1.f
db stdout  > c:\data\rembackup2.fbk
gbak: ERROR:Invalid clumplet buffer structure: string length doesn't match with clumplet
gbak:Exiting before completion due to errors

Erreur dans la sauvegarde-restauration en une seule étape lorsque la sauvegarde échoue pour une raison quelconque :

Code

gbak: ERROR:No request from user for stdin data
gbak:Exiting before completion due to errors

Si vous essayez de passer un fichier non-sauvegarde à gbak

Code

gbak: ERROR:unavailable database
gbak:Exiting before completion due to errors
gbak: ERROR:expected backup description record
gbak:Exiting before completion due to errors

La sauvegarde d’un fichier de base de données corrompu avec une mauvaise page signalera l’erreur suivante (le numéro et le fichier de base de données différeront, bien sûr)

Code

gbak: ERROR:database file appears corrupt (E:\DATABASE1.FDB)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 9294588 is of wrong type (expected 8, found 0)
gbak: ERROR:gds_$get_segment failed
gbak:Exiting before completion due to errors
gbak: ERROR:Unexpected I/O error while reading from backup file
gbak:Exiting before completion due to errors

Contacts

N’hésitez pas à nous contacter pour toute question, ou à signaler toute erreur ou faute de frappe : [email protected]