# Need recovery advice after 2.3.0.0 issue: recreate found 36 broken filelists, purge dry-run fails

**URL:** https://forum.duplicati.com/t/need-recovery-advice-after-2-3-0-0-issue-recreate-found-36-broken-filelists-purge-dry-run-fails/22492
**Category:** Uncategorized
**Created:** [June 12, 2026, 5:06am UTC](https://forum.duplicati.com/t/need-recovery-advice-after-2-3-0-0-issue-recreate-found-36-broken-filelists-purge-dry-run-fails/22492 "2026-06-12T05:06:07Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![adamlove](https://forum.duplicati.com/user_avatar/forum.duplicati.com/adamlove/32/7857_2.png) [@adamlove](https://forum.duplicati.com/u/adamlove)
#### Post date: [September 15, 2026, 10:25am UTC](https://forum.duplicati.com/t/need-recovery-advice-after-2-3-0-0-issue-recreate-found-36-broken-filelists-purge-dry-run-fails/22492/3 "2026-09-15T10:25:59Z")

</div>

## Update: I eventually recovered the backup

Despite the radio silence, I wanted to close the loop because this thread has now helped another user experiencing the same SQLite memory problem.

The immediate memory workaround was:

`CUSTOMSQLITEOPTIONS_DUPLICATI=temp_store=FILE`

Without that setting, Duplicati’s repair validation caused `Duplicati.CommandLine.exe` to consume around 66–68 GB of virtual memory. I reproduced this on two different Windows computers. With SQLite temporary storage moved to disk, the heavy repair operation completed without exhausting memory.

Recovering the backup still required considerably more work:

- Several full database recreates, each taking multiple days.
- Identifying 36 damaged restore points containing broken filelists.
- Archiving and then deleting those 36 affected versions.
- Fixing one dangling `BlocksetEntry` relationship that made 37,054 empty files appear to have a 1 MiB block.
- Running database consistency checks, remote tests and representative restores.
- Comparing a restored file against its original SHA-256 hash.
- Finally completing a real backup on 20 June 2026.

The repository was ultimately made usable again, but this was not a normal or realistically supportable recovery process for most users.

This issue is relevant again because another user has now reported repeated OOM failures during delete/cleanup and database rebuild. They tried the same `temp_store=FILE` workaround and went from 16 OOM kills to zero:

[Release 2.4.0.0 discussion and independent reproduction](https://forum.duplicati.com/t/release-2-4-0-0-stable-2026-09-03/22653/19)

The maintainer’s response indicates that this likely involves a runaway SQLite query and may be related to the newer SQLite package.

I still think two improvements are particularly important for large repositories:

1. Resumable database recreate, so a failure after several days does not require starting again.
2. Safer SQLite temporary-storage behaviour for large databases, instead of allowing a maintenance query to exhaust all available memory.

I have retained extensive logs and database-analysis notes if they would help turn this into a reproducible issue.

---

_[View the full topic](https://forum.duplicati.com/t/need-recovery-advice-after-2-3-0-0-issue-recreate-found-36-broken-filelists-purge-dry-run-fails/22492)._