Re: [firebird-support] NBackup Backup Takes Long Time For Level 2.

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

15.11.2017 7:49, Anto Edin Charley antoedinchar...@gmail.com [firebird-support] 
wrote:
> For every Level 2 Backup it takes more than 30 Minutes to complete. Is there 
> anything i 
> need to Check/Improve

1) Try switch -d. NBackup should work at disk's speed.
2) You can migrate to Firebird 3 where performance of nbackup of level 1+ was 
improved.

> or if this is the normal time that will take for this kind of Database.

   30 minutes for copying of 20 Gb file is too much. Even notebook HDD can 
perform better. 
Check your storage system.

-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

04.08.2017 20:37, 'Leyne, Sean' s...@broadviewsoftware.com [firebird-support] 
wrote:
> Unfortunately, in your later post you suggested that nbackup is never safe to 
> use.

   Sure, as any other software it may have destructive bugs. Every software 
license has 
words like "this software is provided as-is without any guarantees". Firebird 
is not an 
exception.


-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Jesus Garcia jeg...@gmail.com [firebird-support]]

> El 4 ago 2017, a las 19:05, Dimitry Sibiryakov s...@ibphoenix.com 
> [firebird-support]  escribió:
> 
> 04.08.2017 18:52, Jesus Garcia jeg...@gmail.com [firebird-support] wrote:
>> As I understood he was saying to not use nbackup, and if one person involved 
>> in any way to 
>> firebird says not to use it, then what make him think to others?
> 
>   There is a difference between "do not use it" and "do not use it with this 
> version".

Sorry, may be I have not understood this phrase.

"Always use the latest release. For 2.5 it is 2.5.7. But even with this it is 
not guaranteed to work. Check list of nbackup-related bugs in tracker"

Jesús 

RE: [firebird-support] nbackup : Error assessing database due a missing delta file

['Leyne, Sean' s...@broadviewsoftware.com [firebird-support]]

>There is a difference between "do not use it" and "do not use it with this
> version".

Unfortunately, in your later post you suggested that nbackup is never safe to 
use.

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

04.08.2017 18:52, Jesus Garcia jeg...@gmail.com [firebird-support] wrote:
> As I understood he was saying to not use nbackup, and if one person involved 
> in any way to 
> firebird says not to use it, then what make him think to others?

   There is a difference between "do not use it" and "do not use it with this 
version".

   And, BTW, I'm not involved to Firebird.

-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

RE: [firebird-support] nbackup : Error assessing database due a missing delta file

['Leyne, Sean' s...@broadviewsoftware.com [firebird-support]]

> Hello Sean, I was replying to dimitry s. Have you read his response?
> 
> As I understood he was saying to not use nbackup, and if one person
> involved in any way to firebird says not to use it, then what make him think
> to others?

Let's just say that I find Dimitry S POV on many subject and his tone to be 
harsh, and they are not always appropriate.

Further, while he is associated with IBPhoenix, he does not speak for the 
Firebird project.

The opinion/voice that you should definitely be listening to is Dmitry Yemanov, 
he can speak for the project with authority.


Sean

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Jesus Garcia jeg...@gmail.com [firebird-support]]

> El 4 ago 2017, a las 16:54, 'Leyne, Sean' s...@broadviewsoftware.com 
> [firebird-support]  escribió:
> 
> > I only see three items pending, but anyway, why not remove Nbackup from 
> > firebird until it is safe to use? 
> 
> As others have pointed out, the latest FB versions have an updated nbackup 
> 
> 
> > Why is there a tool that cannot be used in a safe way? 
> 
> Q1: How do you *know* if a tool is safe in all possible situation/conditions? 
> 
> A1: You test under all possible conditions? 
> 
> 
> Q2: Can all possible conditions be predicted/known in advance? 
> 
> A2: Absolutely not! That is why all software has bugs! 
> 

Hello Sean, I was replying to dimitry s. Have you read his response?

As I understood he was saying to not use nbackup, and if one person involved in 
any way to firebird says not to use it, then what make him think to others?

Jesus

RE: [firebird-support] nbackup : Error assessing database due a missing delta file

['Leyne, Sean' s...@broadviewsoftware.com [firebird-support]]

Jesus Garcia,

> I only see three items pending, but anyway, why not remove Nbackup from
> firebird until it is safe to use?

As others have pointed out, the latest FB versions have an updated nbackup


> Why is there a tool that cannot be used in a safe way?

Q1: How do you *know* if a tool is safe in all possible situation/conditions?

A1: You test under all possible conditions?


Q2: Can all possible conditions be predicted/known in advance?

A2: Absolutely not!  That is why all software has bugs!


Sean

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Jesus Garcia jeg...@gmail.com [firebird-support]]

> 
> Always use the latest release. For 2.5 it is 2.5.7. But even with this it is 
> not 
> guaranteed to work. Check list of nbackup-related bugs in tracker: 
> http://tracker.firebirdsql.org/secure/IssueNavigator.jspa?sorter/field=updated/order=
> 

I only see three items pending, but anyway, why not remove Nbackup from 
firebird until it is safe to use?
> 

Why is there a tool that cannot be used in a safe way?

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

03.08.2017 11:00, Jorge Gonçalves projo...@gmail.com [firebird-support] wrote:
>  From which version is safe to use nbackup ?

   Always use the latest release. For 2.5 it is 2.5.7. But even with this it is 
not 
guaranteed to work. Check list of nbackup-related bugs in tracker: 
http://tracker.firebirdsql.org/secure/IssueNavigator.jspa?sorter/field=updated/order=DESC


-- 
   WBR, SD.

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Jorge Gonçalves projo...@gmail.com [firebird-support]]

>Restore your database from backup and never use nbackup with this bugged
FB version any
>more.

Done ...


>From which version is safe to use nbackup ?

Re: [firebird-support] nbackup : Error assessing database due a missing delta file

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

02.08.2017 15:20, Jorge Gonçalves projo...@gmail.com [firebird-support] wrote:
> Any idea how to prevent this problem to appear again in the future ?
> 
> FB Version : 2.5.2.26539

   Restore your database from backup and never use nbackup with this bugged FB 
version any 
more.


-- 
   WBR, SD.

Re: [firebird-support] nbackup

[hugo.lar...@yahoo.com [firebird-support]]

Hi,

Interesting that FB 3.0 reduces the nbackup time. Thanks for the info.

 We have so many installations so I think we will wait for FB 4.0 which have 
incremental nbackup restore and native replication.

BR,
 Fadi 

Re: [firebird-support] nbackup

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi Hugo,

Yes, in this case you can check MON$ tables.
Please note that in case of many connections query to MON$ can consume 
significant resources.



