Backup and restore
Backup
Architecture
On fabric-console, you can backup any resource, that is peers, orderers, CAs, MSPs and the system-channel genesis block.
The user can decide to back up the resources either on-demand or schedule a backup process that will essentially back up a given resource in a periodic way.
The user can also specify how many backups have to be retained and after this threshold is reached the backup operator will purge the older versions of the backup.
The backup CRD has the following specs:
1 - Resource: Definition of the resource, some examples are given below:
-
a) peers.peerset.hyperledger.fabric/p1 (peer p1)
-
b) orderers.orderingservice.hyperledger.fabric/o1 (orderer o1)
-
c) fabriccas.ca.hyperledger.fabric/ca1 (fabric-ca ca1)
-
d) configmaps/msp1 (msp msp1)
2 - Schedule: Defines how often the backup process has to be carried out. This can be skipped if the user wants to have a one-time backup of a resource.
3 - Retention: Defines how many versions of the backup have to be retained. This is only applicable for scheduled backups as on-demand backups store a single version of the resource.
The flow of a backup process is illustrated in the following diagram:
How does it work?
The user will use the UI to create a backup of a given resource, the UI prompts the user to select the resource that has to be backed up, the scheduling policy for the resource to be backed up, that is, how often should the resource be backed up and how many versions of the backup has to be retained before purging.
The backup operator picks up the backup CRD and schedules the backup (or creates a single backup if it is an on-demand backup). The operator backups the resource manifest, any secondary resource that is owned by the particular resource and the parent resources. For example, if you back up a peer that uses couch db, the backup operator backups up the peer manifest and takes a volume snapshot of its PVs, stores the couch db manifest, and the secrets associated with it and also stores the peer set manifest.
Scheduled backups repeat this process in the defined time interval and store multiple versions of the backup. The operator purges older versions once the number of versions has crossed the retention limit.
Restore
Once the backup is created, a user can restore a resource to a particular version of the backup.
Architecture
Unlike the backup process, restore does not have an operator but uses the fabric-console APIs. From the fabric-console UI, the user can choose which resource to restore, select the backup and the version to which he/she wants to restore it.
The resource is then recreated if it does not exist or deleted and restored to the version the user requested.
