On Don, 2013-12-05 at 15:42 +1000, Tom Cameron wrote:
> My main aim is to work out what happened. My best guess is that Zope
> was somehow connecting to a stale or outdated file pointer and
> updating that file all along while the Data.fs was pointing to an
> August 5 copy. But how could this situation eventuate and persist for
> so long?
for my, it looks exactly like that Zope used an inode, which wasn't the
Data.fs you expected. It used that as long as you restarted Zope. your
backups were always copying the old Data.fs from the filesystem path,
where you expected the correct one to be in.
that happens, when the directory with your Data.fs is moved
(e.g. $ mv ./var ./var-bak)
and a new one copied back to the old place
(e.g. $ cp -R ./var-bak ./var).
that happens also, when the Data.fs is deleted.
there are chances, that the correct Data.fs is still somewhere around
(except when it was deleted, then a data recovery service might be able
just a wild guess: did your backup script screw this up?
> The odd thing is that we had 2 very similar incidents on 2 different
> Zope servers a few months ago but both resulted in almost no data loss
> as the timeframes were shorter and I dismissed them as some odd user
> We have recently moved most of our Zope servers to Linode - could it
> be their file system? or could it be the new way we setup the
> buildouts and init scripts?
> Any clues at all would be welcomed.
> Tom Cameron
> Technical Director
> Mooball IT
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-dev )
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -