Most n8n backup guides get the obvious part right: back up the database. Fewer mention the one thing that makes a backup actually useless if you skip it. Here’s the full picture.
The three things a real backup covers
- The database — typically PostgreSQL — which stores your workflows, credentials, and execution history. A
pg_dump(or equivalent) on a schedule is the core of this. - Workflow JSON exports, either via the UI or the API, as a second, portable copy of your workflow definitions independent of the database dump.
- The
.n8ndirectory / instance configuration, so environment settings and any local state are captured alongside the data itself.
The part everyone forgets: the encryption key
n8n encrypts every stored credential using an encryption key. That key is what makes your credential backups readable at all — and it’s stored separately from the database it decrypts, which is exactly why it’s easy to leave out of a backup plan built around “just back up the database.”
If you lose that key, it doesn’t matter how many database backups you have: every stored credential in them becomes permanently unrecoverable. Not “hard to recover” — cryptographically gone. The practical fix is simple and non-negotiable: back up the encryption key separately from the database, ideally in an offline password manager or a secrets vault, and treat losing it as equivalent to losing the entire instance.
What “good” actually looks like
A defensible backup strategy, in order of importance:
- Daily database backups, encrypted, stored off-site (not on the same server as the instance).
- The encryption key, backed up separately, in a different system entirely from where the database backups live.
- A defined retention window — commonly 7 days on lighter tiers, 30 days for production-grade setups — long enough to catch a problem you didn’t notice immediately.
- Continuous or frequent WAL archiving for Postgres specifically, if you want tighter recovery points than “whatever the last daily dump caught.”
- Following the 3-2-1 rule where practical: three copies of the data, on two different types of storage, with one copy off-site.
Testing restores is not optional
An untested backup is a theory, not a backup. The realistic cadence most teams land on is a quarterly full restore test onto a staging instance — enough to catch silent corruption, permission issues, or a backup job that’s been quietly failing for weeks without anyone noticing. If a restore test fails, that’s the finding: better to discover it on a Tuesday afternoon in staging than during an actual incident.
Rollback discipline matters too
Backups aren’t only for disasters — they’re also your safety net for ordinary maintenance. Best practice before any n8n version upgrade is to test it in a staging environment first; if an update breaks workflows or makes the UI unreachable, the plan is to roll back to the previous version, not to debug live in production.
Why this is easy to get wrong on your own, and easy to get right with the right setup
None of this is complicated in isolation. What actually fails, in practice, is consistency — the backup job that silently stopped running two months ago, the encryption key that only lived on one laptop, the restore that was never tested until the day it mattered. That’s the specific gap a managed instance closes: daily off-site encrypted backups with monthly restore tests are the default, not a task on someone’s to-do list. See the full security and backups approach for how it’s structured across plans, or what a migration onto managed hosting actually preserves if you’re moving an existing instance.