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