Ledger Recovery

Ledger Recovery complements a standardised Corda network operational backup and recovery process. Its function is to re-instate a Corda database from the point of a consistent backup. It is not intended to be used to recover a partially corrupt database, for example, where records may be missing from a subset of tables. The Ledger Recovery process utilises new recovery distribution records in conjunction with the atomicity semantics of recording Corda transactions. The process encompasses recording the transaction to the node_transactions table, updating the vault states tables and, optionally, updating any other custom contract state tables associated with the transaction.

Ledger Recovery builds on the foundations established in Two Phase Finality, where recovery metadata is stored for transactions at both the sender’s and receiver’s side of a transaction flow.

For any given transaction, the sender’s side stores one or more SenderDistribution records in its local sender_distribution_records database table. There is one SenderDistribution record for each receiver peer of a transaction. Receiver peers include any participants and/or observers to the transaction.

A SenderDistribution record contains the following transaction metadata:

  • Transaction ID
  • Receiver peer ID (the secure hashed value of CordaX500Name using SHA256)
  • Receiver StatesToRecord value

Upon storing the SenderDistribution records for a transaction, the sender node also generates a single ReceiverDistribution record. A ReceiverDistribution record contains the following transaction metadata:

  • Transaction ID
  • Sender peer ID (the secure hashed value of CordaX500Name using SHA256)
  • A distribution list comprised of two sections:
    • An AES-encrypted map of the peer IDs of all receiving peers for the transaction and their associated StatesToRecord value.
    • A tamper-proof cleartext senderRecordedTimestamp, indicating when the sender records were generated. Corda uses the same upon storing the ReceiverDistribution record at each of the receiving node peers. This is required to enable synchronized record comparisons across peers when performing transaction recovery.

The generated ReceiverDistribution record is shared with all receiving peer sessions (both participants and observers) to the transaction, which stores it in their local receiver_distribution_records database table.

Both sender’s and receiver’s distribution records use the same composite key type for uniquely storing records. The PersistentKey contains the following fields:

  • Transaction ID
  • PartyId of flow peer (the secure hashed value of CordaX500Name using SHA256)
  • Timestamp (Instant)
  • Timestamp discriminator (Int) The timestamp discriminator allows for storing of records generated at the same time even for the same transaction.

The sender’s and receiver’s distribution records are subsequently used to enable Ledger Recovery.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.