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

GHOST Chain
1

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.

validator screenshot
validator screenshot1882×1001 62.7 KB

4 Likes
2

Have you tried this quick guide I put together?

2 Likes
3

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: :ghost:).

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.

3 Likes
4

image
image1306×492 16.5 KB

image
image1413×733 50.2 KB

1 Like
5

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:

image
image1418×654 37.5 KB

1 Like
6

Bump it ? Bump it real good. if your node is not stopped, has peers and synching but not caught up to current blocks there is relatively new function to Bump EVM Blocks in the Ghost Eye blog. enter validator tab and highlight the network (Sepolia, Hoodi, Mordor) and then Shift + 0 and enter in the “block height” some number within 10 higher than the current block finalizing. The blog says to set to higher but slightly behind also works. That said, given the timing of this message, you probably need to check your RPC on Mordor per VoidDragon.