On Sun, Jun 2, 2013 at 7:06 PM, sir_wally_lewis <rgilland1966@...>wrote:

>
>
> I have in the past also put forward a database level suggestion by
> enhancements to "gbak"
>
> The suggestion is:
>
> 1. gbak run with two new options to "-xbackup op.fbk" "-xrestore op2.fdb"
> 2. this option backups up to op.fbk.
> 3. Also server keeps a separate file for new changes to database during
> process.
> 4. server then restores op2.fdb and at the end attaches all new changes to
> op2.fdb.
> 5. shuts down live database and replaces it.
>
> I think it can be done.
>

That's one of the challenges that caused nbackup to be created. As you
know, gbak
restore creates new, empty database, then creates most of the metadata for
the database,
then loads the data from the backup file, then finishes metadata. The
metadata is split
to avoid problems with foreign key and other constraints during the data
load phase.
That means that all the simple ways to identify tables and records (i.e.
table and record
ids) change. I'm not convinced that you can replay a series of inserts,
updates, and
deletes and guarantee that the results will be the same as the original.

Yes, I know that's how MySQL does replication - it keeps a statement log
and applies
it at the remote site. I spent considerable time trying to make that work
with MVCC -
and was never convinced that it was right there either. Yes, it can be
made to work if
the database and applications are designed to work from a statement log,
but if that
feature were to be part of gbak, it would have to work every time with any
database.

My advice to those who want a backup that's up to the minute is to use
nbackup.
Use gbak for archival storage and to avoid major headaches like running out
of
transaction ids. However, if you have a critical site and need
reliability, replicate.

Good luck,

Ann
IBPhoenix, your source for Firebird support


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