Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-3364

Add ledger backup/restore to Operations Guide



    • Documentation
    • Status: Closed
    • Medium
    • Resolution: Done
    • None
    • v2.0.0
    • fabric-docs, fabric-ledger
    • None


      Ledger backup
      It is not required to backup the ledger data of a peer. This is because, even in the worst case of catastrophic failure of a peer (e.g, a disk failure) , the peer can be brought up with no ledger at all. You can then have the peer re-join the desired channels and as a result, the peer will automatically create a ledger for each of the channels and will start receiving the blocks from genesis block on, via regular block transfer mechanism from other peers in the channel. As the peer processes blocks, it will build up it's state database.

      Still, some organizations may want to be more self-reliant and hence may want to take backup of their ledger data so as to be able to recover from catastrophic failures and resume block processing from the point of the last backup. In addition, ledger data backups may help to expedite the addition of a new peer, which can be achieved by backing up the ledger data from one peer and starting the new peer with the backed up ledger data.

      In order to back up the ledger data of a peer, perform the following steps.

      1. Stop the peer
      2. 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`.

      In the step 2 above, some of the sub-folders under `<peer.fileSystemPath>`/ledgersData can be skipped while backing up the ledger data.
      These sub-folders include `stateLeveldb`, `historyLeveldb`, `chains/index`. Skipping these folders reduces the storage demand for the backup however, at the same time, the peer recovery from the backed up data may take more time, as these ledger artifacts will be re-constructed when the peer starts if they are found to be missing.

      if using CouchDB as state database, there will be no stateLeveldb directory, as the state database data would stored within CouchDB instead.  But similarly, if peer starts up and finds CouchDB databases are missing or at lower block height (based on using an older CouchDB backup), the state database will be automatically re-constructed to catch up to current block height.  Therefore, if you backup peer ledger data and CouchDB data separately, ensure that the CouchDB backup is always older than the peer backup.

      In order to restore the ledger data to a fresh peer, perform the following steps.

      1. Copy the backed-up folders to the new peer's `<peer.fileSystemPath>` directory.
      2. Start the peer

      Note - additional details provided in google doc for handling private data in later releases:
      I'd suggest community docs include offline backup information.


        Issue Links



              joe-alewine Joe Alewine
              denyeart David Enyeart
              2 Vote for this issue
              17 Start watching this issue