|Subject||RE: [Firebird-Architect] Re: Some enhancements to NBackup to allow backups more often|
> I'm talking here about the creating of a (classic) server process andOpening the files and allocating disk space is an insignificant cost
> the log on it since the NBackup is a user, not mainly about the cost
> of creating the NBackup process. Also if the NBackup is already
> running, on a next iteration the difference file is already opened
> with the disk space allocated already (if the code closes it and
> frees the allocated disk space, I think that's easy to change that)
> in order to gain speed.
when talking about a backup.
Further, it is necessary for NBackup to close the files upon completion,
after all how could you backup the backups?
I don't think that NBackup suffers from performance problems.
In our testing, we found that databases with a reasonable number of
changed pages, that NBackup generated the backup file faster than most
disk I/O systems are able to process, so NBackup is limited by the
hardware not by it's design.
> And also, the previous scanned results can beWhat would happen to the cache if the server was restarted?
> cached in order to not scan again each header. But the last one is
> only a presumtion since I didn't see the code.
Further, NBackup was designed to support multiple levels of backups, so
the engine would need to track changes for all backup levels.
Additionally, there has been a feature request to allow for multiple
backup 'sets' to be support. This feature would allow for a developer
to take backups at arbitrary points (Set #2) while not affecting the
production backup cycle (hourly, daily, weekly...) (Set #2)
Can NBackup be improved? Like any product, always! But within a
realistic context of the appropriate functionality.