How do you recover if  it's stuck?


nbackup -n

>I noticed that the larger the database is the longer it takes to do 
nbackup even if the delta is very small.


In 2.5 nbackup of any level scans the whole database file.
Consider to migrate to 3.0 to take advantage of nbackup improvements

Regards,
Alexey Kovyazin
IBSurgeon
www.ib-aid.com



Hi Alexey,

In my case the database is seldom larger 500 MB and the backup takes 
30 maximum seconds.


Would it not be sufficient to check the  MON$BACKUP_STATE field 
(thanks Thomas) and if its stuck on state 1 or 2 for several minutes 
then I execute "ALTER DATABASE END BACKUP".

How do you recover if it's stuck?

I noticed that the larger the database is the longer it takes to do 
nbackup even if the delta is very small.


BR,

hugo

Re: [firebird-support] nbackup

[hugo.lar...@yahoo.com [firebird-support]]

Hi Alexey,

In my case the database is seldom larger 500 MB and the backup takes 30 maximum 
seconds.

Would it not be sufficient to check the  MON$BACKUP_STATE field (thanks Thomas) 
and if its stuck on state 1 or 2 for several minutes then I execute "ALTER 
DATABASE END BACKUP".
How do you recover if it's stuck?

I noticed that the larger the database is the longer it takes to do nbackup 
even if the delta is very small.

BR, hugo

Re: [firebird-support] nbackup

[Thomas Steinmaurer t...@iblogmanager.com [firebird-support]]

Hello,

> Hello,
> 
> Is there a way to ask a database if someone is performing a nbackup?
> 
> If it's in "the physical backup mode".
> 
> I'm always paranoid if there is a power failure during a backup and it 
> gets stuck in that mode and I would like it to recover from such situation.
> We have many hundreds of installations and it's difficult to monitor all.
> 
> Firebird 2.5 on Windows

Perhaps MON$DATABASE is delivering with the MON$BACKUP_STATE field?
https://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref-appx05-mondb.html


-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] nbackup

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi Hugo,

In HQbird, we monitor size and age of delta files.
If it is bigger or older than appropriate size/age (like 500Mb/6 hours, 
for example), the database is marked as critical in Control Center.
You can implement the same - the status of the database and path to 
delta file can be retrieved from the database.


Regards,
Alexey Kovyazin



Hello,

Is there a way to ask a database if someone is performing a nbackup?

If it's in "the physical backup mode".

I'm always paranoid if there is a power failure during a backup and it 
gets stuck in that mode and I would like it to recover from such 
situation.

We have many hundreds of installations and it's difficult to monitor all.

Firebird 2.5 on Windows

BR,
Hugo

Re: [firebird-support] "nbackup needs local access to database file"

[fabia...@itbizolutions.com.au [firebird-support]]

Ok, but something is not right, in some instances I am getting about 1 or 2 
megabytes throughput with gbak fb3, and I am getting 150 MB throughput with 
gbak fb 2.5; the problem is so evident it cannot be just different access. It 
seems there is a bottle neck somewhere; perhaps the small changes I've made to 
the firebird.conf are affecting it substancially??? Simple changes like tcpip 
packet size to 16384 instead of 8192, more memory assigned to some resources, 
nothing creazy, like multiply by 4 changes...
  - Original Message - 
  From: Mark Rotteveel m...@lawinegevaar.nl [firebird-support] 
  To: firebird-support@yahoogroups.com 
  Sent: Sunday, September 11, 2016 5:11 PM
  Subject: Re: [firebird-support] "nbackup needs local access to database file"


  On 10-9-2016 23:34, fabia...@itbizolutions.com.au [firebird-support] wrote:
  > I am getting this error while running nbackup:
  >
  > "nbackup needs local access to database file"
  >
  > The nbackup sentence is:
  >
  > Nbackup.exe -user SYSDBA -pas HereMyPass   -B  0
  >  localhost:MyDB_FB3.fdbC:\temp\MyDB_Level_0.nbk
  >
  > If I remove localhost: then it works, but that would be running as
  > embebed and it is a superserver with active network connections.
  >
  > Any ideas?

  Gbak and nbackup are different tools that work in a different way. Gbak 
  works through a Firebird server (real or embedded), while nbackup works 
  with the physical backup file.

  Mark
  -- 
  Mark Rotteveel


  
  Posted by: Mark Rotteveel <m...@lawinegevaar.nl>
  

  ++

  Visit http://www.firebirdsql.org and click the Documentation item
  on the main (top) menu.  Try FAQ and other links from the left-side menu 
there.

  Also search the knowledgebases at 
http://www.ibphoenix.com/resources/documents/ 

  ++
  

  Yahoo Groups Links

Re: [firebird-support] "nbackup needs local access to database file"

[Mark Rotteveel m...@lawinegevaar.nl [firebird-support]]

On 11-9-2016 09:11, Mark Rotteveel m...@lawinegevaar.nl 
[firebird-support] wrote:
> Gbak and nbackup are different tools that work in a different way. Gbak
> works through a Firebird server (real or embedded), while nbackup works
> with the physical backup file.

That should have been "physical database file".

-- 
Mark Rotteveel

Re: [firebird-support] "nbackup needs local access to database file"

[Mark Rotteveel m...@lawinegevaar.nl [firebird-support]]

On 10-9-2016 23:34, fabia...@itbizolutions.com.au [firebird-support] wrote:
> I am getting this error while running nbackup:
>
> "nbackup needs local access to database file"
>
> The nbackup sentence is:
>
> Nbackup.exe -user SYSDBA -pas HereMyPass   -B  0
>  localhost:MyDB_FB3.fdbC:\temp\MyDB_Level_0.nbk
>
> If I remove localhost: then it works, but that would be running as
> embebed and it is a superserver with active network connections.
>
> Any ideas?

Gbak and nbackup are different tools that work in a different way. Gbak 
works through a Firebird server (real or embedded), while nbackup works 
with the physical backup file.

Mark
-- 
Mark Rotteveel

Re: [firebird-support] nbackup problem : Database is already in the physical backup mode

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi Hugo,

So if the computer is shutdown during a nbackup the database is locked 
in this way indefinelty?




Yes, it's one of the most prevalent problems with nbackup.
To prevent it you need to monitor delta file age and size - manually, or 
automatically using our FBDataGuard tool.





What do you suggest I should do with JayBird when the exception is thrown?
Execute alter database end backup?



Yes, it should merge delta file back to the main database and unlock it.

Regards,
Alexey Kovyazin
IBSurgeon

Re: [firebird-support] nbackup problem : Database is already in the physical backup mode

