FirebirdSQL logo
  • Anglaiskeyboard_arrow_down

Restoring incremental backups

When restoring incremental backups, you must specify the entire chain of backup files, from level 0 through the one you wish to restore.The database is always built up from the ground, step by step.(It is this stepwise adding until the database is restored that gave rise to the term incremental backup.)

The formal syntax is:

nbackup -R database [backup0 [backup1 [...] ] ]

So, restoring the level-2 backup from the previous example goes as follows:

C:\Data> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk
           inventory_3-Mar-2006.nbk inventory_3-Mar-2006_2.nbk

Of course the line has been split here for layout reasons only — in reality you type the entire command and only hit kbd:[Enter] at the end.

Comments (in addition to the comments with restoring a full backup)

  • Because it is not known beforehand how many filenames will follow the -RESTORE switch (as we don’t specify a level when restoring), nbackup considers all arguments after the -RESTORE to be names of backup files.It is for this reason that no other parameter may follow the list of filenames.

  • There is no formal limit to the number of backup levels, but in practice it will rarely make sense to go beyond 3 or 4.

Non-connecting links

What happens if you accidentally leave out a file, or specify a series of files that don’t all belong together?You could imagine that you specify inventory_2-Mar-2006.nbk by mistake instead of inventory_3-Mar-2006.nbk in the above example.Both are level-1 backup files, so in both cases we get a nice “0, 1, 2” level series.But our level-2 file is incremental to the level-1 backup of 3 March, not to the one of 2 March.

Fortunately such a mistake can never lead to an incorrectly restored database.Each backup file has its own unique ID.Furthermore, each backup file of level 1 or above contains the ID of the backup on which it is based.When restoring, nbackup checks these IDs;if somewhere in the chain the links don’t connect, the operation is cancelled, and you get an error message.

docnext count = 17

Backing up raw-device databases

Firebird databases need not be files;they can also be placed on a so-called raw device, for instance a disk partition without a file system.The question of where the delta has to be placed in such cases was at first overlooked during the development of nbackup.On Posix systems, if the database was located at e.g. /dev/hdb5, it could happen that the delta was created as /dev/hdb5.delta.In light of the nature and purpose of the /dev directory and its often limited available space, this is undesirable.

As of Firebird 2.1, nbackup refuses to operate on raw-device databases unless an explicit location for the delta file has been set.The way to do this is discussed in [nbackup-deltafile], later on in this manual.

Suppressing database triggers (Firebird 2.1+)

Firebird 2.1 introduced the concept of database triggers.Certain types of these triggers can fire upon making or breaking a database connection.As part of the backup process, nbackup opens a regular connection to the database (in some versions even more than once).To prevent database triggers from firing inadvertently, the -T or — since Firebird 3.0 — -NODBTRIGGERS switch can be used.

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.

Read on?

At this point you know everything you need in order to make and restore full and/or incremental backups with nbackup.You only need to read any further if you want to use backup tools of your own choice for your Firebird databases (see [nbackup-lock-unlock]), or if you want to override the default name or location of the delta file (see [nbackup-deltafile]).

If you have no craving for any of that: good luck in your work with nbackup!

Locking and unlocking

If you prefer to use your own backup tools or just make a file copy, nbackup’s lock-unlock mode comes into view.“Locking” means here that the main database file is frozen temporarily, not that no changes can be made to the database.Just like in backup mode, mutations are directed to a temporary delta file;upon unlocking, the delta file is merged with the main file.

As a reminder: nbackup.exe is located in the bin subdirectory of your Firebird folder.Typical locations are e.g. C:\Program Files\Firebird\Firebird_3_0 or C:\Program Files\Firebird\Firebird_2_0\bin (Windows) or /opt/firebird/bin (Linux).There’s no GUI;you launch it from the command prompt or call it from within a batch file or application.

Locking the database and making the backup yourself

A typical session in which you make your own backup goes as follows:

  1. Lock the database with the -L (lock) switch:

    nbackup [-U user -P password] -L database

  2. Now copy/backup/zip the database file to your heart’s content, with your own choice of tools. A simple file copy is also possible.

  3. Unlock the database with -N (uNlock), or — since Firebird 3.0 — -UN:

    nbackup [-U user -P password] -N database

The last command will also cause any mutations — which have been written to the delta file — to be merged into the main file.

The backup you made contains the data as they were at the moment the database was locked, regardless how long the locked state has lasted, and regardless how long you may have waited before making the actual backup.

