Backup và khôi phục n8n cần giữ những thành phần nào?

Trước khi chuyển n8n sang một máy chủ mới, bạn cẩn thận xuất (export) toàn bộ workflow ra các tệp JSON bằng câu lệnh CLI. Tệp tin được nhập (import) thành công vào máy chủ mới, các node xuất hiện đầy đủ trên màn hình, nhưng toàn bộ credential (thông tin xác thực) đều báo lỗi không thể sử dụng. Lịch sử thực thi (execution history) biến mất hoàn toàn và một số workflow xử lý tệp tin báo lỗi thiếu dữ liệu.

Đây là tình huống rất thường gặp khi vận hành n8n. Lệnh export workflow của n8n chỉ giúp bạn lưu giữ logic và sơ đồ kết nối, nhưng một hệ thống tự động hóa hoàn chỉnh còn phụ thuộc chặt chẽ vào cơ sở dữ liệu, encryption key (khóa mã hóa thông tin xác thực), kho lưu trữ dữ liệu tệp tin (binary data), cấu hình môi trường và các custom node (node tự phát triển). Nếu chỉ giữ các tệp JSON, bạn mới chỉ sao lưu được phần vỏ của hệ thống.

Bài viết này giúp bạn xác định chính xác các thành phần bắt buộc phải sao lưu theo kiến trúc thực tế, đồng thời hướng dẫn quy trình diễn tập khôi phục (restore drill) có kiểm soát. Mục tiêu không phải là tạo ra thật nhiều tệp sao lưu, mà là dựng lại được instance n8n từ máy chủ trắng, giải mã thành công credential và chạy thử workflow an toàn mà không vô tình tác động tới dữ liệu production.

Bộ dữ liệu phục hồi toàn diện n8n (Recovery Set): Database Dump, Volume .n8n, Encryption Key, Binary Storage và Cấu hình Compose.

1. Phân biệt giữa Export workflow và Sao lưu toàn diện instance

Công cụ dòng lệnh của n8n (Server CLI) cho phép xuất workflow và credential ra các tệp JSON riêng biệt. Tính năng này rất hữu ích khi bạn muốn di chuyển một logic nghiệp vụ giữa các môi trường, đưa mã nguồn vào Git hoặc lưu trữ phiên bản.

Tuy nhiên, CLI export không lưu trữ toàn bộ trạng thái của một máy chủ n8n. Theo tài liệu chính thức, câu lệnh này không bao gồm: tài khoản người dùng và vai trò phân quyền, lịch sử thực thi, nhật ký hệ thống, biến môi trường nội bộ, cấu hình instance và đặc biệt là không chứa encryption key. Do đó, bạn không thể chỉ dựa vào các tệp JSON xuất ra để dựng lại nguyên trạng hệ thống sau sự cố mất máy chủ.

Bạn cần phân biệt rạch ròi hai loại bản sao:

• Bản xuất workflow/credential (Export): Phục vụ việc di chuyển logic hoặc khôi phục nhanh một quy trình bị xóa nhầm.
• Bản sao lưu toàn diện (Full backup): Bao gồm cơ sở dữ liệu, khóa mã hóa và cấu hình máy chủ, phục vụ việc dựng lại toàn bộ hệ thống sau thảm họa phần cứng hoặc khi nâng cấp phiên bản thất bại.

Cả hai loại bản sao này nên được duy trì song song trong quy trình vận hành.

2. Lập bản đồ dữ liệu trước khi viết lệnh sao lưu

Đừng mặc định rằng dữ liệu của bạn chỉ nằm gọn trong một volume Docker. Trước khi thiết lập bất kỳ tập lệnh (script) sao lưu tự động nào, hãy đọc kỹ tệp cấu hình triển khai và lập danh mục vị trí thực tế của từng thành phần:

