# Why is fdbrestore restoring data so slowly?

**URL:** <https://forums.foundationdb.org/t/why-is-fdbrestore-restoring-data-so-slowly/4668>\
**Category:** Using FoundationDB\
**Created:** [October 21, 2024, 7:26am UTC](https://forums.foundationdb.org/t/why-is-fdbrestore-restoring-data-so-slowly/4668 "2024-10-21T07:26:32Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![1412904892](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/1412904892/32/1869_2.png) [@1412904892](https://forums.foundationdb.org/u/1412904892)\
**Post date:** [October 21, 2024, 7:26am UTC](https://forums.foundationdb.org/t/why-is-fdbrestore-restoring-data-so-slowly/4668/1 "2024-10-21T07:26:32Z")

</div>

Our project finally decided to use fdb as metadata storage. When verifying the backup and recovery, we found that the data recovery was very slow.

 ![image](https://global.discourse-cdn.com/foundationdb/original/2X/c/c108adffe9247f4ca1b69d75408b068fd686d3c8.png)

The recovery task lasted about 10 minutes.  
restore cluster

fdb\> status

Using cluster file `/etc/foundationdb/fdb.cluster’.

Configuration:  
Redundancy mode - triple  
Storage engine - memory-2  
Encryption at-rest - disabled  
Coordinators - 3  
Usable Regions - 1

Cluster:  
FoundationDB processes - 6  
Zones - 5  
Machines - 5  
Memory availability - 7.2 GB per process on machine with least available  
Retransmissions rate - 1 Hz  
Fault Tolerance - 1 machines  
Server time - 10/21/24 15:10:46

---

<div class="post-metadata">

**Author:** ![SteavedHams](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/steavedhams/32/18_2.png) [@SteavedHams](https://forums.foundationdb.org/u/SteavedHams)\
**Post date:** [October 21, 2024, 6:33pm UTC](https://forums.foundationdb.org/t/why-is-fdbrestore-restoring-data-so-slowly/4668/2 "2024-10-21T18:33:04Z")

</div>

Your database is very small and your restore point would need under 1 minutes of mutation logs, so the restore job itself is trivial in size. This means the problem is likely that your `backup_agent` processes were not running consistently, or were not stable, or one or more of them cannot access the backup data.

Restore jobs execute as a bunch of individual “tasks” on the `backup_agent` processes, so if one of them can’t access the backup data it can claim a Task in the database and then fail to read the backup data and retry periodically, eventually failing and releasing ownership of the Task for another `backup_agent` or perhaps itself to claim again later.

A common reason for `backup_agent` processes being unable to access backup data is that you’re using a local filesystem for backup data which is not mounted on all of the hosts where `backup_agent` runs. Given that your screenshot shows backup data in `/tmp`, I would suggest that if you have other hosts running `backup_agent` process they cannot access this path as it only exists on the host you ran the `fdbrestore` client on. Note that `fdbrestore` does not actually do any restore work, it only controls the Restore job states and can create/monitor/abort them.