Comments:

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

  • The -U and -P parameters may be omitted if the envars ISC_USER and ISC_PASSWORD are set, if you are root on a Posix system, or if trusted authentication under Windows permits it.For a detailed description see the comments under Making full backups.

  • Starting with Firebird 2.5, instead of -P password you may also use -FE filename.

  • Both -L and -N (-UN) make a regular connection to the database, so in Firebird 2.1 and above it may be wise to add the -T (or -NODBTRIGGERS) parameter (see Suppressing database triggers).

  • If you’re locking a raw-device database with Firebird 2.1 or above, the -S option can be very helpful;see [nbackup-lock-unlock-rawdevices].

  • You can optionally add -Z to have version information printed on the first line of the output.

Warning

What goes for backup/restore also applies to the lock/unlock switches: do not use them on multi-file databases.Until things have changed, don’t let nbackup loose on multi-file databases at all!

Restoring a backup made after “nbackup -L”

A copy of a locked database is itself a locked database too, so you can’t just copy it back and start using it.Should your original database get lost or damaged and the self-made copy needs to be restored (or should you wish to install the copy on another machine), proceed like this:

  1. Copy/restore/unzip the backed-up database file yourself with the necessary tools.

  2. Now unlock the database, not with the -N (or -UN) switch, but with -F (fixup):

    nbackup -F database

    Here too, you can optionally use an alias instead of a filename, and add -Z for version info.Other options make no sense.

Why are there two unlock switches, -N/-UN and -F?

  • -N/-UN first sees that any changes made since the locking by -L are merged into the main database file.After that, the database goes back into normal read/write mode and the temporary file is deleted.

  • -F only changes the state flag of the user-restored database to “normal”.

So you use:

  • -N/-UN after having made a copy/backup yourself (to reverse the -L issued earlier);

  • -F after having restored such a backup yourself.

Note

The term fixup is used because it doesn’t attempt to reintegrate the delta-file, but only makes the minimum changes necessary to make the database file usable again.

Under the hood

Note

This section doesn’t contain any necessary knowledge, but provides some extra information which could deepen your understanding of the various switches.

nbackup [parameter] -L does the following:

  1. Connect to the database;

  2. Start a transaction;

  3. Call ALTER DATABASE BEGIN BACKUP (this statement has been discussed in the extra information on nbackup -B);

  4. Commit the transaction;

  5. Disconnect from the database.

nbackup [parameter] -N follows the same steps, but with “…​ END BACKUP” in step 3.

nbackup [parameter] -F works as follows:

  1. The restored database file is opened;

  2. Within the file, the state flag is changed from locked (nbak_state_stalled) to normal (nbak_state_normal);

  3. The file is closed again.

Note

nbackup -F operates purely on file level and can therefore also be performed without a Firebird server running.Any credentials supplied via the -U, -P or -FE parameters are ignored, just as with nbackup -R.

Locking raw-device databases

As discussed in [nbackup-backups-rawdevices], problems can arise if a delta has to be created for a database located on a raw device.Therefore, in Firebird 2.1 and up, nbackup refuses to operate on raw-device databases unless an explicit location for the delta file has been set previously.For the procedure, see [nbackup-deltafile], a little further down.

There’s also another problem if you lock and copy a raw device: you don’t know the actual size of the database!The raw device may be 10 GB, but the database might only take up 200 MB of that space.To prevent having to copy the entire device just to be on the safe side — possibly wasting huge amounts of time and space — Firebird 2.1 has introduced a new parameter for nbackup: -S.This parameter is only valid in combination with -L and when it is present, nbackup writes the database size in pages to stdout after locking the database.Because the size is given in pages, it has to be multiplied by the database page size in order to get the actual number of bytes to be copied.Or, if you use the dd copy utility, you could specify the page size as (i)bs and the output of nbackup -L -S as count.

Locking/Unlocking database in case of Virtual Machines Backup

Using Virtual Machines backup tools without preparing database for such type of backup can lead to the corrupted (i.e. useless) backup copy.

Firebird server intensively uses its own cache in RAM to speed up operations, and implements complex techniques to ensure database consistency at the every given moment.Virtual Machine backup tools are not aware about Firebird’s cache, and usually they do not consider database files as random-access files.

As a result, when the virtual machine backup is done, the database file inside it will have the state as after a hard reset of VM, and very often such copy is not consistent (i.e. corrupted).The chance of such problem is higher when many active users are changing the database, or if there is active sweep process.

Such inconsistent backups can occur in any virtualized environment, including public clouds.

