Toby Dickenson wrote:
On Monday 02 June 2003 12:48, Peter Sabaini wrote:
Toby Dickenson wrote:
On Monday 02 June 2003 10:18, Peter Sabaini wrote:
Think of backup as a database operation - this script has no ACID.
please explain -- why would i need transactions and concurrency with a backup script?
Suppose this morning (Monday) the machine locks up (or power failure, or network loss if this is on a network mount, etc) immediately after this backup script has terminated. Some, but not all of the changes to /archive/monday/data.fs will have been written to disk, and some will have been lost. There is every chance that todays backup has been mashed together with the backup from last weeks monday in some arbitrarily confusing way. There is no new backup, and the old backup has been destroyed.
Sure, if this happens only once then this script leaves you with six other good daily copies. But during a disaster recovery is the worst possible time to have to be thinking about which "backup" directory contains a data.fs that has recently been destroyed by a non-transactional backup script. Sean Upton talks about disaster-prepardness here: http://zope.nipltd.com/public/lists/zope-archive.nsf/AGByKey/6036CE8DFC2D348...
This "bug" can be fixed for FileStorage backup scripts, check out the link I posted earlier. The cost is in performance.
i see. i guess it mainly depends on how write-heavy your zope application is. but if this is okay for you i'd like to put up the script you linked to as a comment as soon as the book is online. [snip] - peter.