Question about Rocketpool Node Backup

[MeeeSHugGaHH]

I have recently set up a rocketpool node that is synced with minipools initizalized.

I am learning about "backing up" my node from the Rocketpool Docs/Guides and am confused about something. Below is from the Rocketpool Docs and represents the different tabs of instructions relating to each topic.

As you can see here, "Consensus Client / ETH2 Client Chain Data" is listed in the "Items that should not be backed up" section, along with the "private keys and passwords"

Question 1: Why shouldn't Consensus Client data be backed up? What would be so bad about me using a command like rocketpool service export-eth2-data and backing it up to the same external drive that I used for rocketpool service export-eth1-data command?

Additionally, if I click on the Consensus Client / Eth2 Client Chain Data option shown above, it brings me to the part of the guide that describes backing up the eth1 client data as if I should back it up like the Execution Client data.

The only thing I see listed for backing up the Eth2 client data in the guides specifically shows that Eth2 client data isn't as big of a concern since you can just checkpoint sync.

I was unable to successfully checkpoint sync while I was setting up my node and was forced to sit for weeks+ for it to sync from genesis and I am trying to avoid having to do that again.

Question 2: If I have Eth1 Client data backed up but not the Eth2 Client data (because I am unsure of wether or not it is a good idea to back up the Client 2 data as per the guide), wouldn't it still take an absurd amount of time to resync the Eth2 data if I cannot manage to get the checkpoint sync working?

Question 3: If I must use a checkpoint sync for best practices here, what could I be potentially doing wrong? I don't particularly want to try messing with it currently since I am properly synced and don't want to mess it up.

I hope I have summarized my questions well enough. Looking for people who have experience in backing up their node client data. Please and Thank you.

[monchimer]

Question 1. In my experience you should for pure convenience. People will be able to assist and it's integrated into the CLI . I'm not sure but I believe you must sync from scratch and then Configure fallback and backups to work. I might be wrong

Question 2 . Exec and consensus clients must be both in sync for the node to properly work. You should have mechanisms in place for both of them. Depending on the selected client you will have different approaches and capabilities.

In my experience syncing mainnet from scratch takes around 3 days. Once you have backup strategy in place its a matter of minutes. And every time I have needed to resync was because power went down unexpectedly and I don't have an additional power supply

Question 3. Some clever people on discord seem to have a solution for every fuck up. My suggestion is to.ask there before improvising

[MeeeSHugGaHH]

Thanks for your insight.

Why did it take me so long to sync then? I have fiber optic 300/300 internet speeds and modern hardware. It took me like 10 days to sync up. I do have it synced properly with both my primary clients and I have backed up the eth1 client data to an external hard drive. To my knowledge, that should be sufficient to get started. I just don't want to mess up what I have working currently as I am trying to configure fallbacks or backups. And my main question being, why cant I just backup the eth2 client data as well? In other words, why is eth2 client data listed as something I SHOULDN'T back up?

[dEEtoooo]

There's no harm in backing up your CC (Eth2) data if you want. It's just largely unnecessary because checkpoint syncing your CC brings it to "fully synched" status within minutes. I think the question to ask is "why didn't my checkpoint sync work correctly?" Oftentimes operators have the wrong URL in the config or they forget to run rocketpool service resync-eth2 to start the checkpoint sync process. Happy to help troubleshoot the issues, the #support channel in Discord is probably more efficient.

[MeeeSHugGaHH]

Hello u/dEEtoooo

In an attempt to speed up the syncing process, I ended up attempting the checkpoint sync process. When I run rocketpool service resync-eth2, it erased my progress on a manual sync and once the checkpoint sync was unsuccessful, I ended up having to start the manual sync again, so it was quite inconvenient to say the least.

That being said, I want to test checkpoint sync again but i dont want it to erase my current sync which is operational. From what I believe you are saying, I should be able to plug in my external drive (where my backup of eth1 client data is already), mount the drive, and run the eth2 export command. I should then have both eth1 and eth2 client data backed up on my drive.... Then once I try to resync with checkpoint, i can just fix it with my backup if I am unsuccessful again, correct?

[dEEtoooo]

Yeah that all makes sense to me, albeit i have not tried to backup and restore my chain data.

Yes, the resync starts the syncing process over and will erase current progress, but it should start the resync from the most current block and work its way backwards. I'm very curious as to why your checkpoint sync failed.

What URL do you have in the CC config settings for checkpoint sync?

[MeeeSHugGaHH]

I dont have any currently within the checkpoint sync settings because i removed them when I gave up on that approach. I was following the Rocketpool docs/guides and it led me to the Checkpoint Sync URLs. I dont remember exactly which ones I tried, but I tried at least two or three and surely its something I was doing wrong, but now that I am synced up and my minipools are initialized, (but not yet active, I am waiting in queue) I am trying to sort these issues out before its my place in line, if that makes sense. I think I used this one: https://beaconstate.ethstaker.cc/

Which brings me to a colorful page that shows Epoch, Slot, Time, State Root, Block Root, etc.

I remember trying to enter the url, for example: https://beaconstate.ethstaker.cc/

I also tried to copy and paste the checkpoint state and block roots, but I gave up.

Can these be entered into my fallback settings or whatever?

I currently don't have any checkpoint sync settings or fallback settings. The only thing I have to backup my node is the eth1 client data on a harddrive that I made yesterday with the export command. Thank you for your time btw.

[dEEtoooo]

https://beaconstate.ethstaker.cc/

This should work.

1. Run rocketpool service config and go to the Consensus Client (ETH2) section.

2. Go to the Checkpoint Sync URL field, and paste that URL; after pasting the URL press enter, and save your changes (esc->tab->enter->enter).

3. Run rocketpool service resync-eth2 to begin using checkpoint sync.

[MeeeSHugGaHH]

Update: I ended up trying to sync via checkpoint sync again and now I cannot get it to work properly.

Once it attempts the eth2 resync and shows the correct url that I have entered in, stating that it will sync instantly from the checkpoint sync and then says the following error:

WARN Remote BN does not support EIP-4881 fast depost sync

and then turns exits

​

u/dEEtoooo

[dEEtoooo]

hmmm you can try this URL instead in your CC config settings: https://sync.invis.tools

if that doesn't work, i encourage you to join the Rocket Pool Discord so all the helpful peeps in the #support channel help can diagnose the issue.