n8n SQLite Database Corrupt Error

n8n SQLite errors / Leave a Comment

Step by Step Guide to solve n8n SQLite Database Corrupt Error

 

Who this is for: Developers and DevOps engineers running n8n in production who need a reliable, step‑by‑step method to detect, back up, recover, and harden a corrupted SQLite database. For a complete guide on managing SQLite in n8n, including errors, performance, and migration, check out our n8n SQLite pillar guide.

Quick Diagnosis

If n8n throws SQLITE_CORRUPT: database disk image is malformed:

  1. Stop the n8n process – prevents further writes.
  2. Back up the current .sqlite file.
  3. Run the three‑step recovery below.
# 1. Verify corruption
sqlite3 /path/to/database.sqlite "PRAGMA integrity_check;"

# 2. Export data if integrity_check fails
sqlite3 /path/to/database.sqlite ".mode csv" ".output /tmp/n8n_backup.csv" "SELECT * FROM workflow;"

# 3. Replace the DB with a clean copy or recreate it
sqlite3 /path/to/database.sqlite < /path/to/clean_schema.sql

After restoring, restart n8n (pm2 restart n8n or docker compose up -d).
*If you have no recent backup, the CSV export is your last‑ditch recovery option.* Find out how to manage disk space in n8n, prevent corruption, and optimize SQLite performance in n8n.

1. Detecting a Corrupt SQLite Database in n8n

Micro‑summary: Identify corruption before any write attempts, then halt the service.

Symptom n8n Log Message Immediate Action
Workflow fails to load Error: SQLITE_CORRUPT: database disk image is malformed Stop n8n; avoid writes.
Random HTTP 500 errors DatabaseError: SQLITE_CORRUPT Verify disk health (e.g., smartctl).
Missing workflow nodes in UI No explicit error Run PRAGMA integrity_check; manually.

1.1 Run an Integrity Check

Purpose: Confirms whether the SQLite file is malformed.

sqlite3 /var/n8n/.n8n/database.sqlite "PRAGMA integrity_check;"
  • Result ok → Corruption is not the cause; investigate other issues.
  • Any error output → Corruption confirmed; proceed to backup.

EEFA Note: Running the check on a live instance can lock the DB. Stop n8n first (pm2 stop n8n or docker stop n8n) to capture a consistent snapshot.

2. Safely Back Up the Corrupted Database

Micro‑summary: Preserve the exact corrupted file before attempting any extraction.

2.1 Offline Copy

# Stop n8n to avoid further writes
pm2 stop n8n   # or `docker stop n8n`

# Copy the DB (preserves the exact corrupted state)
cp /var/n8n/.n8n/database.sqlite /tmp/database_corrupt_$(date +%F_%H%M).sqlite

2.2 Export Recoverable Tables to CSV

Purpose: Pull out rows that are still readable. CSV is tolerant of partial corruption.

Export Workflows

sqlite3 /tmp/database_corrupt_*.sqlite <<'SQL'
.mode csv
.output /tmp/n8n_workflows_backup.csv
SELECT * FROM workflow;
SQL

Export Credentials

sqlite3 /tmp/database_corrupt_*.sqlite <<'SQL'
.mode csv
.output /tmp/n8n_credentials_backup.csv
SELECT * FROM credential;
SQL
  • Why CSV? VACUUM aborts on corruption, but row‑wise reads often succeed.
  • EEFA Warning: CSV does not retain binary data (e.g., encrypted credentials). Export those via the UI before corruption if possible.
  • Optimize performance and prevent storage issues like corruption and disk full errors in n8n SQLite.

3. Restoring from a Known Good Backup

Micro‑summary: Replace the broken file with a clean copy, or rebuild the DB from exported CSVs when no full backup exists.

3.1 Restore a Recent .sqlite Backup

# Rename the broken DB
mv /var/n8n/.n8n/database.sqlite /var/n8n/.n8n/database.sqlite.broken

# Copy the good backup into place
cp /backups/n8n/database_2025-12-20.sqlite /var/n8n/.n8n/database.sqlite

