Back up and Recovery Best Practices

Question

Hello ,

We are researching as to how do we take a multichain based solution mainstream . We wanted your view on the backup and recovery design or best practices for a multichain based solution. Pertinent questions will be :

1.What kind of back up process should be enabled for a multichain system : daily , incremental , change log based?

2.Will multichain provide api/utilities to initiate , automate and control the back up process

3.What kind of restoration will be supported - point in time , till last daily backup ...etc

4.Will multichain provide api/utilities to initiate , automate and control the restore process

5.How to create a high available system with multiple replica of the multichain , for the application to failover to any of the instance of multichain

Looking forward to views from you side .

Thanks

Answer 1

Thanks for the detailed questions:

1. I would suggest an incremental backup process because the majority of the data on disk (the blockchain itself) will not change once it is written.

2. We do not yet have utilities for this but this issue is on our roadmap. In the meantime the basic process would be: (a) stop (via the API) the node, (b) back up the blockchain directory that is in .multichaind, (c) restart the node using multichaind. To keep your application functioning during this process, see below for details about managing node redundancy.

3. and 4. have similar answers to 2 - we don't yet have utilities for this. But for now your basic process would be to restore via the file system, while the node is not running. All state is stored in the blockchain directory.

5. Yes, blockchains by their nature are designed for replication and failover. Each node in a blockchain has a full copy of the chain and all nodes automatically synchronize with each other.

If you want multiple nodes to act as exact replicas in terms of funds they hold and other transactions they sign, the one issue will be if you store private keys in MultiChain's internal wallet (rather than externally which is also an option). In that case you can use APIs like dumpprivkey and importprivkey to transfer keys between nodes and ensure they are working to the same key set.

Depending on how you set up your keys, you might also have to consider the chance of double-spends between your replica nodes, i.e. if they control the same assets though the same keys, and you tell more than one simultaneously to send some of those assets elsewhere, they might inadvertently perform a double-spend against each other by using the same inputs. You can resolve this by either manually controlling which inputs are used by which nodes, or else by always sending API calls to one node, and on failover waiting a couple of seconds before starting to send API calls to a different node. That would give the other node enough time to receive any incoming transactions that have been broadcast by the first, to ensure that it doesn't try to use the same inputs.