n8n Masterclass
0/24 complete

Module 05 · Self-Hosting n8n

Backups, Updates, and Keeping It Running

20 minfocused lesson5practical steps4grounded questions3source links
Open lesson + course map

On this lesson

Course outline

A backup is proven only by restoration. An update is safe only after staging, compatibility checks, database backup, and rollback rehearsal. Availability depends on operated alerts and runbooks, not container restart policies alone.

// concept

Inventory Recovery Assets

Protect:

  • PostgreSQL database;
  • n8n encryption key;
  • deployment configuration and pinned versions;
  • workflow/source exports where useful;
  • required binary data according to storage mode;
  • license/configuration records;
  • DNS/TLS/reverse-proxy instructions;
  • credential owner/rotation inventory without secret values.

Store backups encrypted, access-controlled, and separate from the primary VPS/account. Define recovery point objective (acceptable data loss) and recovery time objective (acceptable outage) from business needs.

// concept

Test Restore

In isolated staging:

  1. create a fresh host/database;
  2. restore database and matching key/config;
  3. start the pinned n8n version;
  4. verify users, workflows, credentials through synthetic calls;
  5. verify webhooks only on staging URLs;
  6. record time, gaps, and evidence;
  7. destroy the test environment securely.

Never connect restored staging to production triggers accidentally.

// concept

Update Deliberately

Read n8n release notes and breaking changes. Pin the candidate in staging, restore a recent scrubbed/authorized backup or representative fixtures, and test critical workflows, credentials, community nodes, webhooks, task runners, and execution modes. Back up production immediately before the maintenance window and define rollback.

Monitor start failures, execution errors, queue age, database/disk, memory/CPU, certificate expiry, backup age, and missing expected runs. Assign owners.

// worked_example

Worked Example

A client schedules monthly updates after a weekly backup restore drill. Version X introduces a node behavior change that breaks an expression in staging. The team fixes/tests before production. During a later update, health checks fail; rollback restores the previous image against compatible database state according to the tested runbook.

The incident report records timeline and evidence without credentials or customer payloads.

// failure_cases

Failure Cases to Diagnose

6 cases to diagnose

  • Only VPS snapshot

    account loss can remove both service and backup.

  • Encryption key missing

    encrypted credentials cannot be recovered.

  • Restore never tested

    backup success notification is insufficient.

  • Automatic major update

    stage compatibility.

  • Rollback ignores database migration

    follow version-specific guidance.

  • Alerts reach one freelancer

    add client-owned escalation.

// pakistan_angle

Pakistan Angle

Schedule maintenance in PKT around real business hours and notify affected teams. Plan for local operator internet/power loss: runbooks and access must be available to another authorized person.

Do not download production backups containing customer/CNIC/bank data to a personal laptop. Use controlled encrypted infrastructure and documented deletion.

// hands_on

Hands-On Exercise

5 steps

  1. Define RPO/RTO and asset inventory.

  2. configure separate encrypted backups.

  3. perform clean restoration.

  4. stage one version update and rollback.

  5. test alerts and alternate operator.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// sources

Sources

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4
  1. 1 / 4 · diagnose

    Your work shows this failure mode: “Rollback ignores database migration.” What does the lesson tell you to do about it?