Attempting to restoring a seed/admin node from a backup results in unspent output error.

Question

I am currently running a private MultiChain P2P network with a single seeder node (the first node) and multiple miner nodes on Amazon’s AWS platform. I'm not using data streams or native assets. I’m trying to implement a backup and restore process for the seeder node.

Currently I have a cron job that shuts the seeder node down via:

multichain-cli  \

    -rpcport=8332 \

    -rpcuser=“redacted” \

    -rpcpassword=“redacted” \

    -datadir=/mnt/multichain/data/mychain \

    mychain stop

I then backup the entire filesystem /mnt/multichain that the chain is stored by taking an EBS snapshot.

I then start the chain backup via

multichaind mychain \

    -rpcallowip=redacted \

    -rpcport=8332 \

    -port=8333 \

    -rpcuser=redacted \

    -rpcpassword=redacted \

    -datadir=/mnt/multichain/data/mychain

Everything seems to work ok.

The issue is when I tear down my network and attempt to restore from the backup. The seeder is booted first and appears to launch correctly.  All of the blocks from the backup are present in the restore. However:

A. The seeder repeatedly attempts reconnect to it’s old peers. The new miners have new IP addresses so it cannot.

B. When the seeder attempts to grant connect,send,receive for each of the new miners the error: “No unspent output with admin permission” is received and the miner is not allowed to join the chain.

So with that, I have two questions:

1. Is there a way to remove old peers from a nodes peer list? I looks like I can do this manually, but I’m hoping that there is a “forget all” type command to aid in automation.

2. Any ideas on why I’m receiving the unspent output error?

Answer 1

1. There isn't yet a "forget all" command for peers, but you shouldn't worry about it too much - eventually the node will give up on the old peers once it has no success connecting to them. But we'll note this as a feature to add in future.

2. If you're using a version of MultiChain earlier than the latest one (alpha 26), the unspent output error might be misleading, so you should upgrade to get the real error message. But if you are on the latest one, it is presumably exactly what it says – the node's wallet does not contain the private key for any addresses which (a) have admin permissions, and (b) have some unspent outputs in the blockchain. You can use the commands getaddresses, listpermissions and listunspent to diagnose and verify this – please update us here.

Comments

After digging into this, I was able to determine that after the restore, the wallet does indeed have no unspent outputs. However when attempting to send a transaction to the address with admin permissions, I would repeatedly receive a "no response from server" error.

After playing around I discovered that if I restart the restored server with the option -reindex=1 that the issue is corrected and the restore behaves correctly.

Even though it works, I'm not sure this approach is the best way to perform a backup/restore. Any advice on how to perform a backup/restore would be greatly appreciated.

---

Are you stopping the node before backing up the directory?

Also please let us know if -rescan=1 works as well as -reindex=1.

---

I am stopping the node before the backup. As per your suggestion, I also tried -rescan=1. The rescan option provides better results. I've switched to this solution. Thanks.