• n8n đang sử dụng hệ quản trị cơ sở dữ liệu nào (SQLite nội bộ hay PostgreSQL độc lập)?
• Thư mục cấu hình N8N_USER_FOLDER (mặc định là ~/.n8n) đang được gắn kết (mount) vào volume nào trên máy chủ?
• Khóa encryption key đang nằm trong tệp cấu hình trên ổ đĩa hay được cấp qua biến môi trường bí mật?
• Dữ liệu tệp tin (binary data) đang được lưu trong RAM, trên ổ đĩa cục bộ hay đẩy ra dịch vụ lưu trữ đối tượng (S3/MinIO)?
• Có custom node nào được nạp qua thư mục mở rộng N8N_CUSTOM_EXTENSIONS hay không?
• Tệp docker-compose.yml, tệp biến môi trường .env và cấu hình reverse proxy đang được lưu trữ ở đâu?
• Phiên bản image Docker cụ thể nào đang chạy?

Bạn có thể xem thêm cách xác định đúng volume dữ liệu tại bài viết về backup dữ liệu persistent của container. Kết quả của bước này phải là một bản kiểm kê vị trí rõ ràng, không phải là một ghi chú chung chung kiểu "đã sao lưu container Docker".

3. Thư mục .n8n luôn là thành phần bắt buộc phải sao lưu

Theo tài liệu chính thức của n8n, một bản sao lưu toàn diện luôn bao gồm thư mục .n8n và cơ sở dữ liệu ngoài (nếu dùng PostgreSQL). Thư mục này mặc định chứa tệp cấu hình lưu trữ encryption key. Nếu bạn sử dụng SQLite mặc định, toàn bộ tệp cơ sở dữ liệu cũng nằm trực tiếp tại đây.

Nhiều người quản trị mắc sai lầm: sau khi chuyển sang dùng PostgreSQL độc lập, họ lập tức bỏ qua thư mục .n8n vì nghĩ rằng toàn bộ dữ liệu đã nằm trong database. Nhưng thực tế, PostgreSQL chỉ lưu các credential ở dạng đã mã hóa thành chuỗi ký tự vô nghĩa; n8n vẫn bắt buộc phải có đúng encryption key từ thư mục .n8n (hoặc biến môi trường tương ứng) mới có thể giải mã để sử dụng. Mất khóa này đồng nghĩa với việc toàn bộ credential trong database đều vô giá trị.

Ngoài ra, khi khôi phục thư mục .n8n trên máy chủ mới, hãy kiểm tra quyền sở hữu tệp tin (owner và permission). Mặc định container n8n chạy dưới quyền người dùng không có đặc quyền (user node với UID/GID 1000). Nếu bạn dùng quyền root để giải nén bản sao lưu, n8n có thể bị lỗi không thể đọc hoặc ghi tệp cấu hình khi khởi động lại.

4. Sao lưu cơ sở dữ liệu phải đạt trạng thái nhất quán

Cách thức sao lưu cơ sở dữ liệu phụ thuộc vào hệ quản trị bạn đang sử dụng:

• Nếu dùng SQLite: Tài liệu n8n khuyến nghị bạn nên tạm dừng container n8n trước khi sao chép tệp cơ sở dữ liệu trong thư mục .n8n. Việc sao chép trực tiếp tệp SQLite khi ứng dụng đang liên tục ghi log thực thi có thể tạo ra một bản sao bị hỏng cấu trúc (corrupt file). Nếu không thể dừng container, bạn bắt buộc phải sử dụng công cụ snapshot chuyên dụng của SQLite.
• Nếu dùng PostgreSQL: Hãy sử dụng công cụ pg_dump tiêu chuẩn để xuất dữ liệu nhất quán tại một thời điểm mà không cần dừng ứng dụng. Hãy ghi rõ phiên bản PostgreSQL, mốc thời gian bắt đầu và kết thúc sao lưu. Một tệp dump chưa từng được khôi phục thử chỉ chứng minh rằng câu lệnh đã chạy xong, chưa chứng minh dữ liệu bên trong có thể dùng lại được.

Đặc biệt, trước mỗi lần nâng cấp phiên bản n8n, bạn bắt buộc phải tạo một bản sao lưu toàn diện cơ sở dữ liệu. Nếu phiên bản mới tự động chạy các đoạn mã di chuyển cấu trúc bảng (schema migration), việc hạ tag Docker image xuống phiên bản cũ sẽ không thể cứu hệ thống nếu bạn không có bản sao lưu database tương ứng để khôi phục lại cấu trúc bảng trước đó.

