On Sun, Jun 2, 2013 at 7:06 PM, sir_wally_lewis <rgilland1...@gmail.com>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]
