Library

Firebird Gbak Tips And Tricks

What is gbak?
1. Mastering Backups with Gbak
1.0 Preparation
1.1 The simplest Firebird backup with gbak command
1.2. Local backup with gbak which can be done online on Windows
1.3. Backup with gbak with TCP/IP connection string
1.4. Faster backup with gbak with Service Manager
1.5. The fastest backup with gbak with Service Manager and inhibited garbage collection
1.6. Backup to the network share or network location
1.7. Simple backup from the remote server to local machine
1.8. Faster backup from a remote server to local machine with Service Manager
1.9. Backup Firebird database on the remote server to the same remote server using Service Manager
1.10. Backup Firebird database 6x faster with Firebird 5 (or HQbird in 2.5/3.0/4.0)
2. Restore with Gbak tool
2.1. The simplest restore command
2.2. Restore with localhost connection string
2.3. Restore with XNET on Windows
2.4. Faster restore with Service Manager
2.5. Non-recommended switch
2.6. Restore database using alias
2.7. Restore local backup to the remote server
2.8. Restore the local backup to the remote server with Service Manager
2.9. Restore extremely long tables
3. Tweaking and logging backup and restore processes
3.1. Gbak with verbose output
3.2. Add performance statistics to verbose output
3.3. Exclude tables from the backup and/or from the restore
3.4. Fetch password for backup or restore from the file
4. One-step backup-restore
5. Performance summary
Very Frequently Asked Question About VM and Firebird Backups
Appendix A. Errors during backup/restore
Contacts

What is gbak?

Gbak is a standard Firebird command-line tool (see its official documentation here), designed to perform 1) full backup of the database: it reads every record in the database and stores them to the backup file, 2) restore backup to the new database.
For developers and administrators with experience with other RDBMS, the term “backup” could be a bit confusing, since gbak produces not the exact copy of the database, but the file in the non-database format, only with data (indices are stored as declarations).
To create a database from the gbak backup file, the restore process with gbak should be performed.

1. Mastering Backups with Gbak

1.0. Preparation

Let’s create folder C:\data and put there some database. We will use 5Gb database from Firebird OLTP-EMUL test, but you can use your own database, of course.

For Linux users – let’s create folder /db and change its owner to "firebird", and copy the database there (make sure its owner is also firebird).

mkdir /db
chown firebird -R /db

1.1 The simplest Firebird backup with gbak command

Windows

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

Linux

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

In this example, gbak tool accesses database file using local or embedded access.

Firebird 3.0: Embedded access in the default configuration for Firebird 3.0 (with parameter in firebird.conf ServerMode = SuperServer) will try to put an exclusive lock on the database, so other connections will be unable to access the database (or gbak attempt will fail due to the active connections).

