AW: [firebird-support] NBackup Levels
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.) Regards, Steffen [Non-text portions of this message have been removed]
AW: [firebird-support] NBackup Levels
Hi > There is no formal limit, ... Is there a negative effect on too many levels? (Slowdown or database storage overhead?) Regards, Steffen
AW: [firebird-support] NBackup Levels
Hi > > 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. But as far as I understand, the database has to track which page changes since which backup. So keeping that information for more bcakups will (in the worst case) require N*M space (with N being the number of levels and M being the number of pages). Where is the fault in that logic? Regards, Steffen [Non-text portions of this message have been removed]
AW: [firebird-support] NBackup Levels
Hi > 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. >From a quick search, I suspect that will be the "pag_scn" 4 byte value. 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. The advantage above nbackup would simply be that I could control the way the information is merged and stored on the server better and that I could use that information to update different clients at different times (with no common base). 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... > NBackup physically reads each page header to determine if the page "version" > has changed since the last backup. Does NBackup do any other magic than that? Regards, Steffen [Non-text portions of this message have been removed]
