couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Data loss in CouchDB 1.0.1
Date Tue, 07 Jun 2011 01:29:30 GMT
I once made a very simple CouchDB undelete tool. It scans your disk
device for anything that looks like the on-disk CouchDB JSON format.

I've recovered data with it, but notably, the _id and _rev are *not*
stored with the rest of a document, so you tend to get lots of docs
with no _id field. (I'm considering always having an "id" field to
dupe the "_id" in case I ever have to do that again.)

On Mon, Jun 6, 2011 at 3:35 PM, René Brüntrup <> wrote:
> Hello!
>> 1) Are you certain that you were in fact writing to the database on this server and
not the replica?  Can you share some access logs towards that end?
> We could not find the missing data in any of the replicated files. Each
> backup has an increasing number of documents with the least amount of
> missing data in the newest backup. Access logs from the 2011-03-08 are
> unfortunately missing, because the log rotation already removed them.
>> 2) Is it possible that you've inadvertently restored the database file from a backup?
> No backup was created at this date and we do not have any mechanisms
> that could automatically restore the backups.
>> 3) Is it possible that you were writing "underneath" the encrypted LVM volume for
the past two months?
> Our system does not work without an initialized database that contains a
> number of user account and definition documents. But even if such an
> initialized database would have been available underneath the encrypted
> volume we would have noticed a data loss after changing the database,
> because the system was already in use before the 2011-03-08.
> We will check again, if there is a database file underneath the
> encrypted volume, but we cannot stop the system right now. When
> replicating the database we just noticed, that the timestamp of the
> source database was updated. The replication processes that where
> started after the 2011-03-08 and before the reboot of the server did not
> change the timestamp of the source database.
> Regards,
> René

Iris Couch

View raw message