Arto Bendiken wrote:
As for the present problem, from further analysis what I suspect to be the reason those sub-DBs each contain their lone keys is that those three keys (one in each sub-DB) are the defaults inserted when the program initializes a new LMDB file to write to. Those three keys are inserted if the database is believed to be empty, i.e., if it has zero entries.
So possibly the post-reboot state of the DB file looked empty to LMDB, either for the main DB or for the three sub-DBs, and the program then proceeded to insert and commit those default keys. That's more plausible than a resurrection of the exact initial state (from months ago) where the original pages would indeed be long gone, as you noted.
I don't suppose there is much hope of finding the previous B+tree root(s) in the .mdb file and attempting to recover data from any still-reachable leaves?
If as you suspect, these 3 entries are present because they were automatically reinserted, then no, you're not likely to be able to recover anything. If the DB file had not been modified from it's actual crashed state, it would have been possible to access the previous transaction's meta page which would very likely have pointed to complete intact data. But when you wrote to the DB, you overwrote the previous meta page.