Backups and Disaster Recovery for n8n on a VPS

Why backups matter in n8n

Automations often become invisible infrastructure. They run silently until they break, and when they do the damage can be huge. Missed invoices, lost leads, failed alerts…. all because a workflow or credential vanished.

That is why backups are not optional when you self host n8n. On a VPS you are responsible for every layer: database, credentials, execution logs, even the Docker volumes. Without a clear backup and restore plan, you are betting your business on luck.

What needs to be backed up

n8n stores data in three places:

• Database: PostgreSQL or SQLite holds workflows, credentials, execution history, and users. This is the most critical part.
• Application data: The .n8n directory inside the container holds configuration, encryption key, and sometimes binary files.
• Binary data: If you run single node with filesystem storage, binary files live on disk. In queue mode they should be in memory or an external storage service like S3 or MinIO.

Backing up only the database is not enough. Without the encryption key in .n8n you cannot decrypt stored credentials. Without binary data storage your file based workflows will break.

VPS level backups vs application level backups

There are two layers of protection.

• VPS snapshots: Instant capture of the entire virtual machine. Useful for rolling back after a failed upgrade. Fast but heavy. Snapshots restore the whole server, not selective data.
• Application level backups: Targeted backups of PostgreSQL, .n8n data, and binary storage. These are lighter, can run daily or hourly, and let you restore specific parts.

The best practice is to combine both. Run daily app level backups and keep weekly VPS snapshots for quick recovery.

How to back up PostgreSQL for n8n

If you use PostgreSQL (which you should for production), the standard tool is pg_dump.

PGPASSWORD=$DB_PASS pg_dump -U $DB_USER -h $DB_HOST -Fc n8n > n8n_backup_$(date +%F).dump

This produces a compressed dump you can restore later. Store it off the VPS — object storage or another server. Encrypt the dump with GPG or at rest in your backup provider.

For larger setups consider streaming backups with pg_basebackup or logical replication.

How to back up the .n8n directory

Inside the container n8n stores critical files at /home/node/.n8n. Mount this as a Docker volume and include it in your backups.

Example with tar:

tar -czf n8n_dotdir_$(date +%F).tar.gz /home/node/.n8n

This ensures your encryption key and configs survive.

Binary data storage

• Single node with filesystem mode: Back up the folder you mapped in N8N_BINARY_DATA_FOLDER.
• Queue mode: Default in-memory storage needs no backup. If you configured external storage (S3, MinIO), rely on their durability plus versioning.

Never try to share filesystem binary storage across multiple workers in queue mode.

Automating backups with cron

Run backups automatically. Add a cron job to dump PostgreSQL and tar the .n8n directory. Example:

0 2 * * * /usr/local/bin/backup_n8n.sh

Your backup_n8n.sh could:

1. Dump the database
2. Tar the .n8n directory
3. Upload both files to S3 or another bucket
4. Rotate old backups

Testing restores

Backups are only real if you can restore them. Test monthly:

• Spin up a fresh VPS
• Install Docker and your stack
• Restore the database
• Restore .n8n data
• Confirm you can log in and workflows run

Without testing you risk discovering broken backups when it is already too late.

Disaster recovery with VPS snapshots

When an update goes sideways, snapshots are the fastest recovery. Most VPS panels let you restore in a few clicks. This rolls back the entire VM, so you lose changes since the snapshot. Keep them weekly or before risky upgrades.

Common pitfalls

• Backing up only the database, forgetting the encryption key.
• Storing backups on the same VPS, then losing everything when the VPS dies.
• Not pruning old executions, letting database size explode and backups grow huge.
• Skipping restore tests.

Putting it all together

A solid plan looks like this:

• Daily PostgreSQL dump and .n8n backup uploaded off-server
• Weekly VPS snapshot before upgrades
• Monthly restore drill to verify backups
• Binary data handled properly depending on storage mode

This way you cover both small failures and big disasters.

FAQ

How often should I back up n8n?

At least daily for database and .n8n directory. Snapshots weekly or before upgrades.

Can I rely only on VPS snapshots?

No. Snapshots are big and restore the whole system. You need database level backups for finer control.

Do I need to back up Redis in queue mode?

No. Redis only holds jobs temporarily. Completed executions are stored in PostgreSQL.

How do I protect credentials?

Never back up without the encryption key from .n8n. Without it credentials cannot be decrypted.

What is the fastest way to recover from a failed update?

Use a VPS snapshot. It restores the whole server in minutes. Then debug the failed update on staging before retrying.