> Why do you need a localhost prefix? NBackup is expected to work fine
> without it, regardless of the TCP port of the FB server.

I need TCP, because I don't want 'direct access to the database file'
as I understand that this kind of access is not multi-thread safe. All
my database clients are connected to the database through TCP
(localhost).

> Really? Hmmm. But anyway, why would you need a different location,
> provided that nbackup should always be run on the same host, so what's
> wrong with running it from /bin?

I'm deploying firebird along with our custom application server, when
installing user has option to use already installed Firebird or to use
firebird server from custom application server subdirectory and
application server expects that nbackup or gbak is to placed in that
subdirectory. But this is no problem, I can fix this..but it's wrong
that it must be run from specific location or it does not work at all,
nor it gives any error message....

>
> > 3. Is full nbackup database dump (-B0 option) compatible with the gbak
> > dump and vice versa?
>
> Nope, they're completely different beasts.

Pity, but I understand that gbak is doing some 'database cleaning'
while performing backup and nbackup does not. If I start to use
nbackup for regular backups, is there any other tool that can be used
to 'maintain compact' database?

> Only nbackup, which does not work remotely. As for how it works, I'd
> suggest to pay more attention to the manual. Or try it yourself.

Yep ur right, I was hoping that nbackup is using TCP/IP and can be
used remotely as it accepts 'localhost' inside connection string, one
would assume that it will also accept IP addres of remote host
machine, but that is not the case, it seems that localhost is only
parsed and ignored, which makes this utility even worse....

My summary on nbackup tool:
- does not support remote (TCP) database access although u can use
'localhost' in connection string which can mislead u
- it expects that aliases.conf is placed in directory above, if not,
it breaks without any error
- when making full backup, seems that whole database file is copied to
the backup file, prior to this nbackup seems to lock database with
ALTER DATABASE BEGIN BACKUP thus allowing somewhat safer copy...
- when restoring database, original database file must not exist, you
have to delete it manually
- when making incremental backups u are never exactly sure what is
last full backup file from which incremental backup is done. I
recently found that you can find last full backup in the
RDB$BACKUP_HISTORY syste table, sort by date and find last backup with
level 0
- only thing that I can say is that I've tested nbackup on 'live
database with connected clients' and it seems to work without error
and very fast.
- with all these in mind and with warning that nbackup versions prior
to 2.1.1 can cause database deadlock probably I should give up on
incremental backups for firebird database until nbackup becomes more
stable.

Final question:
Does anybody actually use nbackup for database backups? Anyone has
practical experiences with this tool?

Branimir