In order to create good Firebird database backup with VM backup tool, it is necessary to lock database file with nbackup before the VM backup, and unlock after it.Usually VM backup tool allows executing custom pre- and post-backup scripts, where you can lock/unlock Firebird databases.

Setting the delta file

By default, the delta file lives in the same directory as the database itself.The file name is also the same, but with .delta appended.This is usually not a problem, but sometimes it is desirable or even necessary to change the location, e.g. when the database is stored on a raw device.Nbackup itself has no provision for setting the location;this must be done through SQL.

Make a connection to the database with any client that allows you to enter your own SQL statements and give the command:

alter database add difference file 'path-and-filename'

The custom delta file specification is persistent in the database;it is stored in the system table RDB$FILES.To revert to the default behaviour, issue the following statement:

alter database drop difference file

You can also specify a custom delta location while creating a new database:

create database 'path-and-dbname' difference file 'path-and-deltaname'
Note

  • If you specify a bare file name with [ADD] DIFFERENCE FILE, the delta will likely not be created in the same directory as the database, but in the current directory as seen from the server.On Windows this may be the system directory.The same logic applies to relative paths.

  • The entire directory path must already exist.Firebird doesn’t attempt to create any missing directories.

  • If you want to change your custom delta specification, you must first DROP the old one and then ADD the new one.

Backup history

The firebird database keeps a history of all nbackup activity in the system table RDB$BACKUP_HISTORY.This information is used by nbackup itself for internal housekeeping, but can also be used to find out when the last backup was done, on which level and what the filename is.

