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?
> -----Original Message-----
> From: Chris Withers [mailto:[EMAIL PROTECTED]]
> 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 :-)
> Zope maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )