Hi Göran, the fault tolerance was designed from the ground up to handle a sudden power outage. Specifically, under the assumption that writes to the various db files could be partially completed to any point in time, but a common point in time between all files.

This is a different situation than copying on-line files because the copy could take some time, even spanning multiple flushes (which are, by default, every 5 seconds). The former is a much easier scenario to consider because, in the latter, the partially-written state of each file is from a different time than all the other files.

I certainly would not risk it. You should close the DB files before doing a backup.

I have sketched out a plan for replication where on-line backup is a nice side-effect. But that might be a while so, until then, I would definitely bring down the DB to do a backup.

- Chris

--- goran@krampe.se wrote:

Hi Chris and all!

Ok, we are getting closer to first test deployment of our app for a few user groups and (since we may experience problems, like db corruption (heaven forbid) or simply bugs in the app causing havoc) I want to make extra sure that I have a good approach regarding backups.

Am I correct that since we now have fault tolerance I could essentially just copy the db files to get a backup of the db - even though it will not be transactionally correct? I mean - I can lose the ongoing txns, but the copy should otherwise be able to recover and work, right?

Or do I need to make a shutdown in order to make sure I get a "proper" backup?

regards, Göran _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma