|Re: [ib-support] Backup and restore of a database
> You shouldn't be using any sort of file copy on a database where theserver
> is running. Just doing *this* will not just produce a corrupt copy, itI knew this in theory, now I know for sure! :-)
> will also potentially corrupt the database file which you are copying,
> because file copy utilities lock sectors of the physical disk, which could
> contain structures that open transactions are writing to, have uncommitted
> record versions in, etc.
> Did you realise that gbak is NOT a file copy utility?Yep.
> On your questions in later messages, there is nothing *wrong* with doing aSo I do get more from a backup and restore than from a simple sweep? Does a
> gbak backup and a gbak restore once a week if you need to. Performance
> will tell you how often you need to resort to this type of hygiene.
sweep reset the metadata change ids? That is, can you make 250 metadata
changes, do a sweep and then do another 250? Apparently, 255 is the max
changes before a backup and restore is required.
> Restore the gbk file using gbak -c to a *different* place on yourI would prefer not having to shutdown the server if it can be avoided....
> filesystem. Connect to it to verify that all is OK; then disconnect and
> then shut down the server.
> Don't rename database files to ".gbk" because, for sure, someone will tryYeah, I've been using .gdb.bak for that reason - otherwise I'd probably be
> to use it as the source of a gbak -c and think it's corrupt because it
> can't be restored-from.
the numbskull trying to restore it...