couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: recovering data from an unfinished compaction db
Date Sat, 22 Sep 2012 12:49:16 GMT
Yup, CouchDB starts from the end of the file and looks backwards until
it finds a valid footer, it can take some time if that's a long way
from the end. It's not so much that CouchDB is skipping over "random
binary data", it just doesn't have any pointers to that area of the

How long as couchdb been seeking backward for a footer? When you say
"doesn't recognize it", are you getting an error message?


On 22 September 2012 13:46, Rudi Benkovič <> wrote:
> CouchDB doesn't recognize it. It's probably corrupted because the
> partition ran out of free space during compaction itself. Does CouchDB
> try to find a valid root node by reading the DB file from the tail and
> skipping over "random" binary data? In that case I might just have to
> let it run for some time before it finds it.
> --Rudi
> On Sat, Sep 22, 2012 at 2:40 PM, Robert Newson <> wrote:
>> The compacted file is a valid couchdb database, it should not be
>> "corrupted", simply rename it to .couch.
>> Obviously you will have lost any data that didn't make it over to the
>> .compact file from the original .couch file that you have mistakenly
>> deleted.
>> B.
>> On 22 September 2012 10:56, Rudi Benkovič <> wrote:
>>> Hi,
>>> I have a .couch file where compaction hasn't finished its job and
>>> we've lost the pre-compaction production DB file (an unfortunate
>>> sysadmin error). Running CouchDB 1.2.0, so the new, corrupted file is
>>> in disk format version 6, with snappy compression.
>>> I've tried using recover-couchdb
>>> (, but it crashes with the
>>> message that disk format 6 isn't supported. I've also tried dropping
>>> in 1.2.0 sources, but that also didn't work.
>>> Anyway, any hints on how to recover the data? 180GB file, lots of attachments.
>>> Many thanks!
>>> --Rudi

View raw message