GUIDE · Recovery

n8n Backup and Disaster Recovery: What to Save, What to Rotate, What to Test

2026-10-20 · William Ayad · 8 min read

The instance is replaceable — the workflows and credentials are not

Disaster recovery for self-hosted n8n starts by separating what is cattle from what carries memory. The n8n instance itself — binary, Docker image, configuration — rebuilds from scratch in minutes. Three things do not: your workflow definitions, your encrypted credentials, and the encryption key that unlocks them. Lose all three in the same fire and the rebuild is not recovery — it is starting a company again with experience.

What an export covers — and the paradox it hides

The CLI export produces JSON files of your workflow structures — perfect for version history, code review, and Git-based backup. But exports frequently carry secrets: hardcoded tokens pasted into node parameters, headers, even TODO jottings nobody scrubbed. The file that is your safety net becomes a live liability the moment it lands in a repository, a Slack paste, a migration zip. This is the same killer #3 from the silent-failure map, wearing a backup jacket: structure is safe to travel, secrets are not.

The two-item backup contract

Item one: automated, nightly, versioned workflow exports — with secret-scrubbing as a mandatory pipeline step, not a good intention. The practical scrub: scan every export before it hits Git for the token shapes and key names that leak — the class of check the free n8n workflow audit performs in your browser (for any export you hold today, this takes under a minute). Item two: the database plus the N8N_ENCRYPTION_KEY, backed up through your infra provider's snapshot or dump tooling, stored somewhere the export files are not. Two locations minimum — key and data together in one fire is the difference between encrypted and gone.

The restore drill nobody runs (run it)

Quarterly, minimum: spin a fresh n8n on a staging container, feed it the backup database and key, import the workflows, and light one real execution end-to-end. Time it; that number is your true recovery time, not the optimistic guess from the last retrospective. Drills find the realistic failures: a key versioned six months ago and rotated since, an export format drifted across a major upgrade, a credential asking OAuth re-consent on a different callback domain. The diagnosis ladder applies cleanly to the workflows that mysteriously stall after a restore.

The discipline that costs one cron line

Recovery capability follows exactly one rule: it exists only in proportion to what you rehearsed. Backup jobs die too — disk fills, tokens expire, schedules drift. The three-layer monitoring guide has a sentence for backup jobs as well: heartbeat-ping your export job's completion, and let silence alert you, so the day you discover the backup died is today — never during an actual restore.

One last habit before the next deploy lands in the backup stream: run the export through the free audit — secret patterns, localhost URLs, broken references — so what you back up is clean by construction, browser-only, nothing uploaded.

Where the free audit stops (honesty first)

The free tool scans one export at a time for the five structural killers — scrub-grade coverage for a pre-commit habit, not an automated backup pipeline with rotation, drills, and runbooks. Those instruments, plus the 24-rule preflight and the full 21-fix library, live in the n8n Reliability Kit, one-time $39 (disclosing: mine), browser-local like everything here.

Save the structures, rot the secrets, keep the key apart. A backup you restored last quarter is the only backup that exists.