Subject Re: [IB-Architect] Backups of large database & super transactions
Author Markus Kemper
Jason et al,

From what I can gather on this thread and from similar problems
with customers I've worked with, the main problem seems to be
the following issues:

a) CPU consumption and halting of garbage collection by the
backup process. The larger the database the longer this
necessary action takes.

b) The length of time it takes to restore a large database
from scratch takes longer and longer as the size of the
database increases.

I would like to see us come up with a solution that does not
involve inhibiting garbage collection while at the same time
deecreases the amount of time to "backup" the necessary data
to allow for a timely disaster recovery.

Perhaps we might brainstorm about solutions that do not
involve the current backup and restore mechanisms (GBAK.exe).

I've always liked the idea of using replication to solve this
problem. Where on a scheduled basis one would replicate (sync)
the production data to a stand-by (backup) database.

Perhaps we need something more sophisticated like a different
backup file format and a staged database restore mechanism.

For example:

a) backup data based on a key stored either in data or
internally in the record structure to a backup file.

b) restore the database but, do not apply constraints and
triggers. Or restore them but, inactive.

c) backup as needed somehow the volitile or newly changed

d) when disaster strikes, restore (sync) the most recent
(new or changed) data file to the backup database and
apply constraints and triggers and bring the system up.


I would however rather see us focus on improving InterBase's
already awesome ability to recover immediately from a
disaster so as to avoid the need for a full backup and
restore all together. InterBase was designed for recovery
in mind. Maybe we can improve on the mechanisms already in
place (not meaning gbak) and resolve the need for additional
backup mechisms or maybe we'll discover that there is a
significant need for such an ability and design it to solve
the problem at hand.

I think that if we can eliminate the need for "incrimental
backups" with better recovery abilities, the hardest part
will be explaining/proving to others why it is not necessary
to have such routines (necessary with other vendors) with