# Use of BR - Considerations

__*Using BR*__
__*BR Considerations*__

+ Recommended to run on nodes with 8-core CPU and 16GB or more of memory
+ Perform backup operations during periods of low business
+ Recovering to a production cluster that is serving is not recommended
+ Multiple BR backup and recover tasks running in parallel is not recommended
+ By default, BR performs data verification after backup and recover are completed
  + Turn off verification during backup (—checksum=false), and only enable verification on recover
+ It is recommended to use a storage system that supports the S3/GCS/Azure Blob Storage protocol to store backup data

-------------------------------------------------------------
Suggestions for use
Here are some recommendations for using BR for backup recover:
Recommend backup operations during peak business hours to minimize business impact;
BR only supports restoring data to a new cluster, and uses as much of the resources of the recover cluster as possible. It is not recommended to perform a recover to a production cluster that is providing services, as this will have an inevitable impact on business during recover;
Running multiple BR backup and recover tasks in parallel is not recommended. Parallelism of different tasks not only leads to poor performance of backup or recover, which affects online services; it also causes tasks to fail due to lack of coordination between tasks, and even affects the state of the cluster;
It is recommended to use a storage system that supports the S3/GCS/Azure Blob Storage protocol to store backup data;
Ensure that the BR, TiKV node, and backup storage system have sufficient network bandwidth, and that the backup storage system can provide adequate write/read performance; otherwise, they may become performance bottlenecks during backup recover;
By default, BR performs a round of data verification after the backup and recover are completed, and the checksum of the backup data is compared with the results of the cluster admin checksum table to ensure correctness. However, the admin checksum table takes a long time to execute and has a big impact on cluster performance. Depending on your situation, you can choose to turn off the verification during backup (—checksum=false), and only enable the verification during recover.