Cara Backup dan Restore Workflow n8n Tanpa Kehilangan Data

Backup n8n yang benar terdiri dari tiga bagian, bukan satu: dump database, folder data, dan encryption key. Melewatkan salah satunya membuat backup Anda terlihat lengkap tapi tidak bisa dipulihkan saat dibutuhkan. Yang paling sering terlewat adalah encryption key, dan akibatnya paling menyakitkan: workflow Anda kembali, tapi semua credential di dalamnya berubah jadi data terenkripsi yang tidak bisa dibuka.

Panduan ini menjelaskan apa saja yang harus di-backup, cara mengotomasinya dengan satu skrip, dan yang paling penting, cara menguji bahwa backup Anda benar-benar bisa dipulihkan.

Apa Saja yang Sebenarnya Perlu Di-Backup

Sebelum menulis skrip, pahami dulu di mana n8n menyimpan apa. Ini menjelaskan kenapa backup satu file saja tidak pernah cukup.

Metode 1: Backup Penuh dengan Satu Skrip

Ini metode utama yang kami sarankan untuk instance self-hosted. Satu skrip yang mengambil ketiga komponen sekaligus lalu membungkusnya jadi satu arsip.

Langkah 1: Buat folder tujuan backup

mkdir -p ~/backups/n8n
cd ~/n8n-stack

Langkah 2: Tulis skrip backup

nano ~/backup-n8n.sh

Isi dengan skrip berikut. Sesuaikan nilai STACK_DIR kalau folder stack Anda berbeda.

#!/bin/bash
set -euo pipefail

STACK_DIR="$HOME/n8n-stack"
BACKUP_DIR="$HOME/backups/n8n"
STAMP=$(date +%Y-%m-%d_%H%M)
WORK="$BACKUP_DIR/tmp_$STAMP"

mkdir -p "$WORK"
cd "$STACK_DIR"

# Ambil kredensial database dari file .env
set -a
source "$STACK_DIR/.env"
set +a

echo "[1/4] Dump database PostgreSQL..."
docker compose exec -T postgres pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB" > "$WORK/database.sql"

echo "[2/4] Salin folder data n8n..."
tar czf "$WORK/n8n-data.tar.gz" -C "$STACK_DIR" n8n-data

echo "[3/4] Salin file konfigurasi..."
cp "$STACK_DIR/docker-compose.yml" "$WORK/"
cp "$STACK_DIR/Caddyfile" "$WORK/"
cp "$STACK_DIR/.env" "$WORK/env.backup"

echo "[4/4] Bungkus jadi satu arsip..."
tar czf "$BACKUP_DIR/n8n-backup-$STAMP.tar.gz" -C "$WORK" .
rm -rf "$WORK"

# Simpan hanya 14 backup terakhir
ls -1t "$BACKUP_DIR"/n8n-backup-*.tar.gz | tail -n +15 | xargs -r rm --

echo "Selesai: $BACKUP_DIR/n8n-backup-$STAMP.tar.gz"

Langkah 3: Beri izin eksekusi dan uji jalankan

chmod +x ~/backup-n8n.sh
~/backup-n8n.sh

Kalau berhasil, Anda akan melihat file arsip baru di folder backup. Periksa ukurannya. Arsip berukuran beberapa kilobyte saja menandakan dump database gagal, biasanya karena nama service PostgreSQL di file compose Anda berbeda.

Metode 2: Ekspor Workflow ke Git

Metode ini melengkapi, bukan menggantikan, backup penuh. Kelebihannya adalah Anda mendapat riwayat perubahan: bisa melihat apa yang berubah pada suatu workflow minggu lalu, dan mengembalikan versi sebelumnya kalau perubahan hari ini merusak sesuatu.

n8n menyediakan perintah CLI untuk mengekspor seluruh workflow sebagai file JSON terpisah.

# Ekspor semua workflow, satu file per workflow
docker compose exec -T n8n n8n export:workflow --backup --output=/home/node/.n8n/backup-workflows/

# Salin ke host
docker compose cp n8n:/home/node/.n8n/backup-workflows/ ./workflows-export/

Setelah itu, folder workflows-export bisa Anda jadikan repositori git dan commit secara berkala.

cd ~/n8n-stack/workflows-export
git init
git add .
git commit -m "Snapshot workflow n8n"

Metode 3: Mengirim Backup ke Luar Server

Backup yang hanya tersimpan di server yang sama dengan n8n bukan backup sesungguhnya. Kalau disk VPS rusak atau server terhapus, keduanya hilang bersamaan. Kirim arsipnya ke tempat lain.

Pilihan paling sederhana adalah rclone, yang bisa menulis ke berbagai penyimpanan awan dengan satu perintah yang sama. Setelah rclone dikonfigurasi, tambahkan satu baris di akhir skrip backup Anda:

rclone copy "$BACKUP_DIR/n8n-backup-$STAMP.tar.gz" remote-anda:n8n-backups/

Alternatif tanpa alat tambahan adalah menyalin ke server lain dengan scp lewat kunci SSH. Prinsipnya sama: yang penting salinannya tidak berada di mesin yang sama.

Untuk gambaran umum strategi backup di lingkungan VPS, panduan cara backup website membahas pola yang bisa dipakai lintas aplikasi.

Menjadwalkan Backup Otomatis

