# Restore operation very slow and causes huge network traffic

**URL:** https://forum.duplicati.com/t/restore-operation-very-slow-and-causes-huge-network-traffic/21984
**Category:** Support
**Created:** [February 17, 2026, 9:55am UTC](https://forum.duplicati.com/t/restore-operation-very-slow-and-causes-huge-network-traffic/21984 "2026-02-17T09:55:55Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)
#### Post date: [February 18, 2026, 5:29pm UTC](https://forum.duplicati.com/t/restore-operation-very-slow-and-causes-huge-network-traffic/21984/4 "2026-02-18T17:29:45Z")

</div>

> [@hbl2bk](#):
>
> Unfortunately this option didn’t have a significant impact.

Your opening sounded like you saw slowdown on 2.2.0.3. Or was this first test?

> [@hbl2bk](#):
>
> This means that Duplicati must be downloading the same data again and again and again.

This was your early conclusion (and the new restore can do that), but then you discovered another theory in the manual, related to how volume sizing matters.

Now we have to try to determine what’s going on, and you’ve started on testing.

> [@hbl2bk](#):
>
> Therefore I reduced the volume size from 50 MB to 20 MB, but this also had no significant impact.

You can’t do this so well after-the-fact, as older larger volumes will stay around.

> [@hbl2bk](#):
>
> Finally I reduced the number of snapshots in the backup from 44 to 3, but this also didn’t improve the restore process.

This seems plausible to me. Deleting versions doesn’t directly reduce what the chosen version has to collect, although it can sometimes be helped by compact.

You can look in any backup log to see roughly what the compact did, if anything.

[Retention settings](https://docs.duplicati.com/configuration-and-management/retention-settings)

> After deleting one or more versions, Duplicati will mark any data that can no longer be referenced as waste, and may occasionally choose to run a compact process that deletes unused volumes and creates new volumes with no wasted space.

A side effect of combining still-useful data from many volumes into fewer is that chances increase that the data from several updates could go into one volume.

I would suggest looking at the job log from the backup that reduced snapshots.

Make sure you turned `use-legacy-restore` on. Just a GUI add might not do it.

Logs can also show which way you’re going. `log-file` at even `information` shows all the downloads, so can support or refute the idea of repeating them for caching reasons. The old restore downloads a dblock once and distributes data content as needed. This is described in the [article](https://forum.duplicati.com/t/blog-post-cut-restore-times-by-3-8x-a-deep-dive-into-our-new-restore-flow/20415) on the design of new restore.

About Duplicati → Logs → Live is an easy way to watch restore. Verbose level provides more details. You can also use `log-file` and `log-file-log-level`.

EDIT 1:

Basically, make sure the option doesn’t look like below. This option is turned off:

![image](https://forum.duplicati.com/uploads/default/original/2X/9/944f02b2b8e0ac646a2a7ad1559b10dd99dda9e4.png)

Download 8.5 times the total backup size (and still going) seems unlikely if the legacy restore is actually in use. I could maybe see a smaller multiple of total, because file metadata (such as time stamps) is set using a separate later step.

The developers know the restore design (especially new one) better than I do.

---

_[View the full topic](https://forum.duplicati.com/t/restore-operation-very-slow-and-causes-huge-network-traffic/21984)._