Subject Re: [IBO] Backup and restore of a database
Author Anthony Ison
> First - you will get more help on the basic IB/FB stuff on
> ib-support

Thanks, I have just forwarded a copy of the original there.

> gbak will produce a clean copy of all comitted records even
> if users are connected. What will be missing is any work
> started after gbak started. There should be NO corruptions.

That is true, and I trust gbak to do this. I need to guarantee that the
system is not going at this time to ensure no data is lost if the backup and
restore turns sour...

> > 3. Copy db1.gdb to db1.gdb.bak
> > 4. Copy db2.gdb to db1.gdb
> No way these will work, unless there are NO connections to
> the files.

That's the part I'm not sure of... I couldn't do this in Windows explorer,
but I'm pretty sure I did this last night on a client site with 5 other
connections.... (hence db1.gdb and db2.gdb were corrupt....)

> Since switching to IBO, I don't think we have resorted to a
> restore. Backup happens every night, and is copied to a
> slave machine, following a sweep of the main database, and
> we only restore if there has been a problem - which has not
> happened for a while. Weekly maintenance restores a backup
> to check integrity, but that copy is not used.
> Upgrades are a slightly different matter. We always create a
> new blank database, and pump the data from the old one, then
> just start using the new one.

I have not looked into Sweeps a whole lot yet... Are they a better solution
to db maintenance than a backup and restore? Are there any differences in
what the final outcome is?

Our upgrades involve a bunch of sql to reconstruct their current database
into the shape we want it... As such, it's a good idea to backup and
restore after this... I think our insert triggers would tear us apart if we
tried to pump to a new db...