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 file.
How long as couchdb been seeking backward for a footer? When you say "doesn't recognize it", are you getting an error message? B. On 22 September 2012 13:46, Rudi Benkovič <[email protected]> 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 <[email protected]> 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č <[email protected]> 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 >>> (https://github.com/jhs/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