For example, to see the last 5` backups you can use:

SELECT RDB$BACKUP_ID, RDB$TIMESTAMP, RDB$BACKUP_LEVEL, RDB$GUID,
    RDB$SCN, RDB$FILE_NAME
FROM RDB$BACKUP_HISTORY
ORDER BY RDB$TIMESTAMP DESC
ROWS 5

The columns of RDB$BACKUP_HISTORY are:

Column Description

RDB$BACKUP_ID

Primary key

RDB$TIMESTAMP

Time and date of backup

RDB$BACKUP_LEVEL

Backup level

RDB$GUID

GUID of the backup (used to check dependencies between files)

RDB$SCN

Highest page marker in the backup

RDB$FILE_NAME

Filename of the backup

For an explanation of the field RDB$SCN see the section [nbackup-background].

The contents of the table RDB$BACKUP_HISTORY are not backed up and restored by gbak;see the section [nbackup-background] for details.

Technical background information

Nbackup performs a physical backup of the database pages by copying pages that have been modified since the last backup of the immediately preceding level.A level 0 backup copies all pages, while a level 1 copies only those pages that have been modified after the most recent level 0.To be able to find the modified pages, Firebird uses a marker that is called the SCN (short for page scan).This number is incremented at each backup state change.For each backup with nbackup there are three state changes:

  1. nbak_state_normal (no backup) to nbak_state_stalled (database writes to delta file)

  2. nbak_state_stalled to nbak_state_merge (merging delta file back into database)

  3. nbak_state_merge to nbak_state_normal (no backup)

Note

These three state changes occur even if the backup fails.

The SCN of the database before the start of the backup is recorded together with the backup.The very first backup gets SCN 0, the second 3, etc.This number is independent of the level of the backup.The SCN is used to mark the pages of a database.So for example:

SCN Explanation

0

Pages before any backup

1

Pages written/updated into the delta file during the backup

2

Pages written/updated during the merge of delta file into main backup

3

Pages written/updated after ending first backup+merge

When a level 1 backup is made, nbackup looks for the last level 0 backup and backs up all pages with an SCN higher than the SCN of that level 0 backup (and so on).

A backup and restore with gbak does not restore the content of the RDB$BACKUP_HISTORY table, and it resets the SCN of all pages back to 0.The reason for this is that gbak creates a logical backup instead of a physical backup.So a restore using gbak will rewrite the entire database (and can even change the page size).This renders previous backups with nbackup meaningless as a starting point for subsequent backups: you need to start with a fresh level 0.

Document history

The exact file history is recorded in the firebird-documentation git repository; see https://github.com/FirebirdSQL/firebird-documentation

Revision History

0.1

21 Oct 2005

PV

First edition.

1.0

1 Dec 2006

PV

  • Removed “beta” reference in edition info.Changed warning against specifying backup file names interactively with nbackup -R.Removed “(or will be)” from first sentence in Document History.

  • Changed C:\Databases to C:\Data in the examples, just to keep the lines from running out of the shaded screen areas in the PDF.

  • Added section Setting the delta file, and changed section Read on? accordingly.

1.1

5 May 2008

PV

  • Making and restoring backups: Added warning about heavy-load risks with nbackup 2.0.0–2.0.3.

  • Restoring a full backup: Corrected wrong statement that nbackup will overwrite an existing database if there are no active connections.Changed italic text about interactive restore failure to a Note and mentioned its fix in 2.0.1.

  • Incremental backups: Inserted warning that incremental backups are broken in 2.1.

  • Suppressing database triggers (Firebird 2.1+): New section.

  • Read on?: Fixed typo (you → your).

1.2

19 Sep 2011

PV

  • Document source formatting: Changed max. line length to 100, without open lines.

  • All sections and subsections now have an id.

  • Introduction: Edited first sentence.

  • Nbackup features — an overview: First sentence: groups → kinds.Edited last para before first subsection: mentioned that only SYSDBA, owner and sometimes OS admins can make a backup.

  • Nbackup features — an overview :: Limitations of nbackup: Edited previously last listitem to mention Services Manager.Added listitem about direct file access.Removed last para.

  • Functions and parameters: New section.

  • Making and restoring backups: Slightly altered last sentence of first para.Extended warning: added info on the role of direct I/O with large databases under Posix.

 

 

 

  • Making and restoring backups :: Full backups :: Making full backups: Corrected and extended listitem on -U and -P parameters.Added listitems on -FE parameter (new in 2.5), -T parameter (new in 2.1) and -D parameter (new in 2.5, backport to 2.1.4).In listitem starting with “The different parameters”, the parenthesized text now reads (-B, -U etc.), because many new parameters have been added.

  • Making and restoring backups :: A word on the inner workings: Small edit (image → impression).

  • Making and restoring backups :: Full backups :: Restoring a full backup: Removed parameters -U and -P from specification.Added listitem on aliases.Changed separate Note about interactive restore failure back to italic text inside the listitem itself.Added listitem about non-necessity of running server and ignoring credentials.

  • Making and restoring backups :: Incremental backups: Edited Warning: mentioned fix in 2.1.1.

  • Making and restoring backups :: Incremental backups :: Restoring incremental backups: Removed parameters -U and -P from formal syntax and 1st listitem.

  • Making and restoring backups :: Backing up raw-device databases: New section.

  • Making and restoring backups :: Suppressing database triggers: Edited and extended this section, but removed the “SYSDBA and owner only” remark.

  • Making and restoring backups :: Direct I/O (Firebird 2.1.4+): New section.

  • Making and restoring backups :: Informational options (Firebird 2.5+): New section.

  • Making and restoring backups :: Backups on remote machines (Firebird 2.5+): New section.

  • Locking and unlocking: Slightly altered last sentence of second para.

  • Locking and unlocking :: Locking the database and backing up yourself: Added Comments (para + itemizedlist).

  • Locking and unlocking :: Restoring a backup made after nbackup -L: Added info on use of alias and -Z to step 2 of procedure.In next para, translated “en” (leftover from Dutch original) → “and”.Added sentence to Note about reading -F as Flag-only.

  • Locking and unlocking :: Locking raw-device databases: New section.

  • Locking and unlocking :: Under the hood: Edited Note.

  • Setting the delta file: 1st para largely rewritten;now refers to raw-device databases.Split off last sentence into a para of its own.Added info (para + programlisting) about setting delta with CREATE DATABASE.1st listitem in Notes: ADD → [ADD].

 

 

 

  • Document history: Changed ulink to CVS (both text and url);now points directly to document.

  • License notice: End year in copyright mention now 2011.

1.3

12 Oct 2011

PV

  • Functions and parameters: In first table: self-restored → user-restored.In second table: self-restore → user restore.

  • Locking and unlocking :: Locking the database and backing up yourself: Section renamed Locking the database and making the backup yourself.

  • Locking and unlocking :: Restoring a backup made after nbackup -L: 2nd listitem in 1st itemizedlist: self-restored → user-restored.

1.4

18 Sep 2014

MR

  • Backup history: New section

  • Technical background information New section

1.5

27 Jun 2020

MR

Conversion to AsciiDoc, minor copy-editing

1.6

25 Jul 2020

AK

Paragraph about VM backups, example with non-standard port, performance notice paragraph on incremental backup

1.7

10 Oct 2022

MR

  • Added switches introduced in Firebird 3.0 and 4.0

  • Various copy-editing

  • Fix rendering of Document History in PDF by breaking long entries into multiple entries