No further backups are possble as there is an error in the database.

[omfk]

Case #08211338

As this is involving the Community edition the case was closed at Veeam due to low support stuff availability. No complain about this.

Maybe someone else has already encountered such a problem:
Additional Details:
19.08.2026 09:12:07 :: JetError -543, JET_errRequiredLogFilesMissing, The required log files for recovery is missing.

Date / Time Event
2026-06-18 16:21:27 UTC Last fully consistent checkpoint recorded in repository.adb (header field “Last Consistent”).
2026-06-19 ≈12:04 UTC Last recorded database activity before the dirty state began; presumed point of interruption (drive disconnect or host I/O stall).
2026-08-18 09:17–09:18 Proxy service repeatedly fails to open the repository: “SQLite Error 14: unable to open database file” (X:\Repository.sqlite) — drive not reachable.
2026-08-19 04:54 Further failed load attempt, same SQLite error — drive still unreachable.
2026-08-19 09:00:29–09:00:30 Drive reconnected. Proxy service opens the SQL database, then fails to initialize the ESE database context for X:\2026 with JetError -543 (JET_errRequiredLogFilesMissing).
2026-08-19 Directory listing of X:\2026 confirms log generations 0x36E1–0x36E8 (14049–14056) — the exact required range — are absent; generations 0x36E9 onward are present.
2026-08-19 esentutl /r adb /lX:\2026 /dX:\2026 executed — fails immediately (0.187 s) with JetError -543, confirming soft recovery is not possible.
2026-08-19 → 20 esentutl /p repository.adb (hard repair) executed — runs ≈11.2 h, reaches ≈50% into “Repairing damaged tables,” terminates with JetError -1620 (JET_errDecompressionFailed).
2026-08-19 (post-repair) esentutl /mh shows Clean Shutdown, a new DB Signature, and Repair Count: 2 — reflecting partial progress, not a verified-clean database.
2026-08-2x esentutl /g repository.adb (integrity check) executed — runs ≈4.44 h, reaches ≈98% complete, terminates again with JetError -1620.
2026-08-2x chkdsk X: /scan (online, metadata-level) completes in ≈3.8 min: 0 KB in bad sectors, no filesystem issues.
2026-08-2x → 25 chkdsk X: /r (offline, scheduled boot-time run) completes after 4.44 days total (Phase 4 surface scan alone: 4.38 days): 0 KB in bad sectors across the entire volume.


Is there any change to just delete the problematic part and then reuse other backup data for continuing the backup?
Or is the only change to completely start from scratch?

BR
Frank

[Polina]

Hi Frank,

In such a case, starting from scratch would be the most reliable way.

Thanks!