> I'm talking here about the creating of a (classic) server process and
> 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.

Opening the files and allocating disk space is an insignificant cost
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 be
> cached in order to not scan again each header. But the last one is
> only a presumtion since I didn't see the code.

What would happen to the cache if the server was restarted?

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.


Sean