Hi @Maor_Avni , welcome to the forum
Yes, the new method is significantly faster, but it looks like we were too conservative in the size of cache and too simple in the ordering strategy. What is happening is that the same files are downloaded multiple times, in an attempt to limit the amount of temporary disk space used.
The effect is that network traffic increases a lot and restore speed slows.
We have another discussion here where @carljohnsen lists some ideas for improvement:
Hi @aureliandevel ! I’m the author of the reworked restore flow . First of all, thank you for the feedback, it’s very appreciated!
The problem
The problem we’ve been seeing comes as a side effect of the new design, which focuses on increasing parallelism and sequential disk writes. This led to caching strategies in order to keep the individual parts of the pipeline busy as much as possible. This caching further led to an increased amount of temporary disk space being used, which led to the intro…
There is also work on a PR that will address the issues:
master ← aureliandevel:feature/restore-volume-caching-revision
opened 10:49AM - 28 Feb 26 UTC
## Disk-space-aware restore volume cache eviction
### Summary
Previously, … when `--restore-volume-cache-hint` was not set, the restore volume cache defaulted to 100× the volume size (e.g. 5 GB for 50 MB volumes) — an arbitrary limit that could be far too large or far too small depending on the environment. This PR removes that default, making the cache unlimited by default and enabling disk-space-aware LRU eviction bounded by a new `--restore-volume-cache-min-free` option.
### Behaviour changes
| Scenario | Before | After |
|---|---|---|
| `--restore-volume-cache-hint` not set | Hint at `VolumeSize × 100` bytes | Unlimited; evicts LRU when temp dir free space drops below `--restore-volume-cache-min-free` |
| `--restore-volume-cache-hint 0` | Caching disabled | Unchanged |
| `--restore-volume-cache-hint <size>` | Hint at `<size>` | Unchanged |
### New option
**`--restore-volume-cache-min-free`** (default: `1gb`)
Minimum free disk space to maintain in the temp directory during restore. When the unlimited cache mode is active, LRU eviction triggers whenever available free space drops below this value. A bare number is interpreted as gigabytes. Has no effect when `--restore-volume-cache-hint` is set to a specific size or to `0`.
### Implementation details
- `RestoreVolumeCacheHint` now returns `-1` when unset (sentinel for "unlimited"), cleanly separating unlimited (`< 0`), disabled (`0`), and hinted (`> 0`) modes.
- `VolumeManager` extends the existing cache insertion block to a three-way branch. The unlimited branch queries `DriveInfo.AvailableFreeSpace` on the temp directory on each volume arrival and evicts LRU entries until free space recovers. The volume is then cached unconditionally (it is already on disk; disposing it would not help).
- If a volume has to be re-downloaded after being evicted due to disk pressure, it is counted in `CachePressureRedownloads`.
### Observability
Two new warnings (emitted at most once each per restore operation):
- **`CachePressure`** — emitted after the 5th disk-pressure eviction: _"Restore volume cache has begun evicting cached volumes due to low disk space in '{tempDir}'. Restore performance may be degraded."_
- **`CacheExhausted`** — emitted if the cache is entirely empty but free space is still below the minimum: _"Restore volume cache is empty but disk space in '{tempDir}' is still below the configured minimum. Performance impact is likely."_
Three new fields on `RestoreResults` (omitted from all output when zero via `ShouldSerialize*()`):
- `CachePressureEvictions` — total LRU evictions triggered by disk pressure
- `CachePressureRedownloads` — volumes re-downloaded after disk-pressure eviction
- `TotalVolumesAccessed` — distinct dblock volumes accessed during the restore
The counters and warnings may seem like overkill for typical restore usage — most emergency restores prioritise completion over speed, and disk pressure is unlikely when restoring small datasets. They are primarily aimed at users and automated pipelines that regularly validate their backups and need to know whether volume caching is working efficiently or silently degrading performance. The zero-suppression design (`ShouldSerialize*()`) means these fields cost nothing in the common case and provide actionable signal when it matters.
### Files changed
- `Duplicati/Library/Main/Options.cs` — new constant, updated `RestoreVolumeCacheHint` fallback, new `RestoreVolumeCacheMinFree` property and `SupportedCommands` entry
- `Duplicati/Library/Main/Strings.cs` — updated `RestoreVolumeCacheHintLong`, new `RestoreVolumeCacheMinFreeShort`/`Long`
- `Duplicati/Library/Main/Operation/Restore/VolumeManager.cs` — three-way cache branch, disk-pressure eviction loop, warning logic, result counter writes
- `Duplicati/Library/Main/ResultClasses.cs` — three new properties on `RestoreResults` with `ShouldSerialize*()` zero-suppression
- `Duplicati/UnitTest/OptionsTests.cs` — three new unit tests for the new option properties
- `Duplicati/UnitTest/RestoreHandlerTests.cs` — `null` added to `RestoreVolumeCache` parameterised values; new `RestoreVolumeCacheDiskPressure` integration test
Related to #6752, #6744