تحديث n8n بدون فقد البيانات: خطوات آمنة للـ workflows

لتحديث n8n بدون فقد البيانات خذ نسخة احتياطية من قاعدة البيانات ومفتاح التشفير أولًا، واقرأ ملاحظات الإصدار لكل نسخة بين إصدارك والإصدار المستهدف، ثم غيّر رقم الإصدار المثبت وأعد التشغيل؛ وسيطبق n8n تعديلات قاعدة البيانات (migrations) تلقائيًا عند بدء التشغيل. الـ workflows وبيانات الاعتماد تعيش في قاعدة البيانات لا داخل الحاوية أو حزمة npm، لذا فالتحديث آمن طالما بقيت البيانات محفوظة وبقي مفتاح التشفير كما هو. وما تبقى هو أن تملك طريق عودة مجرَّبًا إذا أساء الإصدار الجديد التصرف.

أين تُحفظ بيانات n8n فعلًا؟

• قاعدة البيانات (ملف SQLite أو PostgreSQL): الـ workflows، وبيانات الاعتماد (مشفرة)، والمستخدمون، والوسوم، وسجل التنفيذات.

• مجلد بيانات n8n (/home/node/.n8n داخل صورة Docker، و~/.n8n في تثبيت npm): فيه ملف config الذي يحمل مفتاح التشفير إذا لم تضبطه بنفسك، وقاعدة SQLite إن كنت تستخدمها، والملفات في وضع filesystem، والعقد المجتمعية المثبتة.

• ملف متغيرات البيئة: إعدادات قاعدة البيانات، وN8N_ENCRYPTION_KEY، وعنوان الـ webhook وغيرها.

معظم قصص "التحديث مسح الـ workflows" ترجع إلى أحد سببين: إعادة إنشاء الحاوية بدون volume دائم، أو بدء النسخة بمفتاح تشفير مختلف فلم تعد قادرة على قراءة بيانات الاعتماد.

لماذا تكسر تحديثات n8n بعض الأشياء أحيانًا؟

• التغييرات الجذرية (breaking changes): بعض الإصدارات تغيّر سلوك عقد معينة، أو تحذف خيارات قديمة، أو تعيد تسمية متغيرات بيئة، أو تغيّر القيم الافتراضية. والإصدارات الرئيسية تأتي بدليل ترحيل يسرد هذه التغييرات.

• إصدارات العقد: يبقي n8n عادةً الـ workflows القائمة على إصدار العقدة الذي بُنيت به، بينما تستخدم العقد الجديدة أحدث إصدار، فقد تتصرف عقدتان متشابهتان بشكل مختلف.

• تعديلات قاعدة البيانات: تعمل تلقائيًا عند بدء التشغيل، وهي في الغالب باتجاه واحد، وقد تستغرق وقتًا على جدول تنفيذات كبير.

• متطلبات بيئة التشغيل: تثبيت npm يعتمد على إصدار Node.js مدعوم، وهذا الإصدار يتقدم مع الوقت.

• العقد المجتمعية: عقد الطرف الثالث قد تتأخر في دعم إصدار n8n الجديد.

قائمة ما قبل التحديث

1. سجّل الإصدار الذي تعمل عليه الآن.

2. اقرأ ملاحظات الإصدار لكل نسخة بين إصدارك والمستهدف وابحث عن breaking changes. راجع ملاحظات الإصدار الخاصة بنسختك بدل الاعتماد على الذاكرة أو المقالات، وهذا المقال منها.

3. خذ نسخة كاملة من قاعدة البيانات.

4. احفظ مفتاح التشفير خارج السيرفر، في مدير كلمات مرور مثلًا.

5. صدّر الـ workflows وبيانات الاعتماد عبر الـ CLI كنسخة ثانية قابلة للنقل.

6. أرشف مجلد بيانات n8n أو الـ Docker volume.

7. اختر وقتًا هادئًا، وحدد الـ workflows الحساسة للوقت لتفحصها أولًا بعد التحديث.

# 0. سجّل الإصدار الذي تعمل عليه الآن
docker compose exec n8n n8n --version

# 1. نسخة من قاعدة البيانات (PostgreSQL)
docker compose exec -T postgres pg_dump -U n8n -d n8n -Fc > n8n-db-$(date +%F).dump

