Recover missing /content items after restart

[arubi9]

Fixes #304.

/content is a database-backed WebDAV view, not a real media folder on disk. If nzbdav starts after a reboot with /content rows missing from db.sqlite, the files appear to disappear even though the app did not intentionally delete them.

This change adds a guarded recovery path:

• persist a snapshot of the /content subtree and its file metadata under /config
• restore missing /content rows and matching file metadata at startup when the DB is empty or partially missing
• restore linked missing items and required parent directories when the snapshot still has them
• validate snapshots before using them, fall back to a backup copy if the primary snapshot is corrupt, and refuse to overwrite the last known-good snapshot with inconsistent state

Healthy startup behavior is unchanged, and intentional deletes stay deleted because valid post-delete snapshots replace the prior state.

Tests cover:

• full restore when /content starts empty
• metadata-only recovery for existing items
• partial recovery for linked missing items
• unsupported snapshot versions
• corrupt primary snapshot with backup fallback
• preserving the last known-good snapshot when metadata rows disappear
• not restoring intentionally deleted items

Validation:

• dotnet build backend/NzbWebDAV.csproj
• dotnet test backend.Tests/backend.Tests.csproj

This does not recover anything if /config itself is not persistent, because both the DB and the recovery snapshot are gone in that case.

[nzbdav-dev]

If nzbdav starts after a reboot with /content rows missing from db.sqlite

@arubi9, the sqlite database is the source of truth. It's odd that you're seeing rows randomly go missing from the DavItems table after a reboot. We should find the root cause of that, rather than trying to build around it.

What do your volume mappings look like?

[arubi9]

/config is on a persistent host bind mount, not container-local storage. My mapping looks like:

volumes:

• /path/to/nzbdav/config:/config
• /mnt:/mnt

So after a reboot, db.sqlite is still there under /config. This is not the case where the whole DB disappears because /config was ephemeral or unmapped.

What I’m seeing is narrower: the database file survives, and other DB-backed state survives, but some /content rows in DavItems are missing after restart. I agree that the SQLite DB should remain the source of truth, and ideally we should find the root cause for why those rows are disappearing.

The reason I proposed this PR is that the user-facing failure mode is severe: /content appears empty or partially missing even though nzbdav did not intentionally delete that content. The recovery path is meant as a guard against that partial-corruption/partial-loss case, not as a replacement for the DB being the source of truth.

[nzbdav-dev]

Ty for clarifying! Are you able to reproduce the missing rows issue pretty consistently?

I'm wondering if something may be going on with the sqlite write-ahead-log (wal file). If the nzbdav container isn't gracefully shut down, then WAL contents might not get a chance to sync to the main db.sqlite file. However, this shouldn't be a problem as long as the WAL file persists after reboot. It should sync to the main db.sqlite next time nzbdav starts up.

Could the WAL file be getting corrupted? If you're able to reproduce the missing rows issue, could you check whether the WAL file is present in the /config folder both before and after the reboot?