[hugo.lar...@yahoo.com [firebird-support]]

Hello Mark,

So if the computer is shutdown during a nbackup the database is locked in this 
way indefinelty?

What do you suggest I should do with JayBird when the exception is thrown?
Execute alter database end backup?

BR,

Re: [firebird-support] nbackup problem : Database is already in the physical backup mode

[Mark Rotteveel m...@lawinegevaar.nl [firebird-support]]

On 27 Mar 2015 01:24:06 -0700, hugo.lar...@yahoo.com [firebird-support]
firebird-support@yahoogroups.com wrote:
 We have a POS application using Firebird 2.5.3 together with JayBird on
 about 300 sites.
 
 The applications runs nbackup several times everyday. It has happened
 several times on several sites that nbackup fails with following
exception:
 org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544351.
 unsuccessful metadata update
 Database is already in the physical backup mode
 
 What happes after this is that all database changes from that point get
 stored in the .delta file.
 
 The soulution i found is to make a full gbak and restore it.

You don't need to restore from a gbak backup, executing ALTER DATABASE END
BACKUP as sysdba (see
http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-ddl-database.html#langrefupd25-alter-db
) should be enough to have the delta file merged back into the database
and ending physical backup mode.

 The is serious nbackup issue which causes problem for the database in
 general.
 The only way to discover this problem is to look after a .delta file or
 attempt another run nbackup again.
 I dont think it's  database corruption or disk problem because it has
 happen too often and everything works fine after the restoring from
gbak.

The  question is whether this is an actual nbackup problem, or if Jaybird
does something wrong with its nbackup implementation causing the backup to
not end correctly. Do you have a reproducible case? Have you checked
whether the previous backup actually ended, or ended correctl?

 I have a copy of such corrupted database if it's interesting.

Not sure if it is: it sounds like the backup mode wasn't completed, and
that is not a corruption.

Mark

Re: [firebird-support] nbackup problem : Database is already in the physical backup mode

[Mark Rotteveel m...@lawinegevaar.nl [firebird-support]]

On 27 Mar 2015 02:52:54 -0700, hugo.lar...@yahoo.com [firebird-support]
firebird-support@yahoogroups.com wrote:
 So if the computer is shutdown during a nbackup the database is locked
in
 this way indefinelty?

As far as I know: yes, until you manually end the physical backup mode.
 
 What do you suggest I should do with JayBird when the exception is
thrown?
 Execute alter database end backup?

What if another user has started a nbackup on the same database? It is
risky to just assume that the error is caused by a failed/crashed backup
and then disable the physical backup mode; that could potentially corrupt
the backup by the other user. I'd suggest that executing the alter
database end backup should be an explicit (manually started) action.

Mark

Re: [firebird-support] nbackup and lost indexes

[fabianoas...@gmail.com [firebird-support]]

What is you firebird version?
AFAIK the only working version, whit no bugs, is 2.5.3
So, try updating customer's Firebird and try again.
Em 04/12/2014 13:10, wobble...@yahoo.co.uk [firebird-support] 
firebird-support@yahoogroups.com escreveu:



 Hi All,


 We use nbackup to pull live copies of customer's production databases back
 to our office to play with and help with support. We run a level0 backup
 every weekend, and a level1 every day which are both copied back to the
 office over night. That just leaves us to run a level2 when we want a live
 copy. Generally it does exactly what it says on the tin and we are all
 happy at the speed we can grab a customer's 5GB database without the server
 really noticing - as opposed to a full gbak stealing all the disk IO.


 However, occasionally we end up tearing our hair out chasing down bizarre
 bugs not directly related to the issue we are really interested in, and it
 always ends up being a problem with the indexes that nbackup has restored. 
 There
 doesn't seem to be any pattern to the customers this affects, the size of
 the level2, the time of day, or anything. Sometimes a random index seems to
 just get corrupted. Queries still use it, but get no results. If we
 deactivate/activate an offending index then everything is great again.

 Has anyone else come across something similar?


 Thanks


 Ian



  

Re: [firebird-support] nbackup database made database inaccessible

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hello,

If you have moved or deleted .delta-file, you got the correct message.
If delta file was corrupted, or database was corrupted in the way which 
prevent merge, there could be various error messages.


Check your database with gfix -v -full now, to be sure it's Ok.

Is it risky to run a nbackup?
If you are using nbackup, you need to understand that you need to watch 
delta file size and lifetime, and also be aware that nbackup does not 
detect any errors on page or record level.


Regards,
Alexey Kovyazin
IBSurgeon



Hello,

I have encountered a serious problem with nbackup.
During a automated nbackup something happened with the .delta file and 
the database was inaccessible until i luckily found the command 
nbackup.exe -U which addressed the problem. Nothing else worked.

The error message was that the .delta file is missing.

The nbackup was executed from JayBird.
Firebird 2.5.3 on Windows.

What causes this? Is it risky to run a nbackup?

BR,

Hugo

Re: [firebird-support] nbackup

[Tony Christiansen t...@adegroup.com.au [firebird-support]]

RE: [firebird-support] NBackup Levels

[Leyne, Sean]

 But as far as I understand, the database has to track which page changes
 since which backup.

Correct, but that information is actually stored as a version number in the 
header of each data page.  When page data changes the version number is 
changed.

The nbackup database structure only stores the version number for the backup 
level.

NBackup physically reads each page header to determine if the page version 
has changed since the last backup.

No list of the pages that have changed is stored within the database.


Sean

RE: [firebird-support] NBackup Levels

[Leyne, Sean]

 From a quick search, I suspect that will be the pag_scn 4 byte value.

I don't recall exactly, if you want to pursue this you should ask on the Devel 
list for confirmation.


 That would mean that I could relatively easily write my own sync code that
 could also read all those values and decide which page would need to be
 transferred while the file is locked.

I don't think that it will be advisable (see below), but why duplicate what 
nbackup is already doing?


 The disadvantage would be that I would need to keep close control of these
 files as nbackup could not come to help to prevent incorrect ordering while
 merging...

There are many other factors to consider:

- backup/restore of source database using gbak -- this would reset all page 
version values

- correctly detecting the database page size value -- which can be changed via 
gbak backup/restore.

- the ODS (on disk structure) for database pages can change from version to 
version*.  You would need to factor these changes in your own code.


 Does NBackup do any other magic than that?

It ensures that a backup file is being applied to the correct target database 
-- it does not blindly restores backup files on top of database.


Sean

* A change to the header layout would be part of a major ODS update.  Such 
updates have (historically) only occurred with major Firebird releases (though 
this may change in the future)