5. Encryption key là thành phần sống còn của dữ liệu phục hồi

Khóa encryption key được tạo ra trong lần đầu tiên n8n khởi động và được dùng để mã hóa toàn bộ mật khẩu, token và khóa bí mật trước khi ghi xuống cơ sở dữ liệu. Khóa này có thể nằm trong tệp cấu hình của thư mục .n8n hoặc được thiết lập chủ động qua biến môi trường N8N_ENCRYPTION_KEY.

Khóa này phải được sao lưu và lưu giữ trong hệ thống quản lý secret độc lập của đội ngũ kỹ thuật, tách biệt hoàn toàn khỏi máy chủ VPS nhưng phải luôn sẵn sàng khi cần phục hồi. Tuyệt đối không đưa khóa bí mật này vào Git, tài liệu hướng dẫn công khai hoặc gửi qua các kênh chat không mã hóa. Bạn có thể tham khảo thêm cách bảo vệ biến môi trường và secret trong Docker.

Nếu bạn triển khai n8n ở chế độ hàng đợi mở rộng (queue mode), toàn bộ các worker container và instance điều phối chính bắt buộc phải dùng chung một encryption key. Nếu worker sử dụng sai key, hệ thống vẫn mở được giao diện editor nhưng các tác vụ xử lý ngầm sẽ âm thầm báo lỗi giải mã.

n8n cung cấp tùy chọn xuất credential ở dạng đã giải mã (--decrypted). Khi sử dụng cờ này, toàn bộ mật khẩu và API token sẽ xuất hiện dưới dạng văn bản rõ (plain text). Bạn không nên dùng tùy chọn này cho quy trình sao lưu tự động định kỳ vì nó biến tệp sao lưu thành một điểm lộ thông tin xác thực nguy hiểm. Nếu một kịch bản chuyển đổi hệ thống bắt buộc phải dùng, hãy giới hạn nghiêm ngặt quyền truy cập, mã hóa tệp và xóa sạch dữ liệu sau khi hoàn tất.

6. Binary data, lịch sử thực thi và các node tùy biến

Ngoài cơ sở dữ liệu và khóa bí mật, còn ba thành phần phụ trợ rất dễ bị bỏ quên trong kế hoạch sao lưu:

• Dữ liệu tệp tin (Binary data): Các workflow xử lý tệp đính kèm, tạo hóa đơn PDF hoặc phân tích hình ảnh thường lưu tệp tin bên ngoài cơ sở dữ liệu (trên ổ đĩa máy chủ hoặc dịch vụ lưu trữ S3). Nếu bạn chỉ khôi phục database mà thiếu các tệp tin này, workflow vẫn hiển thị lịch sử thực thi nhưng người dùng không thể mở hoặc tải lại tệp tin.
• Thời hạn lưu lịch sử thực thi: Hãy đảm bảo rằng chính sách sao lưu đồng bộ với chính sách dọn dẹp (pruning). Không nên cố gắng sao lưu hàng chục gigabyte log thực thi cũ nếu chúng không phục vụ mục đích kiểm toán hay đối soát.
• Các node tùy biến (Custom nodes): Nếu workflow của bạn sử dụng các node mở rộng được cài đặt qua thư mục N8N_CUSTOM_EXTENSIONS hoặc cài thêm từ cộng đồng, bạn bắt buộc phải sao lưu thư mục này và ghi lại chính xác phiên bản của từng gói mở rộng. Một bản khôi phục có đầy đủ workflow nhưng thiếu thư viện node tương ứng sẽ báo lỗi thiếu loại node (Node type not found) và dừng hoạt động.

Khi phục hồi sự cố, không tự ý cài đặt phiên bản mới nhất của các community node; hãy cài đúng phiên bản đã được kiểm thử để tránh sự thay đổi hành vi ngoài ý muốn.

7. Lưu giữ tệp cấu hình để sẵn sàng tái lập môi trường

