# Backup & restore performance tuning **URL:** \ **Category:** Using FoundationDB\ **Tags:** performance\ **Created:** [April 18, 2020, 6:43am UTC](https://forums.foundationdb.org/t/backup-restore-performance-tuning/2078 "2020-04-18T06:43:29Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [May 5, 2020, 9:08pm UTC](https://forums.foundationdb.org/t/backup-restore-performance-tuning/2078/14 "2020-05-05T21:08:43Z")
Backup agents are all stateless workers, that coordinate using the database to grab smaller tasks as part of the overall backup. If a backup agent dies, then the work it was assigned will eventually be picked up and completed by some other backup agent. > [@Throughput of a Queue/Set like data structure](https://forums.foundationdb.org/t/throughput-of-a-queue-set-like-data-structure/205/6): > > Our backup and DR are implemented as clients of the database. We wrote a task bucket abstraction on top of the database to prevent different workers from doing the same work. You might be interested in looking at how we implemented that to give you some ideas for what you are planning. has links to both the TaskBucket implementation in FDB that’s used to coordinate backup agent work, and the next post down has a link to something similar, but written in python (and smaller, clearer, and probably easier to quickly grok). This is also all changing in 6.3, and there will be a new backup implementation available that uses a different sort of worker, that instead recruited and managed as part of the cluster. You can read more about that in the [design doc](https://github.com/apple/foundationdb/blob/master/design/backup_v2_partitioned_logs.md). --- _[View the full topic](https://forums.foundationdb.org/t/backup-restore-performance-tuning/2078)._