FirebirdSQL logo

Direct I/O (Firebird 2.1.4+)

Originally, nbackup used direct I/O only when making a backup under Windows NT (and successors like 2000, 2003 etc).On all other OS’es, direct I/O was off.This caused problems on some Linux systems, so in versions 2.0.6 and 2.1.3 direct I/O was switched on under Linux as well.However, this turned out to be problematic for certain other Linux configurations.In 2.1.4 and 2.5 the original behaviour was restored, but this time as a default that was overridable by a newly added parameter: -D.Its use is as follows:

nbackup -B 0 cups.fdb cups.nbk -D on    -- direct I/O on
nbackup -B 0 mugs.fdb mugs.nbk -D off   -- direct I/O off

Just like the option letters themselves, the arguments ON and OFF are case-insensitive.

Direct I/O is only applied when making a backup, not during a restore.Under Windows it is realized by setting FILE_FLAG_NO_BUFFERING.On other systems, O_DIRECT and POSIX_FADV_NOREUSE are used.The latter two are sometimes unavailable;in such cases, they are (or one of them is) silently left out.Even if the user specified -D on explicitly, this doesn’t lead to a warning or error message.

Informational options (Firebird 2.5+)

Apart from the already mentioned -FE and -D parameters, Firebird 2.5 also saw the introduction of the following two:

-Z

Shows single-line version information.This option can be used independently, but also in combination with other parameters, such as -B, -R, -L etc.

-?

Shows a summary of nbackup’s usage and command-line parameters.Attention: If this option is present, all the other parameters are ignored!

Backups on remote machines (Firebird 2.5+)

Nbackup itself only operates on local databases.But in Firebird 2.5 and up, nbackup-type backups and restores can also be performed remotely via the Services Manager.For this, the program fbsvcmgr.exe on the local machine is used;it is located in the same folder as nbackup.exe and the other Firebird command-line tools.The first argument is always “hostname:service_mgr”, with hostname being the name of the remote server.Other available parameters are:

-user username
-password password
-action_nbak
-action_nrest
-nbk_level n
-dbname database
-nbk_file filename
-nbk_no_triggers
-nbk_direct on|off

Making a full backup on the remote machine frodo goes like this:

fbsvcmgr frodo:service_mgr -user sysdba -password masterke
  -action_nbak -nbk_level 0
  -dbname C:\databases\countries.fdb -nbk_file C:\databases\countries.nbk

And a subsequent incremental backup:

fbsvcmgr frodo:service_mgr -user sysdba -password masterke
  -action_nbak -nbk_level 1
  -dbname C:\databases\countries.fdb -nbk_file C:\databases\countries_1.nbk

To restore the whole shebang:

fbsvcmgr frodo:service_mgr -user sysdba -password masterke
  -action_nrest -dbname C:\databases\countries_restored.fdb
  -nbk_file C:\databases\countries.nbk -nbk_file C:\databases\countries_1.nbk
Note

Each of the above commands should be typed as a single sentence, without line breaks.The hyphens before the parameter names may be omitted, but especially with long commands like these it may be helpful to leave them in, so you can easily identify the individual parameters (the arguments don’t get a hyphen).

Comments:

  • The Services Manager always requires authentication, be it automatic (root under Posix, trusted under Windows) or explicit through the parameters -user and -password.The environment variables ISC_USER and ISC_PASSWORD are not used.AUTO ADMIN MAPPING in the database has no effect when connecting remotely (though this may also depend on the configuration of the network).

    Note: When Windows trusted authentication is in effect, the account name of the user on the local machine is passed to the Services Manager on the remote machine.If the owner of the remote database is a Windows account (e.g. FRODO\PAUL) rather than a Firebird account, and the Windows account name on the local machine is the same as the owner account name on the remote machine, the caller is acknowledged as the database owner and allowed to make a backup.This could pose a security risk, because even on local networks user PAUL on one machine is not necessarily the same person as user PAUL on another machine.

  • Restoring (-action_nrest) also requires authentication, but once verified the credentials are not used in any way.Hence, the user need not be the database owner, SYSDBA or superuser.In the case of Windows trusted authentication, the user need not exist at all on the remote machine (where the database is located).

    This weak authentication implies another potential security risk.Suppose a sensitive database is nbackupped, and the backups are well protected on the filesystem level.An average user can’t restore the database with nbackup then, because nbackup runs in the user process space.But that same user, if he knows name and location of the backup, or can guess them by analogy, might be able to get hold of the database by having fbsvcmgr restore it to a public folder.After all, fbsvcmgr calls the Firebird server, which may have file-level access to the backup.Of course there are solutions to this, but it’s important to be aware of the risk.

  • The Services Manager can also be used locally;in that case the first argument becomes service_mgr, without hostname.When used locally, AUTO ADMIN MAPPING has the intended effect;this is still true if you prepend localhost: or the name of the local machine.Local use of the Services Manager can be beneficial if you don’t have filesystem access to the database and/or backup files, but the Firebird server process does.If you do have sufficient rights, then it’s more practical to use nbackup itself, with its much shorter commands.

  • Specifying -nbk_no_triggers or -nbk_direct with -action_nrest leads to an error message.Nbackup itself is more lenient here: it simply ignores the -T and -D parameters if they are used in the wrong context.

  • Instead of a database filename you may also use an alias.

  • Database path (or alias) length is limited to 255 characters.

A practical application

An nbackup-based incremental backup scheme could look like this:

  • Each month a full backup (level 0) is made;

  • Each week a level-1;

  • A level-2 backup daily;

  • A level-3 backup hourly.

As long as all backups are preserved, you can restore the database to its state at any hour in the past.For each restore action, a maximum of four backup files is used.Of course, you schedule things in such a way that the bigger, time-consuming backups are made during off-peak hours.In this case the levels 0 and 1 could be made at weekends, and level 2 at night.

If you don’t want to keep everything for eternity, you can add a deletion schedule:

  • Level-3 backups are deleted after 8 days;

  • Level-2s after a month;

  • Level-1s after six months;

  • Full backups after two years, but the first one of each year is kept.

This is only an example of course.What’s useful in an individual case depends on the application, the size of the database, its activity, etc.