Re: [firebird-support] NBackup Levels

[Kjell Rilbe]

Steffen Heil (Mailinglisten) skriver:

 Hi

   I could simply create backups with incrementing levels, move the
   backup to the other server(s) and apply them there (that database is
   offline).
   However, I suspect there is a limit for the number of backup levels a
   database can have.

  You don't need a lot of backup levels to do what you want. For 
 example, Do a level 0 backup once a month/year/whatever, then do a
  level 1 backup every weekend, a level 2 backup every day, and if 
 required a level 3 backup every hour/whatever.

 For another type of service I already have a backup script that 
 creates 5 levels of backups:
 Level 0 at the first Sunday of every quarter.
 Level 1 at the first Sunday every month.
 Level 2 at every Sunday.
 Level 3 every day.
 Level 4 every hour.

 But for this project I want more than hourly consistency. I am 
 targeting 5 minuites or even less. That could be done using:
 Level 5 every 5 minutes.

 However in this case there might be lots of days with nearly no 
 difference and then there may be some days with gigabytes of changes.
 Using an approach as above would mean to copy all these changes up to 
 23 times...
 I would really like to prevent that kind of extra traffic AND more 
 important that delay in synchronization.
 Moreover, the servers hard drives may be rather slow and the database 
 may grow up to 200 GB.
 (During operation there are relatively few reads and only some writes, 
 the database is idle 99% of the time, so for operation the slow
 io system is not a problem.)


I understand your problem. Would it be possible to measure the size of 
each level 5 backup, and if it's over a certain threshold use a higher 
level for the rest of that day to keep from copying the same large set 
of data over and over?

In essence, you would create a script that backs up every five minutes, 
and if the last backup size was below a certains threshold use the same 
level as before, otherwise bump it up. Reset to level 3 each night.

The benefit is that you won't create a large number of levels unless 
it's actually needed to reduce backup traffic.

Regards,
Kjell




++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu.  Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com 

++
Yahoo Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

* To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

* To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

* Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

RE: [firebird-support] NBackup Levels

[Svein Erling Tysvær]

I understand your problem. Would it be possible to measure the size of each 
level 5 backup, and if it's over a certain threshold use a higher 
level for the rest of that day to keep from copying the same large set of data 
over and over?

In essence, you would create a script that backs up every five minutes, and if 
the last backup size was below a certains threshold use the same 
level as before, otherwise bump it up. Reset to level 3 each night.

The benefit is that you won't create a large number of levels unless it's 
actually needed to reduce backup traffic.

I thought similar to Kjell, yet opposite: If the size is over the threshold, 
just do an extra backup at a lower level, e.g. make a level 2 backup if the 
level 5 backup is above 1 Gb and a level 3 backup if the level 5 backup is 
above 100Mb or similar. I would expect it to be possible to mix this with the 
backup scheme that you've already described, but I've absolutely no knowledge 
of NBackup and may be completely wrong.

HTH,
Set

RE: [firebird-support] NBackup Levels

[Leyne, Sean]

  There is no formal limit, ...
 
 Is there a negative effect on too many levels?
 (Slowdown or database storage overhead?)

No negative effect.

The database does track the ID of the last backup at each level, so you would 
have 2 or 3 more entries that the typical usage, but the details are notional 
in size.


Sean

Re: [firebird-support] NBackup Levels

[Zsazsi]

Every operating system has some limit on environment strings like command
line, that can be a problem on restore where the every level's filename
should be supplied.

Not sure if it's a theoretical or practical problem in Your case.

I use 3 levels (0 - friday night, 1 - every other weekday night, 2 - 90
minutes).

Regards

Zsazsi


2014-05-07 8:43 GMT+02:00 Steffen Heil (Mailinglisten) 
li...@steffen-heil.de:

 Hi


  There is no formal limit, ...

 Is there a negative effect on too many levels?
 (Slowdown or database storage overhead?)


 Regards,
   Steffen



 

 ++

 Visit http://www.firebirdsql.org and click the Resources item
 on the main (top) menu.  Try Knowledgebase and FAQ links !

 Also search the knowledgebases at http://www.ibphoenix.com

 ++
 Yahoo Groups Links

Re: [firebird-support] NBackup Levels

[Kjell Rilbe]

Den 2014-05-05 22:27 skrev Steffen Heil (Mailinglisten) såhär:

 I know that nbackup keeps track of which blocks in the database 
 changed and which did not so that backups contain only the blocks that 
 changes since the last backup of the next lower level.
 I want to use that feature to do syncs between servers.

 I could simply create backups with incrementing levels, move the 
 backup to the other server(s) and apply them there (that database is 
 offline).
 However, I suspect there is a limit for the number of backup levels a 
 database can have.


You don't need a lot of backup levels to do what you want. For example, 
Do a level 0 backup once a month/year/whatever, then do a level 1 backup 
every weekend, a level 2 backup every day, and if required a level 3 
backup every hour/whatever.

Copy the backup files to the remote server, and use nbackup there, to 
restore the most current backup chain. Granted, the restore operations 
on the other server(s) will take a bit of time, but if those servers are 
offline, that would not really be a problem. In fact, I see no real 
point in doing those restores until you actually need to put the backup 
online. Just save the most recent chain of backup files, and you're 
ready to do a restore when the need arises.

 Another strategy would be to lock the database, take a copy, unlock it 
 and then use external software to do the diff.
 However that would mean that the database would have to be copied very 
 often and that a lot of extra space was needed.
 That would mean a lot of disc io.

 That could be reduced, if I locked the database, sync it using some 
 software as rsync and then unlock it again.
 I would not need extra copies any more, but a) the database would need 
 to be offline much longer (remote sync needs more time) and b) it 
 would have to be done for every replica again.


This is the approach I use for my 100+ Gbyte database on modest hardware 
(Windows server with 7200 rpm scsi traditional non-ssd harddisks). I use 
FastCopy (http://ipmsg.org/tools/fastcopy.html.en) to copy the database 
files while it's locked and then rsync the copy to our backup server. 
The FastCopy takes about 45-60 minutes and the rsync usually takes a 
couple of hours.

There is NO downtime! The application is online when the database is 
locked and of course also during rsync.

 So here are my questions:

 a) How many levels of backups can a database have (nbackup, not gbak)?


Sorry, I don't know. But I don't think you need more than 3-5 levels.

 b) How bad is it (in terms of performance) to lock a database for a 
 longer period of time?


I've seen no problems whatsoever with the scheme I described, in which 
the database is locked for about an hour. I don't see how/why you would 
need any more than that.

 c) Is there any way to get the information used by nbackup without 
 actually creating a new backup level? (Just use this information to 
 use external block copying?)


