Bitcoin Core 26.0 Crash on Macbook - Error opening block database.

[Mebits3]

Hello all,

Is there any way of recovering the block database without downloading the entire thing from scratch?

My Macbook crashed for some reason and now Bitcoin Core comes up with the error: "Error opening block database. Do you want to rebuild the block database now?"

I continued but it has started verifying all block from the beginning.

I am running the node from an external drive if that's important. I wonder if the computer crashed because of a memory or related issue due to the external hard drive setup.

Thanks

Steve

[achow101]

What version of MacOS are you using? Possibly the same issue as https://github.com/bitcoin/bitcoin/issues/28552

Is there any way of recovering the block database without downloading the entire thing from scratch?

Rebuilding the block database doesn't redownload anything. It is reading all of the blocks from disk and building the block index, so the software gives the same progress bar as syncing, but no downloading happens until it reaches the end of what's on disk.

[Mebits3]

Thanks, I'm still using Ventura 13.6.

However, my drive is ExFAT (and the article suggests it should be APFS), so maybe that is the issue?

Okay, So I'll just let Bitcoin Core continue processing the headers, and then hopefully it will retain most of whats already on disk?

S

[Mebits3]

After syncing the headers it has just started downloading all blocks from the beginning

Could it not be recognising the blocks folder at all if it seen as corrupt?

[achow101]

After syncing the headers it has just started downloading all blocks from the beginning

Could it not be recognising the blocks folder at all if it seen as corrupt?

Why do you assume that it is downloading all blocks? When it is reindexing, it will say something about syncing, but there won't be any network activity. You should be able to disable networking (either OS, or in Bitcoin Core) and it will still continue to be "downloading".

[alecfisker]

Hello all,
Is there any way of recovering the block database without downloading the entire thing from scratch?
My Macbook crashed for some reason and now Bitcoin Core comes up with the error: "Error opening block database. Do you want to rebuild the block database now?"
I continued but it has started verifying all block from the beginning.
I am running the node from an external drive if that's important. I wonder if the computer crashed because of a memory or related issue due to the external hard drive setup.
Thanks
Steve

post hardware profile, crash log, could be free memory related
does system have swap file enabled

[Mebits3]

Okay so I left it to continue "indexing files on Disk" and it did sort out the block database without downloading everything again. I would say it is worth noting that it may seem like this should be a quick process, however it still took many hours so I needed to be more patient. It didn't however take many days as the case when first downloading the blockchain.

I'm not sure if swap file is enabled but I haven't changed anything from default on that front.

Maybe if it crashes again it might be worth looking into?

Thanks for the help guys

S

[satscraper]

Okay so I left it to continue "indexing files on Disk" and it did sort out the block database without downloading everything again. I would say it is worth noting that it may seem like this should be a quick process, however it still took many hours so I needed to be more patient. It didn't however take many days as the case when first downloading the blockchain.

I'm not sure if swap file is enabled but I haven't changed anything from default on that front.

Maybe if it crashes again it might be worth looking into?

Thanks for the help guys

S

The speed of reindexing depends on the size of dbcash. Taken  dbcash=1/4 RAM as a  rule of thumb  I would advocate dbcash=4096 (for 16 GB RAM).

Some times reindex-chainstate  (and even reindex which is more slower process then reindex-chainstate ) doesn't help to restore corrupted database. I faced it just a few days ago when attempting to recover blockchain data  somehow corrupted in the course of  copying them from my other SSD. Had to do it all over again and the second attempt at copying was a success.

[nc50lc]

Some times reindex-chainstate  (and even reindex which is more slower process then reindex-chainstate ) doesn't help to restore corrupted database. I faced it just a few days ago when attempting to recover blockchain data  somehow corrupted in the course of  copying them from my other SSD. Had to do it all over again and the second attempt at copying was a success.

That depends on the which database is corrupted;
if it's just the UTXO set, the fast --reindex-chainstate should be enough.
if it's the block index or the blockchain, then --reindex-chainstate wont be useful in that case.

Perhaps the "corrupted copy" had a different issue,
this is why checking the debug.log for errors should be the first step before applying those command line options.

The speed of reindexing depends on the size of dbcash.

May be a typo because it should be dbcache.

[satscraper]

The speed of reindexing depends on the size of dbcash.

May be a typo because it should be dbcache.

Sure dbcache rather than dbcash.

Fault of my brain which thinks all time think of the lack of cash.

Some times reindex-chainstate  (and even reindex which is more slower process then reindex-chainstate ) doesn't help to restore corrupted database. I faced it just a few days ago when attempting to recover blockchain data  somehow corrupted in the course of  copying them from my other SSD. Had to do it all over again and the second attempt at copying was a success.

That depends on the which database is corrupted;
if it's just the UTXO set, the fast --reindex-chainstate should be enough.
if it's the block index or the blockchain, then --reindex-chainstate wont be useful in that case.
Perhaps the "corrupted copy" had a different issue,
this is why checking the debug.log for errors should be the first step before applying those command line options.

Yeah, forgot to look inside debug.log and, thus,  proceeded with the second copy attempt.  

However the time I have spent for the full-blockchain- coping (involved two fast SSDs) was far less than time of reindexing.

Thus, I'm not upset.

[NotATether]

The thing I get from this is that it is is largely a macOS issue. Specifically with Sonoma where Apple said the implementations of MS filesystems have changed substantially.

Why these changes would crash an application doing lots of I/O is not clear to me at the moment.

Okay so I left it to continue "indexing files on Disk" and it did sort out the block database without downloading everything again. I would say it is worth noting that it may seem like this should be a quick process, however it still took many hours so I needed to be more patient. It didn't however take many days as the case when first downloading the blockchain.

I'm not sure if swap file is enabled but I haven't changed anything from default on that front.

Maybe if it crashes again it might be worth looking into?

Thanks for the help guys

S

Maybe if you find that Bitcoin Core is causing the Mac to use lots of swap, it could escalate the risk of some I/O fault happening to Core again. But I wouldn't disable it unless the machine only runs Bitcoin Core.