Cơ sở dữ liệu và thư mục volume là chưa đủ nếu bạn không biết cách kết nối chúng lại với nhau khi dựng một máy chủ mới. Kế hoạch sao lưu cần lưu giữ cả tệp cấu hình triển khai (như docker-compose.yml) đã loại bỏ các khóa bí mật thật, kèm theo tài liệu hướng dẫn nơi lấy secret.

Những thông tin cấu hình cốt lõi cần lưu trữ bao gồm:

• Phiên bản cụ thể của n8n, PostgreSQL và Redis (nếu có).
• Cấu hình tham số kết nối cơ sở dữ liệu và tên database.
• Tên miền chính thức, cấu hình biến môi trường WEBHOOK_URL, múi giờ và cấu hình reverse proxy.
• Chế độ lưu trữ dữ liệu tệp tin (storage mode), thông số bucket và endpoint.
• Chính sách dọn dẹp lịch sử thực thi (execution pruning) và giới hạn số luồng chạy đồng thời.
• Danh sách các worker container, tham số hàng đợi và đường dẫn nạp custom node.
• Hướng dẫn cấp khóa N8N_ENCRYPTION_KEY và thông tin kết nối các dịch vụ phụ thuộc.

Tài liệu vận hành (runbook) không được chứa mật khẩu trực tiếp, mà chỉ cần chỉ rõ cho kỹ sư có thẩm quyền biết secret được lưu ở đâu trong kho quản lý bí mật nội bộ và quyền truy cập cần thiết để lấy ra.

8. Bản sao lưu phải nằm ngoài vùng chịu lỗi của máy chủ

Một tệp sao lưu nằm trực tiếp trên cùng một máy chủ VPS có thể biến mất cùng lúc khi máy chủ gặp sự cố phần cứng hoặc bị xóa nhầm. Việc tạo snapshot trên cùng hệ thống lưu trữ của nhà cung cấp dịch vụ đám mây giúp bạn quay lại nhanh khi gặp lỗi thao tác, nhưng không bảo vệ bạn trước sự cố hỏng hóc toàn vùng (region failure) hoặc sự cố ở tầng tài khoản dịch vụ.

Hãy áp dụng quy tắc backup 3-2-1 cho VPS: luôn có ít nhất 3 bản sao lưu, trên 2 loại phương tiện lưu trữ khác nhau, và ít nhất 1 bản sao lưu được lưu trữ độc lập tại một vị trí vật lý hoặc dịch vụ đám mây bên ngoài. Bạn có thể kết hợp thêm hướng dẫn tại bài chiến lược backup VPS cho doanh nghiệp nhỏ để xây dựng chu kỳ lưu trữ phù hợp.

Toàn bộ tệp sao lưu n8n phải được mã hóa trước khi truyền qua mạng và lưu trữ tại đích đến. Hãy phân quyền nghiêm ngặt: chỉ tài khoản sao lưu tự động mới có quyền ghi dữ liệu vào kho lưu trữ ngoài. Cần nhớ rằng, người nắm trong tay bản sao lưu database và encryption key có thể giải mã toàn bộ API token và mật khẩu của doanh nghiệp, vì vậy quyền tiếp cận bản sao lưu phải được bảo vệ chặt chẽ hơn cả quyền truy cập giao diện n8n hàng ngày.

9. Chuẩn bị môi trường khôi phục cô lập hoàn toàn

Tuyệt đối không bao giờ thực hiện diễn tập khôi phục đè trực tiếp lên máy chủ production đang chạy. Hãy sử dụng một máy chủ thử nghiệm hoặc mạng nội bộ hoàn toàn tách biệt.

Trước khi khởi động n8n trên môi trường thử nghiệm, bạn cần áp dụng các biện pháp an toàn nghiêm ngặt:

