Published on

Backing up Hyperledger Fabric

Authors

What Is the Issue?

Hyperledger fabric has a number of concepts like channels and private data built in which are some of the things that make it well suited for corporate B2B applications. The one thing that was not clear is with all these features for example channels where is the data stored as channels only occur between some of the parties involved in a consortium not necessarily all users of that blockchain. As I was not 100% sure how this mechanism worked I wanted to understand how to harden this for corporate applications. Specifically if a participant wants to backup their data without having to rely on other nodes can they?

Why the need for a backup?

There are a number of reasons to do this:

  1. A channel is a separate chain to the chain shared by all participants and it is not too clear how this channel chain's data is stored. On a public blockchain as all data is shared across all participants there is already resilience of the data. But on a permissioned blockchain where there are far less participants and where we further break the chain into channels there is less resilience as less participants have this data.
  2. Fabric has a state DB as part of a node which is used to more quickly query data on the chain. It is valuable being able to backup a node and restore it if you want to quickly respond to failure and if you want to be able to spin up a new node faster (i.e. by restoring it from the backup).

How to backup a Fabric instance?

I tried searching through the official Fabric docs but could not find anything that addressed my concerns about how these channels and state DBs are stored. I also could not find anything on what the backup and restore procedures would be. I did find an open Jira issue about exactly this - the absence of documentation on backing up and restoring a Fabric node. This issue did shed plenty of light on these issues. Channels are a separate chain in Fabric. There are a number of ways of dealing with failures with regards to channels:

  • Rebuild From Another Node: Spin up a new node which has access to the same channels as the failed node. This new node will then rebuild its ledger and state DB for all these channels.
  • Backup and restore the data manually: Backup up the various Fabric folders as outlined in the issue:

Backup the folders <peer.fileSystemPath>/ledgersData and <peer.fileSystemPath>/chaincodes. <peer.fileSystemPath> refers to the value of the property specified in the configuration (core.yaml or overridden in docker with CORE_PEER_FILESYSTEMPATH) - default value of this property is /var/hyperledger/production.

  • If CouchDB is used for for the stateDB then back that up separately to the Fabric data folders but ensure that the CouchDB backup is older than the peer data as Fabric will take the longest chain when running into issues of multiple chains.