# Fix permissions (Docker containers often run as UID 1000)
chown 1000:1000 /var/n8n/.n8n/database.sqlite
chmod 600 /var/n8n/.n8n/database.sqlite

Restart and verify:

pm2 start n8n   # or `docker start n8n`
curl -s http://localhost:5678/rest/workflows | jq .

3.2 Rebuild from CSV Export (No Full Backup)

  1. Create a fresh schema – n8n ships a schema.sql file.
sqlite3 /var/n8n/.n8n/database.sqlite < /usr/local/lib/node_modules/n8n/dist/database/schema.sql
  1. Import the CSV data.

Import Workflows

sqlite3 /var/n8n/.n8n/database.sqlite <<'SQL'
.mode csv
.import /tmp/n8n_workflows_backup.csv workflow
SQL

Import Credentials

sqlite3 /var/n8n/.n8n/database.sqlite <<'SQL'
.mode csv
.import /tmp/n8n_credentials_backup.csv credential
SQL
  1. Repair auto‑increment counters (SQLite does not auto‑fix sqlite_sequence).
sqlite3 /var/n8n/.n8n/database.sqlite "UPDATE sqlite_sequence SET seq = (SELECT MAX(id) FROM workflow) WHERE name='workflow';"
  1. Validate the rebuilt DB.
sqlite3 /var/n8n/.n8n/database.sqlite "PRAGMA integrity_check;"

A return of ok confirms a healthy database. If errors persist, repeat the export for each table individually.

EEFA Insight: Execution logs (execution_entity table) are lost during CSV import. Keep the original corrupted DB for forensic analysis if needed. Implement backup and restore strategies to protect against database corruption and storage problems in n8n.

4. Preventing Future Corruption

Micro‑summary: Apply SQLite‑level settings, OS‑level safeguards, and regular backups to minimize risk.

Prevention Technique How to Enable Why It Helps
Write‑Ahead Logging (WAL) Add journal_mode=WAL to the SQLite connection string in ~/.n8n/config Reduces lock contention; protects against abrupt shutdowns.
Periodic VACUUM Cron: 0 3 * * * sqlite3 /var/n8n/.n8n/database.sqlite "VACUUM;" Rewrites the file, eliminating fragmented pages.
Filesystem Sync Mount volume with sync (docker run -v n8n_data:/home/node/.n8n:rw,sync) Forces immediate flushes, mitigating power‑loss corruption.
Automated Backups Use restic or rsnapshot to copy /var/n8n/.n8n/database.sqlite hourly Guarantees a recent restore point before corruption spreads.
Disk Health Monitoring smartctl -a /dev/sda + alert on reallocated sectors Disk errors are a leading cause of SQLite corruption.

4.1 Enable WAL in a Docker Deployment

Purpose: Show the minimal docker‑compose changes required.

services:
  n8n:
    image: n8nio/n8n
    environment:
      - DB_TYPE=sqlite
      - DB_SQLITE_DATABASE=/home/node/.n8n/database.sqlite
      - DB_SQLITE_PRAGMA=journal_mode=WAL
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

EEFA Reminder: WAL is incompatible with read‑only filesystems (e.g., some NFS mounts). Test in staging before production rollout.

5. Verifying Recovery & Going Live

Micro‑summary: Perform quick sanity checks to ensure the service is stable after restoration.

  1. Smoke Test – Trigger a simple “Hello World” workflow via UI or API.
  2. Log Review – Confirm no SQLITE_CORRUPT entries appear in ~/.n8n/logs.
  3. Metrics Check – If using Prometheus, verify sqlite_db_size_bytes remains stable (no sudden spikes).

When all checks pass, the recovery is complete.

All commands assume a Linux host; adapt paths for Windows/macOS accordingly. For Docker‑only deployments, replace /var/n8n/.n8n/ with the container’s volume mount point (/home/node/.n8n/).

Must Read

Leave a Comment

Your email address will not be published. Required fields are marked *