• Ngăn chặn kích hoạt ngoài ý muốn: Khi khôi phục nguyên trạng cơ sở dữ liệu, các workflow đang ở trạng thái hoạt động (active) trên production sẽ giữ nguyên trạng thái đó. Nếu máy chủ thử nghiệm có kết nối Internet thông suốt, một workflow hẹn giờ có thể tự động chạy và gửi email thật, gọi thanh toán thật hoặc ghi đè dữ liệu CRM thật của khách hàng.
• Cách ly mạng: Hãy chặn đường truyền ra ngoài Internet (egress) của container thử nghiệm đối với các dịch vụ bên thứ ba, hoặc sử dụng câu lệnh cập nhật trực tiếp cơ sở dữ liệu để chuyển toàn bộ workflow về trạng thái tạm dừng (inactive) trước khi khởi động n8n.
• Sử dụng tài khoản thử nghiệm: Chuẩn bị sẵn một bộ credential thử nghiệm có phạm vi hạn chế để dùng riêng cho việc kiểm tra kết nối sau khôi phục.
• Cố định đúng phiên bản: Sử dụng chính xác phiên bản Docker image n8n tương ứng với bản sao lưu. Đừng kết hợp việc diễn tập khôi phục với việc nâng cấp phiên bản mới trong cùng một lần thao tác, vì điều đó sẽ làm bạn không thể phân biệt lỗi phát sinh do dữ liệu hay do phần mềm mới.

10. Thứ tự khôi phục theo chuỗi phụ thuộc

Việc khôi phục theo đúng thứ tự giúp bạn phát hiện lỗi ngay tại tầng phát sinh thay vì để lỗi lan truyền lên ứng dụng:

1. Dựng hạ tầng mạng và volume: Tạo các volume lưu trữ bền vững và mạng nội bộ cần thiết, chưa cho phép lưu lượng truy cập công khai từ bên ngoài vào.
2. Khôi phục thư mục .n8n và custom node: Giải nén thư mục cấu hình và các thư viện mở rộng, kiểm tra và gán đúng quyền sở hữu cho người dùng nội bộ của container (thường là user node với UID 1000).
3. Khôi phục cơ sở dữ liệu PostgreSQL: Nạp tệp dump vào hệ quản trị cơ sở dữ liệu và xác nhận dữ liệu đã được nạp đủ các bảng.
4. Thiết lập biến môi trường và Encryption Key: Cung cấp chính xác khóa N8N_ENCRYPTION_KEY và các thông số kết nối database trong tệp .env.
5. Khởi động container n8n: Bật tiến trình n8n và theo dõi nhật ký khởi động (container logs). Xác nhận endpoint /healthz/readiness trả về mã HTTP 200 và không có thông báo lỗi giải mã.
6. Đăng nhập và kiểm tra tài sản: Đăng nhập bằng tài khoản quản trị, kiểm tra danh sách workflow, danh sách credential và các biến môi trường nội bộ.
7. Chạy kiểm tra thực tế (Smoke test): Mở một workflow thử nghiệm, kiểm tra kết nối credential và chạy thử để xác nhận luồng xử lý hoàn tất trơn tru.

Nếu gặp thông báo lỗi không giải mã được credential, đừng cố gắng xử lý bằng cách tạo ra một khóa encryption key mới. Khóa mới không thể giải mã các dữ liệu cũ. Hãy dừng lại ngay và tìm đúng khóa bí mật đã được lưu kèm với bản sao lưu cơ sở dữ liệu đó.

11. Tiêu chí nghiệm thu một lần khôi phục thành công

Một buổi diễn tập khôi phục chỉ được xem là đạt yêu cầu khi bạn thu thập đủ các bằng chứng xác nhận ở từng lớp:

Bạn có thể tham khảo thêm khung kiểm tra chi tiết tại bài viết về checklist thử restore website để bổ sung các bước kiểm tra tên miền và chứng chỉ SSL.

12. Đo lường RPO và RTO thực tế từ lần diễn tập

Mục tiêu điểm phục hồi (RPO - lượng dữ liệu mất tối đa chấp nhận được) trên lý thuyết phụ thuộc vào tần suất bạn lên lịch chạy script sao lưu. Nhưng RPO thực tế phụ thuộc vào bản sao lưu gần nhất có thể khôi phục thành công. Nếu bản sao lưu cách đây 4 giờ bị hỏng key và bạn buộc phải dùng bản của ngày hôm trước, RPO thực tế của bạn đã là hơn 24 giờ.

