Hi !

danny_vdw wrote:

> Hi,
>
> I m testing the new incremental backup facility for being used in the near future for production.
>

I am running nbackup for 15 days in production, so I am not an
experienced nbackup user, I will try to expose my view because I post
some questions about nbackup some week and got no answer.

> Test environment:
> * Windows Xp SP3 English version, 2 GB RAM
> * AMD 4400+ Dual core 2.2 GHz
> * Firebird Classic 2.1.3 RC1 (same situation occurs for 2.1.1, we don't use 2.1.2 of singleton bugcheck error in PSQL), pagebuffers 128 16K buffersize
> * I'm using Delphi 7 / FIBPlus in a 3 - tier application, 95% of the reads are being done in a read-only read committed trx (this transactions dies after 2 minutes of idle time); all writes occurs in short normal (concurry write) trxs, the gap OIT and Next trx is never big, at most 1000 in the worst case scenario when a OLAP report is running).
>
> When I issue the following command:
> nbackup -B 0 inventory.fdb inventory_1-Mar-2006.nbk
>
> I start a fresh full backup for my database Phoenix.
> I get a record in the system table rdb$backup_history:
>
> 1 2/07/2009 20:06:02 0 {7E18A0C7-D9EE-4CF3-14AB-FC56BBDE21BF} 0 phoenix.fdb-0-20090702-1956.nbk
>

I think you have some problems here (perhaps some attempt that failed
before) take a look:

nbackup -B 0 inventory.fdb inventory_1-Mar-2006.nbk


Shoud create the back-up file named as "inventory_1-Mar-2006.nbk" but in
your back-up history you have "phoenix.fdb-0-20090702-1956.nbk"

This name pattern is like the one generated by nbackup automatically
(when you does not provide a back-up name)

The delta file you see could be the one that was "stalled" when
generating some previous back-up.

did you aborted any attempt to run it ?

Could you try to run again and see if it complains about the database
already being in back-up mode ?

> While the nBackup utility is busy I m gonna stress a little bit the database. I got following files in my directory:
> PHOENIX.FDB 10.900.208 KB
> phoenix.fdb-0-20090702-1956.nbk 10.701.312 KB
>

As told before A name distinct from what you provided on the command line

> PHOENIX.FDB.delta 158.488 KB
>

ok

> After 11 minutes the nBackup utility finished his job, but still the PHOENIX.FDB.delta file exists, so what is know happened?
> Is the merge failed?
> Is the merge succeeded but the file isn't deleted?
>

I think you had some kind of problem during this task, the delta file is
automatically removed by nbackup

> A full validate says after this situation:
> Validation completed, no errors found
>
> What should I do, remove the PHOENIX.FDB.delta or will it be automatically removed when next nBackup cycle start?
>

It you not be removed automatically, I think that if the file is there,
there is some problem during the merge

> Does any one use nBackup in a heavy duty production environment without having trouble / corruption ?
>

I am using for 15 days, without a glitch, but with version 2.1.2

> I know much questions, so thx in advance for the answers
>

HTH

> Danny
>

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br