Backup and Restore
Backup
Architecture
On Fabric Console, you can back up any resource: peers, orderers, CAs, MSPs, and the system-channel genesis block.
You can decide to back up resources either on-demand or by scheduling a periodic backup. You can also specify how many backups to retain — once the threshold is reached, the backup operator automatically purges older versions.
The backup CRD has the following specs:
1 — Resource: Definition of the resource to back up. Examples:
peers.peerset.hyperledger.fabric/p1— peer p1orderers.orderingservice.hyperledger.fabric/o1— orderer o1fabriccas.ca.hyperledger.fabric/ca1— fabric-ca ca1configmaps/msp1— msp msp1
2 — Schedule: Defines how often the backup process is carried out. Can be skipped for a one-time on-demand backup.
3 — Retention: Defines how many backup versions to retain. Only applicable for scheduled backups, as on-demand backups store a single version.
Backup Process Flow
How Does It Work?
The UI prompts you to select the resource to back up, the scheduling policy, and the retention count. The backup operator then:
Scheduled backups repeat this process at the defined interval, storing multiple versions. The operator purges older versions once the retention limit is crossed.
Restore
Once a backup is created, you can restore a resource to a particular backup version.
Architecture
Unlike the backup process, restore does not have an operator but uses the Fabric Console APIs. From the Fabric Console UI, choose which resource to restore, select the backup and the version, and the resource is recreated (or deleted and restored to the requested version).
Future Scope
Complete system backup — Requires ordering of restore, similar to backing up a peer when it uses CouchDB.
Templating a restore process — Will help launch predefined networks easily.
Last updated
Was this helpful?