On Don, 2013-12-05 at 15:42 +1000, Tom Cameron wrote:
Questions 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 to help). just a wild guess: did your backup script screw this up? best, johannes
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 error.
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 https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )