Just to start by pointing out the bloody obvious: - Restoring from backup means you lose all data between backup date/time and system failure. Sucks, but it beats losing *all* your data. (RAID5 anyone?) - With that in mind, *consistency* of the backup database takes the highest priority. All existing transactions should be fully completed - no half-done updates, etc. It seems to me that the easiest way to get there with ZODB might be to just make a simple file copy of the database and have some kind of integrity checking tool to run against the static backup copy to weed out the junk. Is this possible, does it already exist? Probably a dumb question, but would Zope itself do this if you fired it off against an inconsistent ZODB? Another random thought is that if ZODB transactions and writes are atomic, than none of this should be an issue. Anyone know the answer to that one? -cw-
-----Original Message----- From: Chris Withers [mailto:chrisw@nipltd.com] Sent: Thursday, June 29, 2000 7:49 AM To: Erik Enge Cc: Oleg Broytmann; Zope Mailing List Subject: [Zope] Backing Up Zope (was: Re: [Zope] Data.fs.lock?)
Erik Enge wrote:
On Thu, 29 Jun 2000, Chris Withers wrote:
Hmm, about extending this so you have 'rotating data.fs
files' in the
same way you have rotating log files?
In general, yes :-). Do you think it would be solving the right problem the right way?
I think so, but that's only my view.
If anyone's got any better ideas, please pipe up :-)
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )