As a best practice, backups of Replica and Client nodes must be regularly scheduled or performed on an ad-hoc basis.
These backups are useful during the following scenarios:
Copying data to a production support environment for triaging issues
Copying data to a non-functional environment for regression testing or performance-related testing
Support for disaster recovery and failure scenarios
For audit purposes to keep copies from previous days, weeks, or months.
The Replica and Client node backups are independent processes configured separately and at different times and intervals. See Back-Up Replica Nodes on vSphere or Back-Up Client Node on vSphere.
Replica Node Backup and Restore Considerations
Complete Replica node backup should be performed at least twice a day, before the daily pruning schedule and after pruning has been completed. This backup is performed while the system is wedged. The pre-pruning backup is a safety measure to safeguard the blockchain from data corruption, although it might occur only in rare cases. The post-pruning backup can be used to restore failed Replica nodes.
The complete Replica node backup can take a considerable amount of time. Therefore to minimize the time the blockchain node is wedged, you can perform incremental backups during the day. While the incremental backup is running, the blockchain is fully operational. Setting up incremental backups reduces the time for the full Replica node backup because the remaining data that must be backed up is considerably smaller than backing up all the blockchain data from scratch. The full and incremental backups schedule is configurable.
The Replica node backup should be performed on at least one Replica node in each data center to avoid copying backups across the network between data centers.
As a best practice, it is recommended to back up every Replica node on the Replica Network so that it can be restored from its data in case of failure.
A system operator can use a backup to restore a faulty Replica node under the following considerations:
The backup was performed after the last pruning operation.
Full backup was performed while the system was wedged, or backup was taken from a Replica node, which was down while the backup process was running.
Client Node Backup and Restore Considerations
The Client node backup schedule is configurable. The Client node backup should be performed from one Client node in each Client node group in a data center. The backup is performed per data center to avoid copying backups across the network between the data centers. Since each physical instance of a logical group or Client node group is the same, it must back up one of the physical instances for the Client node group. The Client node backup mechanism is fast. Therefore every time the backup is initiated, a full Client node backup is performed.
Client node backup should be performed at least twice a day, before the daily pruning schedule and after pruning has been completed. The Client node backup is performed while the Client node is up and running. Client node backup does not require the Client node to be stopped or taken down. The pre-pruning backup is a safety measure to safeguard data corruption, although it might occur only in rare cases. The post-pruning backup can be used to restore failed Client nodes.
A system administrator can use a backup to restore a faulty Client node under the following considerations:
The backup was performed after the last pruning operation.
The Client node state must be restored to a time before the current state of the blockchain.
