FirebirdSQL logo

Changing The Page Size

Similar to the example above to change the default database cache size, the database page size can also be changed using gbak.

tux> # Check current page size (as root user!)
tux> gstat -h employee | grep -i "page size"
        Page size               4096

tux> # Restore the database & change the page size.
tux> gfix -shut -tran 60 employee
tux> gbak -r o -page_size 8192 /backups/employee.fbk employee

tux> # Check the new page size (as root user!)
tux> gstat -h employee | grep -i "page size"
        Page size               8192

Creating A Read-Only Database Clone

Sometimes you do not want your reporting staff running intensive queries against your production database.To this end, you can quite easily create a clone of your production database on a daily basis, and make it read-only.This allows the reporting team to run as many intensive reports as they wish with no ill effects on the production database, and it prevents them from inadvertently making changes.

The following example shows the production employee database running on Linux server tux, being cloned to the reporting team’s Linux server named tuxrep.First on the production tux server:

tux> # Backup the production database.
tux> gbak -backup employee /backups/employee.fbk

Then on the reporting team’s tuxrep server:

tuxrep> # Scp the backup file from tux.
tuxrep> scp fbuser@tux:/backups/employee.fbk ./
Using keyboard-interactive authentication.
Password:
employee.fbk              |         19 kB |  19.3 kB/s | ETA: 00:00:00 | 100%

tuxrep> # Restore the employee database as read-only.
tuxrep> gfix -shut -tran 60 employee
tuxrep> gbak -r o -mode read_only employee.fbk employee

tuxrep> # Check database mode (as root user)
tuxrep> gstat -h employee|grep -i attributes
        Attributes              no reserve, read only

Creating a Database Clone Without a Backup File.

You may use gbak to create a clone of a database, on the same server, without needing to create a potentially large backup file.To do this, you pipe the output of a gbak backup directly to the input of a gbak restore, as follows.

tux> # Clone a test database to the same server, without requiring a backup file.
tux> gbak -backup emptest stdout | gbak -r o stdin emptest_2

You will notice that the output filename for the backup is stdout and the input filename for the restore is stdin.This ability to pipe standard output of one process to the standard input of another, is how you can avoid creating an intermediate backup file.The commands above assume that there are suitable alias names set up for both emptest and emptest_2.If not, you will need to supply the full path to the two databases rather than the alias.

The -⁠r o option on the restore process will overwrite the database name specified — as an alias or as a full path — if it exists and will create it anew if it doesn’t.

If you don’t want to overwrite any existing databases, use [gbak-cmdline-create-database] which will only create a database if it doesn’t already exist, and will exit with an error if it does.In POSIX compatible systems, the error code in $? is 1 in this case.

Further examples of backing up and restoring remote databases over ssh, using the stdin and stdout filenames, can be seen below.

Gbak Caveats

The following is a brief list of gotchas and funnies that I have detected in my own use of gbak.Some of these are mentioned above, others may not be.By collecting them all here in one place, you should be able to find out what’s happening if you have problems.