Sorry, I don't know.

 d) Is there any other good way to create a live exact replica?


Shadow file feature? Third paerty replication tools?

Regards,
Kjell

Re: [firebird-support] nbackup strategy advice

[Thomas Steinmaurer]

Hello,

 Hello,
 We have a POS applications with hundreds of clients and need some advice
 on how to backup.
 Each application has it's own Firebird database.
 Read about nbackup and thought that this could be a solution since the
 clients has low bandwidth.

I'm not entirely sure if I understand your scenario correctly. Is the 
database running at your customer site or are you acting as a service 
provider and the customers are connecting via e.g. terminal services or 
similar? How is bandwidth related to backup here?

If possible, I would always be in favor for gbak over nbackup due to its 
logical data processing approach, thus detecting data corruption etc. 
How large are your databases?


-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] nbackup strategy advice

[Paul Vinkenoog]

Hello Hugo,

 We have a POS applications with hundreds of clients and need some advice on 
 how to backup.
 Each application has it's own Firebird database.
 Read about nbackup and thought that this could be a solution since the 
 clients has low bandwidth.

 My first idea was to daily backup and begin with N=0 and count up the N each 
 day. This would result in probably hundreds of files.
 Would this be an OK solution?
 
Incrementing the backup level above 2 or 3 usually doesn't make sense.

An nbackup scheme may look something like this:

- A full (level-0) nbackup every month
- A level-1 incremental nbackup every week
- A level-2 incremental nbackup every day
- Optionally: a level-3 incremental nbackup every hour

Of course this is just an example, but you get the general idea.

With the 4 levels in the example, any restore would involve at most 4 files.

You should probably also script a deletion scheme.

See also the nbackup guide, especially this page: 
http://www.firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/nbackup-backups.html

 Is it possible to restore a database with 1000 of nbackup files?

Theoretically, yes. But you don't need that many levels. And you can't put that 
many file names on the command line.

 Is it possible to tell nbackup to read all files in a folder?

Not directly. If you want to nbackup multiple databases, you should write a 
shell script that calls nbackup within a loop, each time with a different 
database name.


Hope this helps,
Paul Vinkenoog

Re: [firebird-support] nbackup questions

[Hugo Eyng]

Hi.

I am not sure if i understood your question.

You want to move the fdb file to another computer?

Hugo Eyng

Em 15/01/2014 12:52, Maury Markowitz escreveu:


I am a admin of the Fishbowl Inventory (FBI) system for our company, 
which is a Java app on top of Firebird.


I need to move the system off an unstable machine. FBI does not allow 
me to simply replace the .FDB files, for reasons that have not been 
explained (error codes that make no sense). I experimented with using 
the system's automated nbackups to replace the information in an 
existing .FDB, and that works. *phew*


The problem is that the system's Scheduler function, without any 
warning or errors, stopped making these nbackups last May. So I need 
to make an nbackup manually. So I tried...


nbackup -U gone -P fishing -B 0 ../data/EXAMPLE.FDB ../data/ex.bak

However, this results in the error, You must be either SYSDBA or 
owner of the database.


The thing is, the user gone is the only one that appears in SHOW 
USER in isql, so how could it be the case that they are not the owner? 
Can one assign ownership to a non-existant user? Might it be assigned 
to SYSDBA?


Moving on I tried the same command, but this time with SYSDBA and 
masterkey. This results in another error, Your user name and password 
are not defined. I assume this is because masterkey is no longer 
used, but the installer process does not ask for a password. The dox 
suggest that the password might be randomly assigned in this case, and 
then stored in a file, but I cannot find the file it refers to.


Can anyone offer suggestions on how to solve this?




--


Atenciosamente,

Hugo Eyng

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 2:02 PM, Hugo Eyng wrote:
 
 I am not sure if i understood your question.
 
 You want to move the fdb file to another computer?

That is correct.

For reasons that I do not understand, the simple method of simply copying the 
FDB from one machine to another does not work. When I try to attach to that 
database, it reports file not found, which I assume is a spurious error code.

But there already is a small (example) database file on that machine that I 
*can* attach to. I can also restore into it. So if I can get nbackup to work, 
that provides a way to move the data over.

Re: [firebird-support] nbackup questions

[Alexandre Benson Smith]

Em 15/1/2014 17:30, Maury Markowitz escreveu:
 On 2014-01-15, at 2:02 PM, Hugo Eyng wrote:
 I am not sure if i understood your question.

 You want to move the fdb file to another computer?
 That is correct.

 For reasons that I do not understand, the simple method of simply copying the 
 FDB from one machine to another does not work. When I try to attach to that 
 database, it reports file not found, which I assume is a spurious error 
 code.

 But there already is a small (example) database file on that machine that I 
 *can* attach to. I can also restore into it. So if I can get nbackup to work, 
 that provides a way to move the data over.



I think it's related to not finding the delta file you mentioned on 
another post.

For some reason the delta file is not merging back to the main file.

