On Mon, Oct 19, 2009 at 12:37 PM, Alex P <[email protected]> wrote: > i'll take a peek tonight, but it just doesn't sound like corruption. the db > is visible, readable, writable, just has an update sequence of 0, 0 docs and > a db size (as reported by futon) of 4.0kb. > > is db size computed off the file size, or based on actual contents? because > if it's the file size, it really doesn't sound like corruption... >
I think it just reports the file size. So if the SAN-restore only brought back 4kb, then there's something to investigate. It could be that the SAN inserted a few bytes randomly in the file, so CouchDB couldn't find a btree root at the position indicated by the header. Which version of CouchDB are you using? I think it's worth diffing the before-restore and after-restore files. If the after-restore is really only 4kb then of course CouchDB isn't seeing docs in it. > (fwiw this is a separate, yet similar issue from the one i had earlier with > data disappearing from a live system) > > On Mon, Oct 19, 2009 at 2:35 PM, Alex P <[email protected]> wrote: > >> cdb catalogs databases purely on file name and presence in the appropriate >> directory, right? so if i copy db1 to db1_copy, i should see db1_copy show >> up in futon? >> >> >> On Mon, Oct 19, 2009 at 2:23 PM, Paul Davis >> <[email protected]>wrote: >> >>> On Mon, Oct 19, 2009 at 3:18 PM, Alex P <[email protected]> wrote: >>> > hello, >>> > >>> > we ran into an issue this weekend where taking a SAN (amazon ebs) >>> snapshot >>> > of a couchdb mount somehow brought over only part of the data. >>> specifically, >>> > there were two small dbs (call them db1 and db2) on the couch instance, >>> each >>> > with several hundred documents. taking the snapshot and bringing it up >>> again >>> > showed both databases, but one had 0 documents and an update sequence of >>> 0. >>> > the instance the snapshot was taken from still has both databases >>> showing >>> > with several hundred databases. we repeated this process several times, >>> with >>> > the same effect, on the same db. >>> > >>> > any thoughts would be much appreciated, as we are about to go live, and >>> not >>> > being able to do a backup of our db is ... disturbing. >>> > >>> > thanks, >>> > alex. >>> > >>> >>> Alex, >>> >>> That's most odd. What happens if you try and cp the database file to a >>> new name? Something like: >>> >>> $ cp /usr/local/var/lib/couchdb/db1.couch >>> /usr/local/var/lib/couchdb/db3.couch >>> >>> Another thing to try would be: >>> >>> $ curl -X POST http://127.0.0.1:5984/db1/_ensure_full_commit >>> >>> And then try to snapshot or copy again. I highly doubt that POST would >>> affect anything, but it might be worth a shot. >>> >>> Paul Davis >>> >> >> > -- Chris Anderson http://jchrisa.net http://couch.io
