Bitcoin Core 26.0 Crash on Macbook Block Database Recovery Issue

9 replies 144 views
wizard51Member
Posts: 11 · Reputation: 134
#1Feb 7, 2019, 06:34 PM
Hey everyone, Is there a way to recover the block database without having to redownload everything? My Macbook crashed outta nowhere, and now Bitcoin Core is throwing this error: "Error opening block database. Do you want to rebuild the block database now?" I clicked yes, but now it's going through all the blocks from the start. Just a heads up, I'm running the node from an external drive, so maybe that’s a factor. I’m kinda thinking the crash might’ve been related to a memory issue because of the external setup. Thanks a lot! Steve
4 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#2Feb 8, 2019, 03:49 PM
What version of MacOS are you using? Possibly the same issue as https://github.com/bitcoin/bitcoin/issues/28552 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.
3 Reply Quote Share
wizard51Member
Posts: 11 · Reputation: 134
#3Feb 10, 2019, 12:20 AM
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 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? [moderator's note: consecutive posts merged]
0 Reply Quote Share
ryan_nodeSenior Member
Posts: 204 · Reputation: 859
#4Feb 10, 2019, 02:20 AM
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".
3 Reply Quote Share
Posts: 7 · Reputation: 126
#5Feb 10, 2019, 08:36 AM
post hardware profile, crash log, could be free memory related does system have swap file enabled
3 Reply Quote Share
wizard51Member
Posts: 11 · Reputation: 134
#6Feb 10, 2019, 09:35 AM
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
3 Reply Quote Share
silentchainHero Member
Posts: 473 · Reputation: 2317
#7Feb 10, 2019, 11:27 AM
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.
3 Reply Quote Share
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#8Feb 10, 2019, 05:10 PM
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. May be a typo because it should be dbcache.
5 Reply Quote Share
silentchainHero Member
Posts: 473 · Reputation: 2317
#9Feb 10, 2019, 05:44 PM
Sure dbcache rather than dbcash. Fault of my brain which thinks all time think of the lack of cash. 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.
5 Reply Quote Share
LuckyCoinLegendary
Posts: 832 · Reputation: 4795
#10Feb 10, 2019, 06:52 PM
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. 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.
4 Reply Quote Share

Related topics