Duplicati relies on local SQLite databases to maintain file index maps, block volume relations, and operation logs. For power users and system administrators, ensuring this local state remains intact during software updates, version rollbacks, and unexpected system crashes is essential to continuous backup integrity.

Automated Schema Migrations During Updates

When upgrading to a new release, Duplicati automatically checks the database schema version against its internal target model before executing any backup operations.

• Transactional Migration: Schema alterations are wrapped inside explicit SQL transactions. If a migration script encounters an error midway, the entire operation automatically rolls back to the previous working state.

  
  

• Sequential Versioning: Updates execute sequentially step-by-step across intermediate schemas rather than jumping directly to the latest build, preventing edge-case structural mismatches.

  
  

• Pre-Flight Backup: Before applying Data Definition Language (DDL) changes, such as reorganizing index tables or modifying column types, Duplicati creates an automated snapshot of the local .sqlite file.

  
  

Safe Manual Downgrades via CLI

Rolling back to a previous Duplicati release can introduce version mismatch errors if the newer binary already applied non-backward-compatible database changes. Because SQLite does not natively support automated reverse migrations, rolling back requires clean database handling:

• Database Utility Tool: Use Duplicati.CommandLine.DatabaseTool.exe / duplicati-database-tool to query database state, inspect schema metadata, and verify database integrity from the command line.

  
  

• Database Downgrade: If rolling back, use the Duplicati.CommandLine.DatabaseTool.exe / duplicati-database-tool to leverage the built-in downgrade tool.

Note: Run the database tool before downgrading Duplicati as only the new version knows how to downgrade to the older version

Hardening Integrity Against Abrupt Faults

Power loss, kernel panics, or ungraceful shutdowns during an active backup job risk leaving open SQLite files in an inconsistent state.

Duplicati mitigates this by leveraging SQLite Write-Ahead Logging (WAL) and strict transaction boundaries. If a crash occurs mid-write, SQLite uses the WAL file to roll back uncommitted transactions upon the next engine initialization. If physical disk corruption damages the database beyond self-repair, Duplicati marks the local cache as invalid and can safely reconstructs the state from remote storage headers without compromising existing backup archives.

If you want a deeper dive into how the database is used in Duplicati, head over to the forum article.