> You shouldn't be using any sort of file copy on a database where the

server

> is running. Just doing *this* will not just produce a corrupt copy, it
> 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.

I knew this in theory, now I know for sure! :-)

> Did you realise that gbak is NOT a file copy utility?

Yep.

> On your questions in later messages, there is nothing *wrong* with doing 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.

So I do get more from a backup and restore than from a simple sweep? Does a
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 your
> filesystem. Connect to it to verify that all is OK; then disconnect and
> then shut down the server.

I would prefer not having to shutdown the server if it can be avoided....

> Don't rename database files to ".gbk" because, for sure, someone will try
> to use it as the source of a gbak -c and think it's corrupt because it
> can't be restored-from.

Yeah, I've been using .gdb.bak for that reason - otherwise I'd probably be
the numbskull trying to restore it...