> > "...
> > However, any data changes that
> > clients commit to the database after the backup begins are not
> > recorded in the backup
> > file.
> > ...
> > "
>
> Martijn Tonies wrote:
> " Well, that's a GOOD thing. How would a backup be a backup of
> a particular point in time, if changes happened AFTER the backup
> has started would be recorded?
> "
>
> Some backup methods allow to restore database to a particular point in

time

> which is not neccesserally a time when backup started but can be a later
> timestamp instead. This is basically about maintaining a sequential

change

> log and it's backup which can be used to roll-forward a database after it

is

> restored from a main backup. The point is that change log is split into
> rather small files and those files can be backuped as they are created.
>
> Then to restore a database one needs to restore it from a main backup and
> then roll-forward using backuped change logs:
> - it takes time to roll-forward of course
> - but one can restore database up to the last available change log file -

if

> log files are not too large then one loses as much data as fits into one

log

> file.
>
> Basically this is about availability which can be achieved by other means

as

> well, e.g. by replication.

I know all this. But Firebird doesn't have a (transaction) log or another
way
to do an incremental backup.

However, what does this has to do with the original statement?

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com