Backup manual selalu berakhir sama: rajin di minggu pertama, lupa di bulan kedua. Jadwalkan dengan cron.

crontab -e

Tambahkan baris berikut untuk menjalankan backup setiap hari pukul 02.00 dini hari waktu server.

0 2 * * * /bin/bash $HOME/backup-n8n.sh >> $HOME/backups/n8n/backup.log 2>&1

Pastikan zona waktu server Anda sudah benar supaya jadwalnya sesuai harapan. Periksa dengan perintah timedatectl. Kalau masih UTC, backup Anda akan berjalan pukul sembilan pagi WIB, tepat saat instance sedang sibuk.

Cara Restore ke Instance Baru

Ini bagian yang paling jarang dilatih orang, dan itulah kenapa restore sering berantakan saat benar-benar dibutuhkan. Urutannya penting.

Langkah 1: Siapkan stack kosong

Pasang Docker di server baru dan salin file docker-compose.yml serta Caddyfile dari backup. Jangan jalankan dulu.

Langkah 2: Pulihkan file .env dengan encryption key yang sama

Ini langkah paling kritis. Nilai N8N_ENCRYPTION_KEY di server baru harus persis sama dengan yang ada di server lama. Kalau berbeda, credential tidak akan bisa dibuka meskipun database berhasil dipulihkan.

Langkah 3: Nyalakan PostgreSQL saja

cd ~/n8n-stack
docker compose up -d postgres

# Tunggu sampai database siap menerima koneksi
sleep 15

Langkah 4: Pulihkan dump database

set -a; source .env; set +a
cat database.sql | docker compose exec -T postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"

Langkah 5: Pulihkan folder data

tar xzf n8n-data.tar.gz -C ~/n8n-stack/
sudo chown -R 1000:1000 ~/n8n-stack/n8n-data

Langkah 6: Nyalakan seluruh stack

docker compose up -d
docker compose logs -f n8n

Buka instance di browser, masuk dengan akun lama Anda, lalu periksa tiga hal: workflow muncul semua, credential bisa dibuka tanpa error, dan satu workflow uji coba berhasil dijalankan manual.

Uji Restore Anda Sebelum Butuh

Ini nasihat yang paling sering diabaikan dan paling mahal harganya. Backup yang belum pernah diuji restore-nya bukan backup, tapi asumsi.

Lakukan latihan ini sekali setiap tiga bulan: ambil VPS termurah yang bisa disewa harian, jalankan prosedur restore di atas dari arsip backup terbaru Anda, pastikan semuanya jalan, lalu hapus VPS itu. Biayanya beberapa ribu rupiah dan waktunya kurang dari satu jam.

Empat hal yang paling sering ketahuan rusak lewat latihan ini: encryption key yang ternyata tidak ikut tersimpan, dump database yang kosong karena nama service salah, folder data yang izin kepemilikannya membuat container gagal start, dan file compose yang merujuk ke jaringan Docker yang tidak ada di server baru.

Membatasi Ukuran Backup

Kalau arsip backup Anda membengkak jadi ratusan megabyte, hampir pasti penyebabnya riwayat eksekusi yang menumpuk. Aktifkan pruning otomatis di file compose Anda:

- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=336
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000

Nilai 336 adalah masa simpan dalam satuan jam, setara 14 hari. Sesuaikan dengan kebutuhan audit Anda. Setelah pruning aktif, ukuran dump database biasanya turun drastis dan backup jadi jauh lebih cepat.

Kalau Anda perlu menyimpan jejak eksekusi lebih lama untuk keperluan audit, pendekatan yang lebih baik adalah mengirim log eksekusi penting ke penyimpanan terpisah lewat workflow, bukan menahan semuanya di database n8n.

Bagaimana kalau Pakai Layanan Terkelola

Kalau instance n8n Anda berjalan di layanan yang sudah menyertakan backup harian, sebagian pekerjaan di atas sudah ditangani. Paket n8n Hosting HostingEkspres misalnya sudah menyertakan daily backup di semua tingkatan paket.

Meski begitu, dua hal tetap jadi tanggung jawab Anda. Pertama, menyimpan encryption key sendiri di pengelola password, karena inilah yang membuka credential Anda. Kedua, mengekspor workflow ke Git secara berkala kalau Anda ingin punya riwayat perubahan, bukan sekadar snapshot server. Backup penyedia melindungi Anda dari kegagalan infrastruktur, tapi tidak melindungi Anda dari kesalahan sendiri saat mengubah workflow.

Pertanyaan Umum (FAQ)

Kesimpulan

Backup n8n yang benar mencakup tiga hal sekaligus: dump PostgreSQL, folder data, dan encryption key yang disimpan terpisah. Otomasikan dengan satu skrip yang dijalankan cron setiap malam, kirim salinannya ke luar server, dan pasang notifikasi supaya kegagalan tidak lewat begitu saja.

Yang paling menentukan bukan seberapa sering Anda membuat backup, tapi apakah Anda pernah membuktikan backup itu bisa dipulihkan. Jadwalkan latihan restore tiga bulan sekali dan Anda akan menemukan masalahnya di saat yang tenang, bukan di saat instance produksi sedang mati. Kalau Anda ingin sebagian beban ini ditangani penyedia, n8n Hosting HostingEkspres sudah menyertakan backup harian di setiap paketnya.