Tương tự, mục tiêu thời gian phục hồi (RTO - thời gian hệ thống được khôi phục) ghi trong tài liệu chỉ là ước tính; thời gian bấm giờ thực tế từ lúc kỹ sư bắt đầu tạo máy chủ mới cho đến khi workflow thử nghiệm chạy xong mới là con số có giá trị vận hành.

Sau mỗi buổi diễn tập khôi phục, hãy ghi nhận lại:

• Bộ dữ liệu phục hồi (Recovery set) đã dùng và mốc thời gian của từng tệp tin.
• Thời gian chính xác cần thiết để khôi phục cơ sở dữ liệu, volume và ứng dụng.
• Các thao tác thủ công phát sinh ngoài dự kiến và các lỗi phân quyền gặp phải.
• Khoảng cách giữa RPO/RTO thực tế đo được so với cam kết vận hành của doanh nghiệp.
• Những điểm cần cập nhật lại trong tập lệnh tự động và tài liệu hướng dẫn khôi phục.

Checklist sao lưu và khôi phục n8n toàn diện

• ☐ Xác định loại cơ sở dữ liệu: Ghi rõ n8n dùng SQLite hay PostgreSQL và công cụ sao lưu tương ứng.
• ☐ Bản đồ volume lưu trữ: Xác định chính xác vị trí thư mục .n8n, các volume Docker và đường dẫn lưu trữ tệp tin.
• ☐ Bảo vệ Encryption Key: Khóa N8N_ENCRYPTION_KEY có bản sao lưu độc lập trong kho quản lý mật khẩu của đội ngũ.
• ☐ Tính nhất quán của dữ liệu: Dừng container SQLite trước khi sao chép, hoặc dùng pg_dump cho PostgreSQL.
• ☐ Dữ liệu tệp tin ngoài: Kho lưu trữ binary data (ổ đĩa hoặc S3) được sao lưu đồng bộ với cơ sở dữ liệu.
• ☐ Lưu giữ cấu hình: Tệp Docker Compose, biến môi trường (đã gỡ secret) và danh sách custom node được lưu trữ an toàn.
• ☐ Lưu trữ ngoài máy chủ: Bản sao lưu được mã hóa và chuyển tự động sang vị trí lưu trữ độc lập theo quy tắc 3-2-1.
• ☐ Môi trường diễn tập cô lập: Thực hành khôi phục trên máy chủ riêng biệt, chặn các trigger gọi ra dữ liệu thật.
• ☐ Kiểm tra giải mã credential: Thử nghiệm thành công kết nối credential bằng tài khoản thử nghiệm.
• ☐ Khôi phục thực tế thành công: Chạy thử nghiệm trơn tru một workflow đại diện bằng dữ liệu test.
• ☐ Cập nhật tài liệu: Cập nhật RPO, RTO thực tế và các câu lệnh thao tác vào tài liệu hướng dẫn sự cố của đội ngũ.

Kết luận

Một bản sao lưu n8n đạt chuẩn không bao giờ chỉ dừng lại ở các tệp JSON xuất ra từ giao diện. Bạn bắt buộc phải giữ đủ: cơ sở dữ liệu nhất quán, thư mục volume .n8n, khóa encryption key, kho lưu trữ binary data, các custom node mở rộng và toàn bộ cấu hình triển khai để kết nối chúng lại.

Khâu quan trọng nhất luôn là một lần diễn tập khôi phục thực tế trong môi trường cô lập. Chỉ khi một kỹ sư khác trong đội ngũ có thể dựa vào tài liệu hướng dẫn để dựng lại hệ thống, giải mã thành công credential và kích hoạt được workflow thử nghiệm, bạn mới có thể yên tâm rằng hệ thống tự động hóa của mình thực sự được bảo vệ an toàn trước mọi sự cố.

Nguồn tham khảo

• n8n Docs — Backing up n8n
• n8n Docs — Server CLI commands
• n8n Docs — Set a custom encryption key
• n8n Docs — Choose n8n's database
• n8n Docs — Security