[Zope] Re: data.fs corruption

[alan runyan]

I hope you dont mind, but im cc'ing the list-- ppl need to see this

one of the scariest things i can imagine is a customer calling up saying the
entire *monolithic* database is corrupt.  the entire workday would grind to
a halt and someone would have to  jump through lots of hoops to just get the
database (zope filesystem) back in order :((((  this is unacceptable
(period) for some of the uses i had in store for Zope.

is zope going to support multiple databases?  jim f. said the ZODB is a
SPOF -- are there any plans on fixing this?  is there anyway to 'block all
writes' while backing up the ZODB?  w/o taking the entire website
down/mostly reads anyways?

is there a way you can 'scan' to see if the ZODB is intact? i.e. having a
process scan the ZODB and return whether or not it is valid?  what was the
'offending' transaction?

thanks
~alan

----- Original Message -----
From: "M. Adam Kendall" <mak@kha0s.org>
To: "alan runyan" <runyaga@thisbox.com>
Sent: Sunday, February 20, 2000 1:52 AM
Subject: RE: data.fs corruption


> Of course, you probably aren't going to like this answer,
> but I spent about 4.5 hours with the Tranalyzer product,
> and a good hex editor hacking away at my Data.fs.  The good
> news: I recovered all my data.  The bad news: I have alot
> less hair now..
>
> I basically used Tranalyzer to figure out where it blew up,
> and then from the comments in FileStorage.py in the Zope source
> I was able to figure out the file format for the Data.fs.  At
> least I knew how many bytes record/field lengths were supposed
> to be.  Then using the hex editor I manipulated the Data.fs until
> I had ripped out the offending transaction record.
>
> Worked like a charm but was a very long drawn out process..
> I would say that Digital Creations needs to provide a tool
> for easy data recover from corrupt Data.fs.
>
> Adam
>