پرش به مطلب اصلی

نگهداری، بکاپ و انتقال n8n

بعد از ساخت workflow، پایداری آن به داده‌های سرویس، credentialها و مدیریت اجراها وابسته است. پیش از تغییر نسخه یا موقعیت، یک نسخهٔ قابل بازیابی داشته باشید.

چه چیزی باید حفظ شود؟​

بکاپ کامل باید پوشهٔ دادهٔ واقعی .n8n، کلید رمزگذاری credentialها، دیتابیس و محل ذخیرهٔ فایل‌های باینری را پوشش دهد. اگر دیتابیس یا ذخیره‌ساز خارجی دارید، بکاپ آن هم جدا لازم است. مسیر رایج Docker، /home/node/.n8n است؛ مسیر و اتصال دیسک برنامهٔ آمادهٔ خودتان را از تنظیمات و کنسول بررسی کنید و تغییر ندهید. برای SQLite، کپی خام هنگام نوشتن برنامه ممکن است سازگار نباشد؛ از بکاپ سازگار یا توقف برنامه هنگام کپی استفاده کنید. مرجع بکاپ کامل n8n

در پنل برنامه‌های آماده ← سرویس n8n ← بکاپ‌ها وضعیت و پوشش بکاپ را بررسی کنید. بکاپ سرویس و مسیرهای دائمی را ببینید؛ صرف وجود JSON یک workflow، بکاپ کل سرویس نیست.

N8N_ENCRYPTION_KEY در صورت استفاده باید ثابت و محرمانه بماند؛ اگر از کلید خودکار استفاده می‌کنید، فایل config حاوی آن را حفظ کنید. روی سرویس موجود یک کلید جدید جایگزین نکنید؛ credentialهای قبلی ممکن است دیگر قابل خواندن نباشند. مرجع کلید رمزگذاری

خروجی workflow و credential​

برای جابه‌جایی چند workflow، از گزینهٔ Download/Export در editor خروجی JSON بگیرید. قبل از اشتراک‌گذاری، headerهای دستی، URLهای دارای token، داده‌های pinشده و اطلاعات خصوصی را بررسی کنید.

در کنسول همان سرویس، برای خروجی مدیریتی از CLI داخلی n8n استفاده کنید. ابتدا پوشهٔ خروجی را داخل مسیر دائمی و موجود انتخاب کنید؛ مثال زیر مسیر اختصاصی قابل جایگزینی است:

n8n export:workflow --all --output=/YOUR_PERSISTENT_BACKUP_DIR/workflows.json
n8n export:credentials --all --output=/YOUR_PERSISTENT_BACKUP_DIR/credentials.json

خروجی credential به‌صورت معمول رمزگذاری‌شده است و بازیابی آن به کلید اصلی نیاز دارد. --decrypted رمزها را به متن ساده تبدیل می‌کند؛ در خروجی عمومی یا تیکت استفاده نکنید. exportها را از سرویس دریافت و محفوظ نگه دارید. این فرمان‌ها جایگزین بکاپ کامل نیستند. مرجع export/import

ارتقای نسخه​

  1. نسخهٔ فعلی و مقصد را ثبت و یادداشت انتشار و تغییرات ناسازگار را بخوانید.
  2. بکاپ داده، کلید و تنظیمات را بگیرید؛ امکان بازیابی را بررسی کنید.
  3. در یک سرویس آزمایشی جدا، workflowهای مهم و credentialها را بررسی کنید؛ زمان‌بندی و webhook آن را به production وصل نکنید.
  4. در پنل، سرویس n8n ← تنظیمات ← نسخه را تغییر دهید.
  5. بعد از آماده‌شدن، لاگ راه‌اندازی، ورود، webhook، زمان‌بندی و یک اجرای واقعی را بررسی کنید.

برگرداندن فقط نسخهٔ برنامه ممکن است کافی نباشد؛ ارتقا می‌تواند دیتابیس را migrate کند. برای بازگشت، نسخه و بکاپ سازگار همان زمان لازم است. راهنمای رسمی ارتقا

مدیریت اجراها و رشد دیسک​

در Executions علت شکست، مدت اجرا و خروجی nodeها را بررسی کنید. برای workflowهای حاوی متن خصوصی، ذخیرهٔ payload موفق را متناسب با نیاز کاهش دهید. برای نمونه، تنظیمات زیر سابقه را محدود می‌کنند؛ این مقادیر سیاست نمونه هستند و اجرای pruning به حذف تاریخچه منجر می‌شود:

EXECUTIONS_TIMEOUT=300
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000

timeout برحسب ثانیه و عمر سابقه برحسب ساعت است؛ 168 یعنی هفت روز. این تنظیمات محدودیت منابع پلن یا timeout پروکسی را تغییر نمی‌دهند. مرجع تنظیمات execution

برای تعداد زیاد item از پردازش دسته‌ای، محدودیت هم‌زمانی و timeout استفاده کنید. queue mode نیازمند طراحی worker، Redis، دیتابیس و کلید مشترک است؛ صرف تغییر EXECUTIONS_MODE روی سرویس آماده کافی نیست. راهنمای رسمی queue mode را برای معماری بزرگ‌تر ببینید.

انتقال از ایران به کلودیوا​

برای رفع محدودیت دسترسی تلگرام، مقصد خارج از ایران انتخاب کنید:

  1. در کلودیوا سرویس n8n با موقعیت خارجی بسازید؛ ابتدا نسخهٔ سازگار با مبدأ انتخاب کنید.
  2. از مبدأ بکاپ کامل و export workflowها تهیه کنید. روش ساده برای تعداد کم، import JSON و ساخت دوبارهٔ credentialها با دسترسی‌های اصلی است.
  3. برای انتقال کامل دیتابیس یا credential رمزگذاری‌شده، کلید اصلی و تنظیمات مرتبط را نیز به‌صورت محرمانه حفظ کنید. پوشش و روش بازیابی بین پنل‌ها را با پشتیبانی تطبیق دهید؛ کپی دستی دیتابیس زنده انجام ندهید.
  4. مقصد را با دامنهٔ آزمایشی، trigger دستی و bot آزمایشی بررسی کنید. workflow زمان‌بندی‌شده یا اثرگذار را هم‌زمان در دو سرویس فعال نکنید.
  5. در زمان جابه‌جایی، triggerهای مبدأ را متوقف، دامنه و URLهای عمومی مقصد را تنظیم و callbackهای OAuth و webhook فراخواننده‌ها را به‌روز کنید.
  6. workflowهای مقصد را منتشر و یک رویداد واقعی آزمایش کنید. برای تلگرام، ثبت webhook مقصد باید به همان bot production اشاره کند.
  7. تا تأیید داده‌ها و اجراها، مبدأ و بکاپ آن را نگه دارید. برای برگشت، ابتدا triggerهای مقصد را متوقف کنید تا پردازش دوگانه رخ ندهد.

اگر انتقال با خطا مواجه شد، نسخه‌های مبدأ/مقصد، نوع دیتابیس، وضعیت credential و متن خطای بدون راز را ثبت کنید. کلید رمزگذاری، bot token و API Key را در تیکت نفرستید.