How to Back Up & Restore n8n: Workflows + Credentials + Database

The VPS dies. The disk fills up. An update wipes your workflows. A docker compose down -v runs one flag too far. In every one of these scenarios, the difference between "10 minutes of recovery" and "two weeks of rebuilding every workflow from memory" is a single question: did you actually back up n8n — all four layers of it?

---

1. The 4 Layers of a Complete Backup

Every "how to back up n8n" guide covers layer 1. Almost none cover layers 2–4 — which is why so many restores fail. Here's what actually matters:

The encryption key deserves special attention. n8n encrypts every credential with it. The key itself lives in the config file inside ~/.n8n — so backing up the folder does capture it. But if you ever restore to a fresh server with a new key, your exported credentials are permanently unreadable. That's why every method below repeats the same rule: know your key, store it in a password manager, never let it change silently.

---

2. Backup Strategy in 60 Seconds

• Frequency: daily at minimum + immediately before every n8n update (updates are the #1 cause of "restore needed" moments).
• Retention: keep 7 daily backups; 1 monthly for 3 months.
• Location: backups on the same server as n8n are not backups. Copy them off-server — Google Drive, S3, another VPS, even GitHub.
• The 3-2-1 rule: three copies, on two different media, one off-site. For a solo automation stack, that realistically means: server copy + cloud copy + your laptop's monthly pull.
• Know your version: find it in the UI (Settings → About) or with docker compose exec n8n n8n --version, and write it down next to the backups — a safe restore needs the same version (section 9, trap 2).
• Test restores: "a backup you never restored is just a hopeful file." Section 10 lays out the full recovery plan.

---

3. Method 1: CLI Export (Workflows + Credentials)

The n8n CLI exports every workflow and credential as JSON files. This is your portable, version-tolerant layer — it survives moving to a new server, a new database, even a slightly different n8n version:

# Export ALL workflows as JSON files
docker compose exec n8n n8n export:workflow --all --output=/home/node/.n8n/export

# Export ALL credentials (still encrypted with your key)
docker compose exec n8n n8n export:credentials --all --output=/home/node/.n8n/export

# Copy the export folder out of the container
docker compose cp n8n:/home/node/.n8n/export ./n8n-exportCopy

What it does NOT capture: execution history, users, settings, and (in filesystem binary mode) your stored files. For those, you need the database and folder backups below. Think of the CLI export as your fast-recovery layer and the full backup as your disaster-recovery layer.

---

4. Method 2: SQLite Backup (Stop First!)

SQLite is a single file: ~/.n8n/database.sqlite. Copying it while n8n is running risks a corrupted backup — SQLite can be mid-write at any moment. The safe options:

4.1 Stop, copy, start (30 seconds of downtime)

# 1. Stop n8n briefly
docker compose stop n8n

# 2. Copy the database file out of the volume
docker compose cp n8n:/home/node/.n8n/database.sqlite ./backup/database-$(date +%Y-%m-%d).sqlite

# 3. Start n8n again
docker compose start n8nCopy

4.2 Zero-downtime: sqlite3 .backup

If the sqlite3 CLI is available in your container, use its online backup command — safe while n8n runs:

docker compose exec n8n sqlite3 /home/node/.n8n/database.sqlite ".backup /home/node/.n8n/database-backup.sqlite"
docker compose cp n8n:/home/node/.n8n/database-backup.sqlite ./backup/Copy

---

5. Method 3: PostgreSQL pg_dump (Hot Backup, No Downtime)

PostgreSQL has a real advantage here: pg_dump produces a consistent snapshot while n8n keeps running. If you followed our Queue Mode guide, you're already on Postgres — this is your method:

# Hot backup — n8n keeps running, zero downtime
docker compose exec -T postgres pg_dump -U n8n n8n > ./backup/n8n-db-$(date +%Y-%m-%d).sql

# Keep the last 7 days
find ./backup -name 'n8n-db-*.sql' -mtime +7 -deleteCopy

Restore (into a fresh, empty database):

docker compose exec -T postgres psql -U n8n n8n < ./backup/n8n-db-2026-08-16.sqlCopy

---

6. Method 4: The Free Auto-Backup Template

You run automation for a living — so automate your backups. This workflow runs nightly at 3 AM: exports workflows and credentials with the n8n CLI, packs them into a nightly archive (the encryption key itself stays out — it lives in your password manager, not in the archive), keeps a 7-day history, and confirms on Telegram. Deploy it once and backups stop being a thing you remember to do.

{
  "name": "n8n Auto-Backup (Nightly)",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "cronExpression",
              "expression": "0 3 * * *"
            }
          ]
        }
      },
      "id": "schedule",
      "name": "Daily 3:00 AM",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [250, 300]
    },
    {
      "parameters": {
        "command": "=mkdir -p /home/node/.n8n/backup/export && rm -rf /home/node/.n8n/backup/export/* && n8n export:workflow --all --output=/home/node/.n8n/backup/export && n8n export:credentials --all --output=/home/node/.n8n/backup/export && cd /home/node/.n8n/backup && tar -czf n8n-backup-{{ $now.format('yyyy-MM-dd') }}.tar.gz export && cp n8n-backup-{{ $now.format('yyyy-MM-dd') }}.tar.gz n8n-backup-latest.tar.gz && find /home/node/.n8n/backup -name 'n8n-backup-*.tar.gz' -mtime +7 -delete"
      },
      "id": "backup-cmd",
      "name": "Export & Pack",
      "type": "n8n-nodes-base.executeCommand",
      "typeVersion": 1,
      "position": [450, 300]
    },
    {
      "parameters": {
        "chatId": "YOUR_TELEGRAM_CHAT_ID",
        "text": "=✅ n8n BACKUP COMPLETE\n\nDate: {{ $now.format('yyyy-MM-dd HH:mm') }}\nWorkflows + credentials packed.\n7-day history retained in the container.\n\n⚠️ Remember: also copy n8n-backup-latest.tar.gz off-server (Drive/S3)."
      },
      "id": "telegram",
      "name": "Telegram Confirmation",
      "type": "n8n-nodes-base.telegram",
      "typeVersion": 1.2,
      "position": [650, 300],
      "credentials": {
        "telegramApi": {
          "id": "YOUR_TELEGRAM_CREDENTIAL_ID"
        }
      }
    }
  ],
  "connections": {
    "Daily 3:00 AM": {
      "main": [
        [
          {
            "node": "Export & Pack",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Export & Pack": {
      "main": [
        [
          {
            "node": "Telegram Confirmation",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "active": false,
  "settings": {
    "executionOrder": "v1",
    "saveManualExecutions": true
  }
}Copy

• Where it runs: the Execute Command node executes inside the n8n container — that's why the commands are bare (n8n export:workflow, no docker exec needed).
• The key stays OUT of the archive — deliberately. The nightly tar holds workflows and encrypted credentials, but never the key that decrypts them. Store N8N_ENCRYPTION_KEY exactly once, in a password manager or secrets vault, separate from the backups. Lose the key and every archive becomes unreadable — keep it only where you keep your passwords.
• Off-site copy: this template keeps backups inside the container — the honest truth is that a server fire takes them too. Add a Google Drive or S3 upload (Read Binary Files node on n8n-backup-latest.tar.gz → Drive Upload) to ship the archive off-server. More ready-to-import blueprints live in our Templates Library.
• If this workflow fails silently — and one day it will — the Error Handling guide makes backup failures alert you. A backup system nobody monitors is a superstition.
• Ship it off-server: add a Read Binary Files node on n8n-backup-latest.tar.gz followed by a Google Drive or S3 upload node — the full walkthrough is in section 7.2.

---

7. Shipping Backups Off-Server

Here's the uncomfortable truth: the auto-backup template in section 6 keeps archives inside the same server. If the server dies, the backups die with it. A backup is only a backup once it lives somewhere else.

7.1 The host route: rclone + cron (5 minutes)

Point the backup output at a folder on the host, then let rclone push it to Google Drive, S3, or any S3-compatible storage every night:

# In docker-compose.yml — mount a host folder as the backup output
volumes:
  - ./n8n-backups:/home/node/.n8n/backup

# On the host: install rclone once, configure a remote
sudo apt install rclone
rclone config    # name the remote 'offsite'

# crontab -e — push every night at 4 AM, keep a tidy log
0 4 * * * rclone sync /home/you/n8n-backups offsite:n8n-backups >> /var/log/n8n-backup.log 2>&1Copy

7.2 The n8n-native route: Drive upload inside the template

No cron, no host access. Add two nodes to the section 6 template: a Read Binary Files node on /home/node/.n8n/backup/n8n-backup-latest.tar.gz, then a Google Drive → Upload node writing the same filename every night. The cloud file gets overwritten in place — one clean, always-current off-server copy.

7.3 Encrypt the cloud copy (rclone crypt)

Your archives hold workflows and encrypted credentials — sensitive enough that a cloud-account compromise would hurt. crypt makes any leaked archive useless to the attacker. The key itself stays in your password manager, never in the archive (section 6):

# Create an encrypted remote wrapping the plain one
rclone config create offsite-crypt crypt remote=offsite:n8n-backups

# Then sync through it — files land encrypted
0 4 * * * rclone sync /home/you/n8n-backups offsite-crypt: >> /var/log/n8n-backup.log 2>&1Copy

One honest warning: the encryption password becomes another thing you must never lose. Store it next to N8N_ENCRYPTION_KEY in your password manager — lose both and the backups become mathematically unreachable.

---

8. Additional Backup Methods: API & Git

The CLI methods in sections 3–6 need shell access. Two alternatives cover the rest of the real world:

8.1 Back up via the public API (no shell needed)

n8n's REST API can export every workflow definition — the right choice on n8n Cloud, or on any server where you don't have (or don't want) shell access:

# 1. Create an API key: Settings → n8n API → Create API Key
# 2. Pull the workflow list, then save each workflow's JSON
IDS=$(curl -s -H "X-N8N-API-KEY: YOUR_API_KEY" https://n8n.yourdomain.com/api/v1/workflows | jq -r '.data[].id')
for id in $IDS; do
  curl -s -H "X-N8N-API-KEY: YOUR_API_KEY" https://n8n.yourdomain.com/api/v1/workflows/$id -o "workflow-$id.json"
doneCopy

Credentials have their own endpoint (/api/v1/credentials) and follow the same encryption-key rules as everything else in this guide. And treat the API key like a root password — it can read and modify every workflow you own.

8.2 Version your backups with Git (GitHub / Gitea)

Committing the nightly export to a private Git repository adds something no archive can: a full change history. Deleted a workflow by accident at 9 AM? git log shows every version that ever existed:

cd /home/you/n8n-backups/export
git init
git add -A
git commit -m "backup $(date +%Y-%m-%d)"
git push origin mainCopy

---

9. Restore: The 7 Real Traps

Restoring is where backup guides go silent — and where people lose hours. Follow these seven rules and your restore is boring (which is exactly what you want):

---

10. Disaster Recovery Plan: RTO, RPO & Failure Scenarios

Backup is the boring half. Recovery is where time and money get lost. A recovery plan is just two numbers and a short table — write them down once, and every future incident becomes a checklist instead of a panic.

10.1 The two numbers: RTO & RPO

• RTO — Recovery Time Objective: how fast you must be back online. An RTO of 30 minutes means your restore must be automated (prebuilt compose file + scripted import) — not improvised at 2 AM.
• RPO — Recovery Point Objective: how much data you can afford to lose. An RPO of 24 hours means daily backups are enough; an RPO of 1 hour means hourly database dumps.

Realistic numbers for a solo automation stack: RTO 60 minutes, RPO 24 hours. That combination is achievable with exactly what this guide already gives you — a nightly backup plus a documented restore path. Anything tighter and you're building infrastructure, not running a blog of automations.

10.2 Failure scenarios & the right response

Note on the last row: never restore over a compromised instance. If someone had access, assume every credential inside is burned — restore the workflow structure, rotate the secrets, and only then bring the automation back to life.

10.3 The staging ritual

Once a month, restore last night's backup onto a throwaway staging instance and confirm three things: workflows open, credentials connect, and one test execution runs. The night described in section 9 went smoothly because we'd rehearsed it — the day you skip the drill is the day you'll need it.

---

11. Backup Tools Worth Knowing

Four tools that earn their place — all verified, none magical. A tool moves bytes; it doesn't replace the four-layer strategy from section 1:

# restic in one breath: init once, then back up the host folder
restic -r s3:https://s3.amazonaws.com/your-bucket init
restic -r s3:https://s3.amazonaws.com/your-bucket backup /home/you/n8n-backupsCopy

n8n Backup Manager on GitHub is a standalone open-source companion app with a clean web UI — useful if you'd rather click "Restore" than type psql at 2 AM. And the official workflow & credential restoration template on n8n.io restores from a backup folder on demand.

---

12. The 7 Most Common Errors & Fixes

---

13. Backup Checklist

• ✅ N8N_ENCRYPTION_KEY known, explicit, and stored in a password manager
• ✅ n8n image version pinned (not latest)
• ✅ Daily automated backup (cron + the template from section 6)
• ✅ Database layer covered (SQLite stop-first or Postgres pg_dump)
• ✅ .n8n folder covered (config, binaryData, community nodes)
• ✅ Retention policy: 7 days minimum
• ✅ Off-server copy (Google Drive / S3 / rclone to another VPS)
• ✅ Backup failures alert you (Error Trigger workflow)
• ✅ Monthly test restore to a staging instance

---

14. Frequently Asked Questions

---

Sources & References

• n8n Documentation — CLI commands (export/import)
• n8n Documentation — Deployment environment variables (encryption key)
• n8n Documentation — Binary data environment variables
• PostgreSQL Documentation — pg_dump
• SQLite Documentation — Online Backup API (.backup command)

Explore More Guides