Take a look on nbackup (http://www.firebirdsql.org/manual/nbackup.html) 
manual so you could try to merge it back manually.

see you !

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 2:43 PM, Alexandre Benson Smith wrote:
 
 Take a look on nbackup (http://www.firebirdsql.org/manual/nbackup.html) 
 manual so you could try to merge it back manually.

Indeed, but that brings me back to the actual problem... I do not know the 
password for SYSDBA, and the only registered user does not have enough privs to 
run nbackup.

So, how do I retrieve the SYSDBA pass?

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 2:43 PM, Alexandre Benson Smith wrote:
 
 Take a look on nbackup (http://www.firebirdsql.org/manual/nbackup.html) 
 manual so you could try to merge it back manually.

But wait... what about...

ALTER DATABASE END BACKUP

If I am reading it correctly, this appears to do the same thing as nbackup -N. 
Is that correct?

Re: [firebird-support] nbackup questions

[Paul Vinkenoog]

Maury Markowitz wrote:

 But wait... what about...

 ALTER DATABASE END BACKUP

 If I am reading it correctly, this appears to do the same thing as nbackup 
 -N. Is that correct?

That is correct, but in order to issue that command you must connect to 
the database as SYSDBA or owner.

 From your earlier postings, I gather that in May 2013 nbackup failed to 
complete, so the main database file has been frozen for 8 months, and 
all the changes since May 2013 have accumulated in the delta.

User GONE doesn't seem to be the owner, and you don't know the SYSDBA 
password. The fact that it isn't masterkey makes sense: either the 
installer generated a random password, or the password was left at 
masterkey. In the latter case, any database administrator in his right 
mind would immediately change it to something else.

Why don't you contact the administrator of the system in question? After 
all, *someone* should know the SYSDBA password, shouldn't they? And how 
about the scripts that executed nbackup until they went broken last May? 
Do you have read access to them? What authentication method did they 
use? And if you can't access those scripts, who can?


Kind regards,
Paul Vinkenoog

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 4:29 PM, Paul Vinkenoog wrote:
 
 Why don't you contact the administrator of the system in question? After 
 all, *someone* should know the SYSDBA password, shouldn't they?

I don't believe so. The installer process that created the DB, which comes from 
Fishbowl, not Firebird, never asked for a SYSDBA password, and did not report 
one.

Some of the dox suggest the Firebird installer will leave behind a file saying 
what the password was randomly set to. No file of this type appears to be on my 
system.

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 5:40 PM, hv...@users.sourceforge.net 
hv...@users.sourceforge.net wrote:
 
   This is too strong statement. To verify it we need to know physical backup
 state of the database. gstat -h will show it (and it not requires admin 
 privileges).

I am able to run this on the original server, are there some additional 
switches you would like? Here is what I got with -h, and I see that force 
write, backup lock at the bottom, which I suspect is interesting...

Database ../data/company.fdb
Database header page information:
Flags   0
Checksum12345
Generation  753393
Page size   4096
ODS version 11.2
Oldest transaction  734639
Oldest active   734640
Oldest snapshot 734640
Next transaction734721
Bumped transaction  1
Sequence number 0
Next attachment ID  18032
Implementation ID   26
Shadow count0
Page buffers0
Next header page0
Database dialect3
Creation date   Sep 1, 2012 10:22:08
Attributes  force write, backup lock

Variable header data:
Database backup GUID:   {407742FD-11DE-43CD-60B7-CBCCC1AA866E}
Sweep interval: 2
*END*

Re: [firebird-support] nbackup questions

[Paul Vinkenoog]

Hello Maury,

 Why don't you contact the administrator of the system in question? After
 all, *someone* should know the SYSDBA password, shouldn't they?

 I don't believe so. The installer process that created the DB, which comes 
 from Fishbowl, not Firebird, never asked for a SYSDBA password, and did not 
 report one.

So Fishbowl installed the Firebird server and kept the SYSDBA password 
to itself. That makes (some) sense.

The only user you know the password of doesn't seem to have access to 
the database. This suggests that either SYSDBA or another Firebird user 
account (created transparently by Fishbowl, with name and password kept 
internal) is the owner.

I think you should contact Fishbowl Inventory support to clear this up.

 Some of the dox suggest the Firebird installer will leave behind a file 
 saying what the password was randomly set to. No file of this type appears to 
 be on my system.

Yes, some installers on Posix systems do this. If this is the case, the 
generated password is in the file SYSDBA.password in the Firebird 
installation directory.

Most keep it at masterkey though. In your case, I assume that the 
Fishbowl software has generated a secure SYSDBA password.


Kind regards,
Paul Vinkenoog

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 8:23 PM, Paul Vinkenoog wrote:
 
 I think you should contact Fishbowl Inventory support to clear this up.

Indeed; they currently have a multi-hour phone wait time.

 Most keep it at masterkey though. In your case, I assume that the 
 Fishbowl software has generated a secure SYSDBA password.

Nice of them to record it...

Re: [firebird-support] nbackup questions

[Hugo Eyng]

There are some things you should observe:

1 - Use the same version of FB server in the computer you move the 'fdb' 
to that you use in the 'source' computer;

2 - Before copying the 'fdb' stop the FB server service;

Another thing I would tell you is that you should use 'gbak' to backup 
your source 'fdb'  and then, in the destination

computer, use 'gbak' to restore and recreate the 'fdb'.

Em 15/01/2014 17:30, Maury Markowitz escreveu:


On 2014-01-15, at 2:02 PM, Hugo Eyng wrote:

 I am not sure if i understood your question.

 You want to move the fdb file to another computer?

That is correct.

For reasons that I do not understand, the simple method of simply 
copying the FDB from one machine to another does not work. When I try 
to attach to that database, it reports file not found, which I 
assume is a spurious error code.


But there already is a small (example) database file on that machine 
that I *can* attach to. I can also restore into it. So if I can get 
nbackup to work, that provides a way to move the data over.





--


Atenciosamente,

Hugo Eyng

Re: [firebird-support] nbackup questions

[Maury Markowitz]

On 2014-01-15, at 8:23 PM, Paul Vinkenoog wrote:
 
 I think you should contact Fishbowl Inventory support to clear this up.

So a little Google-fu was all that took. Now armed with the credentials, what 
would be the next steps at this point?

I suspect the next step is to END BACKUP. However, I wish to tread carefully... 
I don't have a backup newer than last May, the existing FDB is not a usable 
file as far as the new machine is concerned, etc.

So, what exactly happens when you do the END BACKUP? Does the server have to 
fold the delta into the original FDB? If so, I suspect this is a long-running 
task given the size of the file? Or is this a much simpler task, simply 
renaming the files or such?

If I first copy the original FDB and delta, if something goes wrong during END 
BACKUP will those files be useful to me? It does not appear the original FDB is 
a working database (at least I cannot connect to it), and I suspect the name 
delta is accurate so it is not a usable file by itself either. This seems to 
suggest (I know I know, ASSuME) that simply copying these files to offline 
storage gets me basically nothing?

Re: [firebird-support] nbackup questions

[Paul Vinkenoog]

Hello Maury,

 So a little Google-fu was all that took. Now armed with the credentials, what 
 would be the next steps at this point?

 I suspect the next step is to END BACKUP. However, I wish to tread 
 carefully... I don't have a backup newer than last May, the existing FDB is 
 not a usable file as far as the new machine is concerned, etc.

 So, what exactly happens when you do the END BACKUP? Does the server have to 
 fold the delta into the original FDB? If so, I suspect this is a long-running 
 task given the size of the file? Or is this a much simpler task, simply 
 renaming the files or such?

 If I first copy the original FDB and delta, if something goes wrong during 
 END BACKUP will those files be useful to me? It does not appear the original 
 FDB is a working database (at least I cannot connect to it), and I suspect 
 the name delta is accurate so it is not a usable file by itself either. 
 This seems to suggest (I know I know, ASSuME) that simply copying these files 
 to offline storage gets me basically nothing?

If you connect to the database and issue ALTER DATABASE END BACKUP:
- The delta (containing the changes since May last year) will be re-integrated 
with the main database file (.fdb).
- Upon success, the delta will be deleted and the state flag of the database 
file set back to normal.

Then, you should make a regular backup with gbak and restore that on your 
target machine (using gbak on your target machine).

I have no idea how much time re-integrating a 70 MB delta will take. Is it a 
problem if it takes several hours? (Not that I expect this.)

As for copying the current .fdb and .delta to your target machine:

- Copying the .fdb is safe - IN THIS CASE! - because the file is frozen and 
closed. (Under normal circumstances, copying an .fdb file is unsafe, unless you 
take special precautions.)

- Copying the .fdb.delta may be unsafe because its a live database file. Even 
if no users are connected to it, the 'hidden' user (or SYSDBA) may be connected 
from within Fishbowl. Can you stop Fishbowl completely? And then check if no 
process has the .delta file open. Then it may be safe (and even wise) to copy 
the two files to your target machine, just in case. (Note: if the source and 
target machine have a different platform architecture, straight file copies may 
not work on the target machine. If they have different endianness, straight 
file copies are *guaranteed* not to work.


Cheers,
Paul Vinkenoog

Re: [firebird-support] Nbackup, Default I/O ON or OFF

[Dmitry Kuzmenko]

Hello, atunccekic!

Friday, December 20, 2013, 12:35:54 PM, you wrote:

adct  It's no big deal but,
adct  Maybe it can be written in the help like :   
adct  Use or not direct I/O when scanning database (Default: Off) 

I think there is a mistake, because nbackup is a part of Firebird
server, so it can't change Forced Write mode for the database where
clients are working.
So, -d option can be used only for the target file, not when scanning
database
But, yes, it is inetersing to know the default of -d option, anyway.

adct  And why am I searching on this.. My system crawled while doing
adct a -B 0 level nbackup today, which I have never tried before.
adct Everything was fine when it finished. 

you are lucky. nbackup can lock if some of fb_inet_server processes
has not finished writing changed pages.
You will see that your delta grows constantly.

adct  But the db file is 28gb having many connections and it took
adct about 10minutes to complete.

10 minutes for 28gb I think is ok. You have good hardware (disks), and I'm
sure that you made nbackup to another physical disk, or at least to
another logical disk on your RAID 10.

adct And now I'm hasitating to start the -B 1 level nbackup.
adct  Will it suspend every connection?

no. why?

adct  Will it take long?

In FB 2.x nbackup always scan the whole DB, for any nbackup level.
So, it will take only a bit less time for -b 1, -b 2, etc.
This behavior will be fixed in Firebird 3.0 (only changed pages
will be scanned).

adct  Should I update to 2.5.2 first?

yes, sure, by lot of other reasons. But not all things related to nbackup are 
fixed.

-- 
Dmitry Kuzmenko, www.ib-aid.com

Re: [firebird-support] NBackup

[Dmitry Kuzmenko]

Hello, alessandroyamasaki!

Friday, December 20, 2013, 8:16:17 PM, you wrote:

agc  I'm trying to run nBackup Firebird through command line below
agc  C: \ nbackup.exe-U sysdba-P masterkey-B 0 C: \ nomedobanco.FDB C: \ 
nomedobackup.TMPNBK

exactly nbackup-U ? and other spaces/nospaces ?

do you have access rights to the C:\ folder?

-- 
Dmitry Kuzmenko, www.ib-aid.com

Re: [firebird-support] NBackup

[Alessandro Yamasaki]

Hi

Yes, I have access to the folder. Thank you for your attention.

The problem was the quotes

resolved


C:\nbackup.exe -U sysdba -P masterkey-B 0 C:\nomedobanco.FDB
C:\nomedobackup.TMPNBK

[]´s



2013/12/20 Dmitry Kuzmenko k...@ibase.ru



 Hello, alessandroyamasaki!

 Friday, December 20, 2013, 8:16:17 PM, you wrote:

 agc I'm trying to run nBackup Firebird through command line below
 agc C: \ nbackup.exe-U sysdba-P masterkey-B 0 C: \ nomedobanco.FDB C: \
 nomedobackup.TMPNBK

 exactly nbackup-U ? and other spaces/nospaces ?

 do you have access rights to the C:\ folder?

 --
 Dmitry Kuzmenko, www.ib-aid.com

  

Re: [firebird-support] NBackup level 0 vs. file copy?

[Konstantin Khomoutov]

On Tue, 8 Oct 2013 12:37:57 +0200
Kjell Rilbe kjell.ri...@datadia.se wrote:

 Working with FB 2.5 on Windows 64 bit, how does Nbackup level 0
 perform compared to a high-performance copy utility like FastCopy?
 
 I'm asking because my DB is 80+ Gbyte and both the database and the 
 backup are currently on the same physical disk. FastCopy works with 
 large chunks to minimize time wasted on disk seeks.
 
 How does NBackup perform in this regard?
 
 Second question: after transferring the level 0 backup file to a
 secure backup volume, I want to use it to create a DB copy for
 test/delev/debug purposes. I can do that using Nbackup restore, b ut
 does this imply copying the entire database yet again?
 
 With a file copy solution with Nbackup lock, I can essentially use
 the copy as is (need to do Nbackup fixup + sweep though). I.e. a
 single read+write of 80 Gbyte. Is this possible with a Nbackup level
 0 backup approach?

Note that nbackup not only copies the data but also updates a special
system table in the database, recording the backup level, timestap and
name of the destination file.  This is used by nbackup to create backup
of the next (lower level).  So if you intend to ever take backups of
lower levels, I'd say you have to use nbackup to do the job, otherwise
lock/copy/unlock is a quite reasonable alternative, I reckon.

RE: [firebird-support] NBackup level 0 vs. file copy?

[Leyne, Sean]

Dmitry,

 Tuesday, October 8, 2013, 2:37:57 PM, you wrote:
 
 KR Working with FB 2.5 on Windows 64 bit, how does Nbackup level 0
 KR perform compared to a high-performance copy utility like FastCopy?
 
 as I see on my desktop nbackup -b 0 is 2-3 times slower than lock/file
 copy/unlock. I think this is known behavior.

In general this is expected, though, the performance difference is less 
significant for larger databases, where the size of the database is larger than 
the OS disk cache.  (OS's perform file copy using their caches to act as a 
write buffer for copy operations)

Nbackup will always be slower due to the fact that it performs individual page 
read/write (ie. Random IO) operations whereas file/fast copy operation use file 
block (ie. Sequential IO) operations which are much faster.


 KR I'm asking because my DB is 80+ Gbyte and both the database and the
 KR backup are currently on the same physical disk.
 this is BAD. Because of 2 concurrent operations - read and write.
 If this is not raid 10, then read+write will be 2 times slower than read from
 one physical disk and write to another physical disk.
 This has nothing related to nbackup, it is just about copying any file.

Agreed.


Sean

RE: [firebird-support] NBackup problem, causing deadlock

[Leyne, Sean]

Matthias,

 We have Firebird 2.5.2.26540, using SuperClassic, 70 users, our
 database file has 2GB, we schedule nbackup every 20 minutes to make a
 incremental backup, after implantation we had a problem, on average once a
 day and happens deadlock and the firebird service stops and we have to kill
 on the task manager to start again. If I disable NBackup not happen deadlock.

Please explain your meaning of deadlock.

Nbackup can significantly consume available disk IO resources while it is 
running.  Please provide details on the disk subsystem which you are running on.


Sean

Re: [firebird-support] NBackup freezes OIT ?

[Ivan Přenosil]

 I just made some nbackup tests (FB 2.5.2 SS, Windows XP) and noticed that 
whenever I use it to restore a database, it's Oldest transaction (OIT) gets 
stuck. It remains at the same value until next database sweep. Is it a bug 
or a feature ?



I think the problem is here:




What nbackup do is




* start transaction

* execute ALTER DATABASE START BACKUP

* commit transaction

* do physical copy of db file


* start transaction

* execute ALTER DATABASE END BACKUP

* commit transaction





the START BACKUP will redirect all subsequent db changes into delta file,

which means the following COMMIT will write its changes into delta,

not the original file, which means the copied database contains

this transaction in ACTIVE state.

On first connect to copied database the state of this active transaction 
is

changed to rollback, thus it becomes your stuck OIT.




Ivan

[Non-text portions of this message have been removed]

Re: [firebird-support] NBackup freezes OIT ?

[Ann Harrison]

On Tue, Apr 16, 2013 at 4:48 AM, remk_1 rem...@yahoo.com wrote:


 I just made some nbackup tests (FB 2.5.2 SS, Windows XP) and noticed that
 whenever I use it to restore a database, it's Oldest transaction (OIT) gets
 stuck. It remains at the same value until next database sweep. Is it a bug
 or a feature ?

 The Oldest Interesting Transaction (OIT) is the oldest transaction in the
system that is not committed.  Ordinarily, that's a transaction that rolled
back and could not be cleaned up automatically.  Only sweep can change the
OIT.The Oldest Active Transaction should move freely, unless you've got
a long running transaction.  The OAT blocks garbage collection and causes
performance problems.  The OIT is much less interesting.  It does require
that every transaction have access to a bitmap of transaction states
between the OIT and the Next Transaction, but that's much less of an issue
than it was when machines had memory measured in megabyte rather than gigs.
 So, neither a bug nor a features.  Just an artifact.

Good luck,

Ann


[Non-text portions of this message have been removed]

Re: [firebird-support] nbackup failure - cause?

[Nick Upson]

the level 0 backup restores ok and gbak will then backup  restore that,
could the corruption be somewhere that that doesn't matter?
how can I find and deal with it?

On 1 November 2011 09:47, Nick Upson nick.up...@gmail.com wrote:

 sorry, didn't think to say, its version 2.1.4


 On 31 October 2011 17:21, Alexey Kovyazin a...@ib-aid.com wrote:

 **


 Hello Nick,

 It seems like you have database corruption.
 What is Firebird version?

 Regards,
 Alexey Kovyazin
 IBSurgeon (www.ib-aid.com)


  Hi,
 
  I have recently started using nbackup and have a system where, at the
  end of an attempt to do a level 0 I got
 
  Fatal lock manager error: invalid lock id (158048), errno: 22
  --Invalid argument
 
  attempts to do subsequent level 1 backups produced:
 
  unsuccessful metadata update
  -Database is already in the physical backup mode
  Failure: Database error
  [
  PROBLEM ON begin backup.
  SQLCODE:-607
  ]
 
  I've never seen anything like this in my earlier testing, can anyone
  tell me what happened (firebird.log has nothing at these times)
 
 

 [Non-text portions of this message have been removed]

  





[Non-text portions of this message have been removed]





++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu.  Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com 

++
Yahoo! Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

* To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

* To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: [firebird-support] nbackup failure - cause?

[Alexey Kovyazin]

Hello,

Unfortunately, I can't say more without thorough investigation.
It can be bug or corruption or misconfiguration.

Regards,
Alexey Kovyazin

 the level 0 backup restores ok and gbak will then backup  restore that,
 could the corruption be somewhere that that doesn't matter?
 how can I find and deal with it?

 On 1 November 2011 09:47, Nick Upsonnick.up...@gmail.com  wrote:

 sorry, didn't think to say, its version 2.1.4


 On 31 October 2011 17:21, Alexey Kovyazina...@ib-aid.com  wrote:

 **


 Hello Nick,

 It seems like you have database corruption.
 What is Firebird version?

 Regards,
 Alexey Kovyazin
 IBSurgeon (www.ib-aid.com)


 Hi,

 I have recently started using nbackup and have a system where, at the
 end of an attempt to do a level 0 I got

 Fatal lock manager error: invalid lock id (158048), errno: 22
 --Invalid argument

 attempts to do subsequent level 1 backups produced:

 unsuccessful metadata update
 -Database is already in the physical backup mode
 Failure: Database error
 [
 PROBLEM ON begin backup.
 SQLCODE:-607
 ]

 I've never seen anything like this in my earlier testing, can anyone
 tell me what happened (firebird.log has nothing at these times)


 [Non-text portions of this message have been removed]





 [Non-text portions of this message have been removed]



 

 ++

 Visit http://www.firebirdsql.org and click the Resources item
 on the main (top) menu.  Try Knowledgebase and FAQ links !

 Also search the knowledgebases at http://www.ibphoenix.com

 ++
 Yahoo! Groups Links









++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu.  Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com 

++
Yahoo! Groups Links

* To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

* To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

* To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: [firebird-support] nbackup failure - cause?

[Alexey Kovyazin]

Hello Nick,

It seems like you have database corruption.
What is Firebird version?

Regards,
Alexey Kovyazin
IBSurgeon (www.ib-aid.com)


 Hi,

 I have recently started using nbackup and have a system where, at the
 end of an attempt to do a level 0 I got

 Fatal lock manager error: invalid lock id (158048), errno: 22
 --Invalid argument

 attempts to do subsequent level 1 backups produced:

 unsuccessful metadata update
 -Database is already in the physical backup mode
 Failure: Database error
 [
 PROBLEM ON begin backup.
 SQLCODE:-607
 ]

 I've never seen anything like this in my earlier testing, can anyone
 tell me what happened (firebird.log has nothing at these times)

 



[Non-text portions of this message have been removed]