# 2. تصدير قابل للنقل (بيانات الاعتماد تبقى مشفرة بمفتاحك)
docker compose exec -u node n8n n8n export:workflow --all --output=/home/node/.n8n/backups/workflows.json
docker compose exec -u node n8n n8n export:credentials --all --output=/home/node/.n8n/backups/credentials.json
docker compose cp n8n:/home/node/.n8n/backups ./n8n-backups-$(date +%F)

# 3. مفتاح التشفير: من متغيرات البيئة، أو من ملف config إذا كان مولَّدًا تلقائيًا
docker compose exec n8n printenv N8N_ENCRYPTION_KEY
docker compose exec n8n cat /home/node/.n8n/config

ملف تصدير بيانات الاعتماد يبقى مشفرًا ولا يمكن استيراده إلا في نسخة تحمل المفتاح نفسه. يوجد خيار --decrypted، لكن ملف بيانات اعتماد بنص مكشوف سرّ خطير، فتجنبه ما لم تكن هناك حاجة حقيقية. ولأرشفة الـ Docker volume أيضًا:

docker volume ls        # اعرف الاسم الحقيقي، مثل myproject_n8n_data
docker run --rm -v myproject_n8n_data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/n8n-data-$(date +%F).tgz -C /data .

للتعمق في نسخ PostgreSQL ومدة الاحتفاظ واختبار الاسترجاع، راجع دليل ضبط PostgreSQL ونسخه الاحتياطي وتأمينه على سيرفر VPS، واحتفظ بنسخة واحدة على الأقل خارج السيرفر كما في استراتيجية 3-2-1 للنسخ الاحتياطي.

تحديث n8n المثبت عبر Docker

لا تشغّل بيئة الإنتاج على الوسم latest أبدًا. ثبّت رقم إصدار محددًا في ملف .env حتى لا تؤدي إعادة تشغيل عابرة إلى تحديث مفاجئ، وحتى يكون الرجوع تعديل سطر واحد.

# في ملف .env: غيّر N8N_VERSION من الإصدار القديم إلى الإصدار الجديد المختبر
docker compose pull
docker compose up -d
docker compose logs -f n8n     # انتظر انتهاء الـ migrations

لا توقف الحاوية أثناء تنفيذ الـ migrations؛ فالتعديل المقطوع في منتصفه أصعب عطل يمكن التعافي منه. وفي وضع queue mode يجب أن تعمل النسخة الرئيسية وكل الـ workers بالإصدار نفسه، فحدّثها معًا. الترتيب الآمن: أوقف الـ workers، ودع النسخة الرئيسية تنهي التعديلات، ثم شغّل الـ workers بالإصدار الجديد:

docker compose stop n8n-worker
docker compose pull
docker compose up -d n8n
docker compose logs -f n8n          # المحرر يعمل والـ migrations انتهت
docker compose up -d n8n-worker

وإذا كنت تستخدم queue mode، فـشرح وضع queue mode في n8n يعرض ملف Compose الكامل الذي تفترضه هذه الأوامر.

تحديث n8n المثبت عبر npm

n8n --version
node --version                 # قارنه بإصدار Node.js الذي يتطلبه الإصدار الجديد
npm install -g [email protected]       # إصدار محدد وليس "latest"
sudo systemctl restart n8n     # أو: pm2 restart n8n

تحقق من متطلب Node.js في ملاحظات الإصدار قبل التثبيت. إذا تغيّر، فحدّث Node.js أولًا ثم n8n.

خطة الرجوع (Rollback)

لأن الـ migrations تغيّر بنية قاعدة البيانات، فالرجوع يعني إعادة البرنامج وقاعدة البيانات معًا إلى حالتهما السابقة. إرجاع رقم الإصدار وحده لا يكفي.

docker compose stop n8n n8n-worker
# في ملف .env: أعد N8N_VERSION إلى الإصدار السابق
docker compose exec -T postgres pg_restore -U n8n -d n8n --clean --if-exists < n8n-db-2026-10-14.dump
docker compose up -d

يوفر n8n أيضًا الأمر n8n db:revert، لكنه يتراجع عن آخر migration فقط؛ واسترجاع النسخة الاحتياطية هو الطريق الأكثر موثوقية. كل ما جرى بعد أخذ النسخة يضيع عند الاسترجاع، فاحسم قرار الرجوع بسرعة.

الاسترجاع من ملفات التصدير

