Quote from: BrokenTractor on November 13, 2024, 06:07:47 PM

Quote from: MegatronOHMICAVT on November 13, 2024, 03:51:05 PM

Quote from: eagleye on November 03, 2024, 02:41:25 AM

You need to format the new 2TB drive with the format command in settings. Don't format your old data drive. Just to make sure all is good. I did that with my new drive. Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive. takes about 45 mins. then shutdown, swap and reboot and it should work fine. THat's my experience. Keep the 1TB as a backup. That's what I have.

I did the reindex-chainstate , took longer. I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate. Also lack of ram slows the process. Seems to actually be quicker to start an IBD after a formatted drive and it is quicker. However, I highly recommend a backup like above. Once my IBD was complete I copied the drive for a backup. I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download. That made recovery quicker in future crashes. My hardest part was the IBD. Once done my system is now running much better.

I have low trust in the reliability of the included microsd card. The original is possibly a much older 16GB microsd. I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find. I flashed it and find it more stable than the included card was.

A follow up question about doing IBD and overcoming what seems to be too much stress for the RAM & processor.

I've got a backup NVME with about the first-half of the IBD on it. I would like to see if there's advice on the procedures for starting a node (Apollo BTC installing 2.0.5) by using the backed-up blockchain data.

Its a 2TB NVME drive in the node, with a 1TB NVME connected via USB and a flashed micro SD to install the system.

Questions are things like which folders need to go over and in what order should steps be taken from initial boot. Thank you!

/blocks & /chainstate
OK I haven’t done this before but I have been reading about copying the Bitcoin Core blockchain to another system and this is what I plan to do when I receive my Apollo II later this week.
I have a fully synched v22 Bitcoin Core node running on an Ubuntu PC that I’ve been playing with and I will copy it over to the new 2 TB SSD to avoid re-downloading the entire blockchain again, which might take me a week.
Bitcoin is installed on my Ubuntu PC in the home directory in the hidden folder .bitcoin. There are three subfolders within .bitcoin, /blocks, /chainstate & /wallets.
/blocks is 699.6 GB
/chainstate is 12.5 GB
I will not be moving over the /wallets folder or the individual files in the .bitcoin folder, files like bitcoin.conf mempool.dat, peers.dat... These are specific to that PC install and I believe the ones on the Apollo II system will already be in place or will be created on statrtup.
So basically I am moving over just two folders under the .bitcoin folder, /blocks & /chainstate. That’s it.
Here’s what I plan to do when I receive the system.
Connect a monitor, keyboard and mouse. Power on and log into the Apollo system with minimum configurations settings. Stop the miner and node if they are running. Use a file manager on the desktop to make sure the file structure is the same on the SSD, “cd /media/nvme/bitcoin” to look for the blocks and chainstate folders. If they are there then rename them to oldblocks and oldchainstate just to save them for now. Shutdown the system, remove the SSD and put on a USB/pcie adapter into my Ubuntu PC. I will put a fan blowing on the SSD during this copy as this will probably be the most work this SSD will ever experience, copying 700+ GB to it in one go. Obviously the Bitcoin Core node will not be running on my PC to ensure the files are all closed properly. After a successful copy, shutdown the PC, move the SSD back over to the Apollo II system and power it on and complete the setup.

I think it will work. Maybe someone else can chime in if this process looks reasonable or if I’ve left something out. Hope this helps. Good luck mining...

Sounds good and some say that should work, but the con to this is you have a duplicate blockchain from another node. Each node creates its own database set. The theory is copies can create risk of exposure to bad actors. But from your own device should be ok. Now, with the new copy of the database is the Node a different bitcoin node address or does it take on the same node address when copying that data?

Using a USB to pcie, I don't think the memory card will overheat as your limited to USB 3.0 speeds which is less than the actual memory card speeds. No overheat here. 200mbps read/write through usb 3.0

directories in your linux raspberry pi is main bitcoin directory media/pcie/Bitcoin. The usb drive is media/futurebit. I am very careful when opening windows and copying files on the node. I look at file properties to make sure I'm pointed to the right drive.

I just had a chainstate file get corrupted, chainstate file xxxxxx is corrupt. possible system crash. Tried to recover it. multiple node restarts failed. reindex-chainstate=1. That will delete all chainstate files on restart and rebuild the chainstate from start. Bitcoin database stays intact. I find the database blockchain files seem to be ok and no errors detected. This process takes too long and My Node can't seem to cleanly rebuild it with anything else running such as the miner or open browser windows. It seems to crash more. If it crashes and you have the reindex-chainstate=1 set it will start from scratch every time. have to delete this setting before any node restart after chainstate files have been deleted. bitcoin will reindex chainstate files on restart even with this setting turned off.

So, what I did, which is quicker is take my backup nvme card and delete the chainstate files on the node that have a corrupt file and reinstall only the chainstate backup files to the node nvme. On restart chainstate files are rebuilt from missing 3 weeks.

Yes, I didn't have the miner or node runnng. Took a few hours to rebuild the missing chainstate from 3 weeks ago. Now back to normal. Node running ok and time to backup the files to todays date. about a 45 to 60 minute time. Carefully delete the usb nvme files and copy a fresh set.

How I can tell is when I shut down the node I look for a clean exit in the debug.log. If there is a chainstate error it shows there.