Backup and Restore - Validator Restore Completed — But Node Not Syncing (From/To Blocks Stuck at 0)

[StarkProtocol]

Hello everyone,

I recently performed a full validator restore using the official Ghost backup/restore process and wanted to report an issue I’m encountering afterward.

Guide followed:
https://blog.ghostchain.io/ghost-eye-startup-guide/#BackupRestore

---

What I Did

I followed the documented procedure closely:

1. Created backups of the required Ghost directories (wallets/session keys/etc.)

2. Reformatted the laptop

3. Reinstalled:

   • Ghost node

   • Ghost-Eye

4. Restored from the backup per the guide

After restoration:

• Wallets restored correctly

• Session keys initially appeared correct

• Node starts normally

---

The Problem

Since the restore:

• From Block and To Block for both Sepolia and Mordor remain stuck at 0

• They are not progressing at all

• As of this morning, all session keys are now crossed out

---

What Looks Normal

• journalctl -f -u ghost-node shows peers connecting

• No obvious errors in logs

• Node appears in telemetry

• Service runs without crashing

So the node appears alive but is clearly not syncing or participating correctly.

---

What I’m Trying to Determine

I’m trying to understand:

• Did I miss a step during restore?

• Could permissions or ownership changes cause this?

• Is there an additional step required after restore that isn’t obvious from the guide?

---

Additional Notes

I did have to manually run ownership/permission fixes after restore:

sudo chown -R ghost:ghost /var/lib/ghost/chains/<CHAIN_NAME>/keystore
sudo chown ghost:ghost /etc/ghost/stash-key
chown -R $(whoami):$(whoami) ~/.local/share/ghost-eye

Not sure if that’s related or just normal hygiene.

---

Ask

Has anyone seen:

• From/To blocks stuck at 0 after restore?

• Session keys becoming crossed out post-restore?

• A node that has peers + telemetry but doesn’t advance blocks?

Any guidance or things to check next would be hugely appreciated.

Thanks in advance.

[Cosmos]

Have you tried this quick guide I put together?

CASPER TestNet Validator Node Stopped being a Validator

[image] My Validator Node stopped being a validating and became a Full Node. The Staking status changed from Active to Rotating. The team alluded to the fact that since there is a limit of 20 Validators at the moment, your node can lose validating status if it has the LEAST bonded amount. I increased my bond from 7 $CSPR to 17 $CSPR and Reset the Commission. This should bump me up in the hierarchy of validators. Just have to wait 1 era to see if it worked …

[VoidDragon]

It looks like the issue isn’t related to backup and restore (or any session key management). The problem occurs when trying to connect to RPC endpoints. To check endpoints from the same machine, use the helper script:

# inside ghost-node directory

# if you are using public endpoints
./scripts/rpc-tester.sh
# if you are using custom rpc
./scripts/rpc-tester.sh --rpcs https://url-to-your-rpc-node.org,https://another-url-comma-separated.com

# the output should look something like this:
----------------------------------------------------------------------------
| Endpoint                                     | Block        | Events     |
----------------------------------------------------------------------------
| https://sepolia.drpc.org                     | 10368208     | YES        |
| https://sepolia.gateway.tenderly.co          | 10368208     | YES        |
| https://api.zan.top/eth-sepolia              | 10368208     | YES        |
| https://rpc.sepolia.ethpandaops.io           | 10368208     | YES        |
| https://ethereum-sepolia-rpc.publicnode.com  | 10368208     | NO         |
| https://1rpc.io/sepolia                      | 10368208     | YES        |
| https://0xrpc.io/sep                         | 10368208     | YES        |
| https://eth-sepolia.api.onfinality.io/public | 10368208     | YES        |
----------------------------------------------------------------------------
---------------------------------------------------------------------
| Endpoint                              | Block        | Events     |
---------------------------------------------------------------------
| https://0xrpc.io/mordor               | 15661874     | YES        |
| https://geth-mordor.etc-network.info  | 15661874     | YES        |
| https://rpc.mordor.etccooperative.org | 15661874     | YES        |
---------------------------------------------------------------------

Columns meaning:

• latest block number - should return a non-zero value without errors. You can use Etherscan or Blockscout as a reference for comparison.
• ability to get events - this is critically important. It indicates whether the endpoint supports event extraction. By default, this feature is enabled, but some RPC node operators may disable it to conserve resources.

If possible, please share a screenshot of your journalctl -f -u ghost-node output. The node itself and the slow clap module have very detailed logging, especially lines that start with the ghost emoji (like this one: ).

P.S. Based on your previous screenshots, the restore process completed successfully, so there’s no need to worry about session keys.

P.P.S. For some reason default ghost emoji is overriden with ghost logo here. Link to the original ghost emoji here.

[StarkProtocol]

[StarkProtocol]

thanks for the response. I’ve attached 2 screenshot to this topic, I hope it helps. Do you want more logs from the journalctl -f-u ghost-node output?

I’m still seeing 0 to and from blocks on both sepoila and mordor: