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
Bitcoin Core 26.0 Crash on Macbook Block Database Recovery Issue
9 replies 144 views
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.
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]
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".
SilentOracleMember
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
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
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.
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.
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.
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.
Related topics
- issues with bitcoin core database read error 2
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Ways to earn some sats by contributing to bitcoin core development 5
- What can I do to fix this Bitcoin Core error? 8
- How do you protect your Bitcoin Core wallet? 19
- Curious about the 'Services' section in the peers of Bitcoin Core 6