Firebird 2.5: With Firebird 2.5 on Windows the command will work fine through XNET protocol (if you have the only Firebird instance running, of course). On Linux, Firebird will try to use embedded access, if it is not accessible, it will automatically (and implicitly) try to connect through TCP/IP. (If you don't know what is the meaning of XNET, INET, etc, please read Connection Protocols in Firebird 3)

Note 1: This command runs under the OS user's (i.e., yours) account, and uses its permissions to access backup and database files.
Normally, Firebird service on Windows runs with LocalSystem account, and on Linux under user “firebird”, but the console is usually run under your own user account.
If this user account does not have access to the database path or backup path, the gbak will fail with the error “Cannot open backup file” (see example in Appendix A. Errors, #5).

Note 2: gbak -b silently overwrites the backup file. So, if you already have backup1.fbk, it will be overwritten.

Note 3: On Linux, this gbak command will create a backup file with the owner equal to the console user.

Time to backup for this command: 120 seconds

1.2. Local backup with gbak which can be done online on Windows

This section is for Windows users only! Usually, we need to perform backup while we have active connections to the database, so instead of embedded connection, it is better to explicitly specify the local protocol to avoid putting exclusive lock on the database file by gbak itself in Firebird 3, i.e. XNET.
For Firebird 3.0:

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

For Firebird 2.5, we can use a local connection string, and it will use XNET too:

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

On Linux, Firebird doesn't support a specific local protocol like XNET on Windows, so it is necessary to use TCP/IP connection string (see section 1.3).
Also, XNET works only for the single instance of Firebird, so if you run several instances of Firebird on Windows, it could be easier to use INET style connection string to specify the target server instance

Time to backup: 139 seconds

1.3. Backup with gbak with TCP/IP connection string

This is the most universal gbak command, to perform backup online.
Windows

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

Linux

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

In this case, by specifying localhost: at the beginning of the database path, the connection is done through the network subsystem of Firebird.
It is slightly slower than local access but works in all cases when we have a running server that accepts connections.

Non-standard port for Firebird

If you have Firebird running on a non-standard port (e.g., 3051 instead of 3050), you can do backup in this way:
Windows

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

Linux

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

Time to backup: 182 seconds

1.4. Faster backup with gbak with Service Manager

How can we achieve the universality of TCP/IP connection, with support of non-standard port, and fast local backup? Let’s use Service Manager! Service Manager, in simple words, is the way to run standard tools through the Firebird engine. Please note, that in the case of Service Manager, there is no need to specify the server name in the path to the database, only in the -se parameter.
Windows

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

Linux

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

This command uses switch -service to specify that we want to use Service Manager of Firebird instance on port 3050 to perform the backup.

In this case, the backup will be performed directly inside the Firebird process (it has a copy of gbak code), and since the in-process communication is much faster, the backup will be significantly faster in this case.
If Firebird is running on the non-standard (e.g., 3051), the command can look like:

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

Note: There is a significant limitation in Firebird 2.5 and Firebird 3.0.0-3.0.5 (removed only in 3.0.6): the command line (all parameters and paths for the database and for the backup) must be less than 256 symbols.

If you hit this limit, for example, due to long paths of database and backup, you can declare an alias for the database in databases.conf (3.0 and higher) or aliases.conf (2.5):

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

mydb1=/db/test1.fdb  #linux

and then use it in our command:
Windows

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

Linux

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

Time to backup: 115 seconds

1.5. The fastest backup with gbak with inhibited garbage collection

To make backup even faster, let’s add switch -g

 -G(ARBAGE_COLLECT)    inhibit garbage collection

So, the backup command will be the following
Windows

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

Linux

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

Switch -g forces Firebird engine to disable garbage collection for the backup process in the database file.
It does not mean that garbage record versions will be stored in the backup file, it means that the server will not try to clean existing garbage in the database during backup, and backup will be faster.

We strongly recommend using this switch, because we believe that garbage collection and associated cleaning should be done by sweep (gfix -sweep or autosweep), so better do not consider gbak as any kind of alternative of the sweep.

Time to backup: 105 seconds

1.6. Backup to the network share or network location

What if we need to put backup file to the network share?

On Windows
The often confusion of new Firebird users: manual backup (when you start command from a command prompt), with simple gbak -b, to the network share works fine, but the fast version of gbak with -se localhost:service_mgr, does not work.
The reason is that Firebird on Windows runs under LocalSystem account, which does not have access to the network locations (unless these network shares have configured access for the group “Everyone”, but this is very very dangerous in our era of ransomware).
The solution is to run Firebird service on Windows under the account with enough rights to access the network share, and, simultaneously, enough rights to access local database files and system files in C:\ProgramData\Firebird. Also, a good idea is to configure parameter RestrictAccess in firebird.conf.
On Linux
Since Firebird on Linux runs under account "firebird", mount network share with mapping to user “firebird”, so Firebird service will be able to access the network location in the same way as a local drive.

1.7. Simple backup from the remote server to local machine

It is possible to back up the database from the remote server to the local machine.
The example command below starts on a Windows computer, accesses the database on Linux server (with IP address 192.168.0.108, but also server's hostname can be used, of course), and the backup file is stored to the folder C:\Data on Windows):

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

Time to backup: 568 seconds

This command usually will be much slower than the local backup, because gbak reads data from the remote server and transfers records through the network.

1.8. Faster backup from remote server to local with Service Manager

The command below is faster than traditional backup from the remote server to local machine, described in #1.7

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

It uses Service Manager to do the backup on the remote server, but the output is being sent to the stdout pipe, and then redirected to the local file.
This command is usually 15%-20% faster than in #1.7 (Simple backup from the remote server to local), due to the following:

it performs backup through Service Manager on the remote server, so all reading and compressing operations are performed in the fastest way,
it transfers through the network only the resulted backup file, with the size less than the data in the database

However, with this command, it is not possible to enable verbose mode and store detailed output to the log file.

Time to backup: 473 seconds

1.9. Backup Firebird database on the remote server to the same remote server using Service Manager

With Service Manager, it is possible to invoke gbak backup of the database on the remote server and store it on the same remote server too.

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

This command through Service Manager invokes backup on the remote server, with the instruction to store the backup file at the same network server too.
Of course, the backup location should be accessible by Firebird service (on Linux it runs as user “firebird”, on Windows as LocalSystem account).

1.10. Backup Firebird database 6x faster with multi-thread backup in Firebird 5 (or HQbird 2.5/3.0/4.0)

If you are still not happy with the backup performance of Firebird gbak, consider migrating to Firebird 5 (or use enterprise Firebird distribution: HQbird for other versions).
It supports multi-thread backup, which enables up to 6x faster backup operations with gbak.

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

As you can see, there is a new parameter -par 8, which makes gbak to use 8 threads to create a backup.
HQbird (version Enterprise only) performs maintenance tasks (sweep, backup, restore) much faster (results on the figure below are from the different database, of course):

2. Restore with Gbak tool

We have backup file backup1.fbk, created by one of the commands above, and we need to restore it, in a fast and efficient way.

Let’s assume the file is in C:\Data\backup1.fbk in case of Windows, or /db/backup1.fbk in case of Linux.

2.1. The simplest restore command

On Windows

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

On Linux

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

First of all, please note that gbak -c does not overwrite the database file, and if there exists file C:\data\new1.fdb or /db/new1.fdb, gbak will return an error saying that the database already exists.

Then, this command is actually working very differently on 2.5/3.0+ and Windows/Linux.

On Linux, this command will use embedded access to the created database (if you did not change in firebird.conf the order of Firebird providers, of course) both for 3.0 and 2.5.

On Windows, on Firebird 3.0 with default order of providers, it will be embedded access, on 2.5 – XNET.

Then, this command creates a file with the rights of the user who started gbak, it is especially important on Linux – if you run such gbak under root, the owner of the database file will be root, and Firebird process, which runs under user “firebird”, will be unable to access the restored file.

Note for Linux users
Many people, in order to “fix” the ownership, apply permission for everybody to access the restored database, i.e., something like “chmod 777 database”, but this is very insecure, the proper way is to change the owner of the database to firebird, with the following command

chown firebird /db/new1.fdb

In general, this command is good enough for the simple restore of non-production databases (used for testing or in development).

Time to restore: 275 seconds

2.2. Restore with localhost connection string

The most universal, but not the fastest restore option is the following:
Windows

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

Linux

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

Non-standard port

If Firebird is running on the non-standard port, for example, 3051, it can be specified in restore command:
Windows

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

Linux

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

Time to restore: 1225 seconds

2.3. Restore with XNET on Windows

To make restore a bit faster, on Windows we can use XNET (for Firebird 3.0 and higher):

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

On Firebird 2.5 on Windows, XNET access will be used with the simple command line (if there is only one Firebird instance is running):

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

Time to restore: 585 seconds

2.4. Faster restore with Service Manager

And the fastest way to restore is to use Service Manager
Windows

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

Linux

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

With switch -se, we invoke Service Manager on the localhost address and instruct it to perform restore code inside the Firebird engine.

When restore is done by Service Manager, the created database file will be owned by the account of running Firebird instance (process) – it is "firebird" on Linux, and LocalSystem on Windows.

Time to restore: 244 seconds

2.5. Non-recommended switch

At some moment you could have the temptation to use the following switch:

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

in order to force replacing of the existing database with the new one.

In our experience, this switch greatly increases the chances to accidentally overwrite the production database.

We strongly recommend restoring the database every time with the new name and rename it, as well as delete the old database, explicitly.

We even will not provide the example of the command with this switch.

2.6. Restore database using alias

It is possible to restore the database using the alias, declared in databases.conf (or aliases.conf in Firebird 2.5)

For example, we have the following declaration

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

restdb=/db/newrest1.fdb  #Linux

So we can run the following command to restore the backup to the path, specified by the alias
Windows

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

Linux

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

2.7. Restore local backup to the remote server

It is possible to restore the local backup file to the remote Firebird server.

In this example, we restore the backup file stored on Windows, to the Linux server (its IP address 102.168.0.108):

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

Time to restore: 7009 seconds

As you may notice, the remote restore process works very slow, can we speed it up with Service Manager?

2.8. Restore the local backup to the remote server with Service Manager

To restore the local backup on the remote server with Service Manager, it is necessary to do the trick with the stdin input stream:

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

This command invokes restore on the remote server with the standard input stdin as the source of backup – and supplies the input using the < C:\Data\backup1.fbk portion of the command.

Looks a bit tricky? But it is an easy way to 10x increase of the gbak performance to restore to the remote server!
Time to restore: 450 seconds

2.9. Restore extremely long tables

If you have a really big database with the total numbers of rows more than 2 billions, it is necessary to specify switch -o[ne_at_a_time], to restore each table in the separate transaction, to avoid some internal overflow.

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

3. Tweaking and logging backup and restore processes

3.1. Gbak with verbose output

By default, gbak is a very silent tool, it returns nothing in case of successful execution. To make it verbose, we can add the switch -v[erify]

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

As a result, there will be more details. The minor, but annoying problem that printing output to the console can make verbose backup significantly slower than the silent variant, so the good idea will be to save the log to the file with switch -y logfile:

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 will not overwrite the existing log file! If you already have C:\data\backuplog1.txt in this example, the backup will raise the error (see #3 in Appendix A).
Note 2: there is option -verbint to control the interval to report the number of processed records during backup or restore.

3.2. Add performance statistics to verbose output

In the gbak verbose output for backup and for restore, we can see messages like these:

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

for every table and other database objects.
It is interesting to figure out which tables/objects take the most of the time, right?

For this, it is necessary to use switch -st(atistics):

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

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

When applied, it will add to the log the following columns:

gbak: time   delta  reads  writes

so we will be able to see time and IO spent on each line.

3.3. Exclude tables from the backup and/or from the restore

If you think that some tables can be excluded from the backup (a good example is a very long log table), you can specify them in the parameter SK[IP_DATA], with regular expression as a parameter.

In the example below, we exclude data from tables COUNTRY and JOB from backup:

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

And, in the example below, we exclude table CLIENT from the restore:

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

Please note that parameter to SKIP_DATA must be transmitted as the single parameter, so it must be in quotes!
On Linux, quotes should be single, on Windows – double.

Precautions on excluding tables from backup and/or restore

We strongly recommend to check the regular expression condition before using it, with the following query – it will return a list of tables which correspond to the filter condition (in the query quotes are always single)

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

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

Please note, that tables from the backup or restore will be excluded regardless of the existing constraints (Foreign Keys), so, if you did not plan such exclusion carefully, it is very easy to receive the error “Cannot commit foreign key index” during the restore process.

3.4. Fetch password for backup or restore from the file

If you are not the big fan of the idea to expose the password to everyone who sees your commands, you will like the following switch: -fetch passwordfile

Let’s create the file with the password in C:\Data\passfile.txt and use it (here we use a very simple embedded variant, of course, the switch will work with Service Manager too):

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

There are 2 practical benefits:

If we store a password in the single file, we can ensure that all our command files will always use the actual password.
We don’t expose the password in the every command file

4. One-step backup-restore

Often the goal of the backup is to perform the immediate restore, in order to get the new fresh database, for example, to apply the new page size for the database, or to migrate the existing database from 2.5 to 3.0.

In this case, it is possible to perform backup-restore with the single command, using standard input and output as sources for the appropriate commands, to bypass creating of the intermediate backup file, reduce requirements for the free space, and speed up the process.
The command is the following:

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

In essence, here we do 2 commands, united by symbol |,
the first for backup to stdout:

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

and the second, for restore from stdin

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

This command is the fastest way to do backup-restore on the same Firebird instance.

Please note: for converting databases with one-step backup-restore from 2.5 to 3.0 it is necessary to use 2 instances of Firebird, see details here.

5. Performance summary

The following figure contains information about the speed of different backup commands of local backup of the test database:

As you can see, the fastest way to do local backup is to use Service Manager (switch -se[rvice]) and inhibit garbage collection (switch -ig).

For the backup from the remote server to the local machine, Service Manager also is the best option:

The situation with restore performance is similar: Service Manager is the fastest way to restore.

As for the pretty rare case, when restore is done from the local backup to the remote server, using Service Manager with stdin trick is the only viable choice:

Very Frequently Asked Question About VM and Firebird Backups

Why should I use Firebird backup tools, when there are popular backup tools available which promise to backup everything?

Or, I do backup the complete image of Virtual Machine, why should I bother about backup of Firebird database?

The answer is here.

Appendix A. Errors during backup/restore

1) An attempt to run gbak without parameters, or with the non-owner user of the database/non-SYSDBA will lead to the following error:

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

2) If you specify the wrong password, there will be the following error:

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

3) Error occurs when the existing file is specified as a verbose log destination

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

4) Error occurs if the existing database is specified in the gbak restore command as a destination

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

5) Error occurs when gbak tries to write a backup to the location where it does not have sufficient rights to write.

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

6) When gbak tries to access the file without permission to do it – for example, the file has another owner than user “firebird” on Linux

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

7) Attempt to use verbose output

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

8) Attempt to do backup with Service Manager on the remote server with enabled verbose and storing to the log file.

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

9) Error in one-step backup-restore when backup fails for some reason:

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

10) If you are trying to pass non-backup to the gbak

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

11) Backup of a corrupted database file with the wrong page will report the following error (number and database file will differ, of course)

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

Please feel free to contact us with any questions, or report any errors or typos: [email protected]