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

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

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.