إذا ضاعت قاعدة البيانات نفسها أو تلفت وفشلت النسخة الاحتياطية، فملفات JSON المصدّرة هي خطتك البديلة. شغّل نسخة n8n جديدة مع PostgreSQL وبنفس مفتاح التشفير، ثم استورد بيانات الاعتماد قبل الـ workflows حتى ترتبط ببعضها بشكل صحيح:

# على نسخة جديدة تعمل بنفس N8N_ENCRYPTION_KEY
n8n import:credentials --input=credentials.json
n8n import:workflow --input=workflows.json

ملفات التصدير لا تتضمن سجل التنفيذات، وقد تحتاج إلى إعداد المستخدمين والمشاركة وإعدادات المشاريع من جديد حسب إصدارك. راجع أي الـ workflows أصبحت نشطة بعد الاستيراد قبل أن تعيد توجيه الـ webhooks والجداول الزمنية إلى النسخة. هذا الطريق أبطأ من استرجاع نسخة قاعدة البيانات، ولهذا تأتي النسخة أولًا في قائمة ما قبل التحديث.

اختبر على سيرفر تجريبي أولًا

للنسخ التي يعتمد عليها العمل، جرّب التحديث على سيرفر ثانٍ. استرجع نسخة قاعدة بيانات الإنتاج عليه بنفس مفتاح التشفير، لكن عطّل كل الـ workflows قبل تشغيل المحرر، حتى لا يرسل سيرفر الاختبار رسائل أو يخصم مدفوعات أو يستطلع واجهات API مرة ثانية. أوامر الـ CLI قد تتغير بين الإصدارات، فتأكد منها بالأمر n8n --help على إصدارك:

# على سيرفر الاختبار، بعد استرجاع النسخة بنفس N8N_ENCRYPTION_KEY
docker compose run --rm n8n update:workflow --all --active=false

امنح سيرفر الاختبار WEBHOOK_URL ونطاقًا خاصين به، ثم نفّذ التحديث، وافتح أهم الـ workflows وشغّلها يدويًا على بيانات تجريبية. وإذا ظهر سؤال عن حجم الموارد أثناء الاختبار، فدليل متطلبات تشغيل n8n يوضح ما يحتاجه كل نوع من العمل.

فحوصات ما بعد التحديث

• المحرر يفتح ويعرض الإصدار المتوقع.

• افتح بعض بيانات الاعتماد: إن ظهرت فمفتاح التشفير صحيح.

• الـ workflows النشطة ما زالت نشطة، والجداول الزمنية تعمل في موعدها.

• الـ webhooks الإنتاجية تستجيب؛ أرسل طلبًا تجريبيًا لواحد منها.

• شغّل أهم workflow لديك وافحص مخرجات كل عقدة.

• راقب السجلات وقائمة التنفيذات الفاشلة خلال اليوم التالي.

• العقد المجتمعية تُحمَّل بدون أخطاء.

أسئلة شائعة

هل يحذف تحديث n8n الـ workflows الخاصة بي؟

لا، طالما بقيت قاعدة البيانات ومجلد البيانات محفوظين عبر التحديث. الـ workflows مخزنة في قاعدة البيانات وليس داخل البرنامج.

هل يمكنني تخطي عدة إصدارات في تحديث واحد؟

غالبًا نعم، لأن الـ migrations تعمل بالتسلسل عند بدء التشغيل. لكن اقرأ ملاحظات كل إصدار تتخطاه، فتغييراته الجذرية تنطبق عليك أيضًا.

هل أحتاج تصدير CLI إذا كانت لدي نسخة من قاعدة البيانات؟

نسخة قاعدة البيانات هي طريق الاسترجاع الأساسي. أما ملفات JSON المصدّرة فنسخة ثانية قابلة للنقل يسهل فحصها وحفظها في Git أو استيرادها في نسخة جديدة.

كل كم يجب تحديث n8n؟

إيقاع منتظم، شهريًا مثلًا، يجعل كل قفزة صغيرة. أما الإصلاحات الأمنية فطبّقها أسرع.

تحديث n8n على IM HOST

تشغّل استضافة n8n من IM HOST نسختك على سيرفر KVM مخصص بأقراص NVMe مع PostgreSQL وصلاحيات root كاملة ونسخ احتياطي يومي مجاني، فتعمل الأوامر السابقة كما هي تمامًا. وبما أن النسخة اليومية قد يكون عمرها يومًا كاملًا، خذ نسخة جديدة من قاعدة البيانات قبل كل تحديث مباشرة.