بقلم Matt Connor 2026-08-13 · آخر تحديث في 2026-08-16

تشغيل متحكم UniFi على خادم VPS

Q: أين تخزّن وحدة تحكم UniFi نسخها الاحتياطية التلقائية؟

في صورة الحاوية المستخدمة هنا، تُحفظ النسخ في /config/data/backup/autobackup، الذي يُربط بمسار بياناتك مضافاً إليه data/backup/autobackup على المضيف، بوصفها ملفات .unf تحمل اسم الإصدار وطابعاً زمنياً. في بعض عمليات التثبيت الجديدة، لا يكون الدليل autobackup موجوداً، وعندها لا تنشئ النسخة الاحتياطية المجدولة أي ملف من دون الإبلاغ عن خطأ. لذلك اعرض محتويات هذا الدليل بعد يوم من ضبط الجدولة، وأنشئه بنفسك إذا كان فارغاً. انسخ الملفات إلى خارج VPS، لأن ملف .unf يحتوي على إعدادات الموقع وحسابات المسؤولين.

تعرف إلى متطلبات تشغيل UniFi Network Application على VPS، ولماذا تحتاج إلى 4 جيجابايت RAM، وكيفية استخدام Docker وMongoDB واعتماد الأجهزة عبر set-inform، مع إبقاء المنافذ الحساسة خاصة.

ما الذي يفعله متحكم UniFi فعلياً على VPS

متحكم UniFi على VPS هو خادم إدارة واحد يظل قابلاً للوصول عندما تتوقف المواقع التي يديرها. البرنامج هو UniFi Network Application من Ubiquiti: برنامج Java تقف خلفه قاعدة بيانات MongoDB. يضبط نقاط الوصول والمبدّلات لديك، ويخزّن إحصاءاتها، ويعرض واجهة الإدارة. لكنه لا ينقل حركة مرور العملاء.

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

عندما يكون المتحكم غير متصل، تواصل نقاط الوصول والمبدّلات المعتمدة تمرير حركة المرور باستخدام الإعدادات التي دُفعت إليها مسبقاً. ستفقد لوحة المعلومات والإحصاءات، إضافة إلى أي ميزة تحتاج إلى أن يكون المتحكم قيد التشغيل، مثل تسجيل الدخول عبر بوابة الضيوف أو RADIUS (خدمة مستخدمي الاتصال الهاتفي للمصادقة عن بُعد) إذا كان المتحكم هو خادم RADIUS لديك. وتبقى الأجهزة العميلة متصلة.

كم يحتاج متحكم UniFi من ذاكرة RAM؟

2 GB هو الحد الأدنى، و4 GB هي السعة التي ينبغي شراؤها. يوجد مستهلكان للذاكرة في الخادم نفسه، هما Java وMongoDB، ويحدّد كل منهما احتياجاته بشكل مستقل عن الآخر.

يُحدَّد الحد الأقصى لذاكرة Java heap بواسطة MEM_LIMIT، وتضبطه صورة الحاوية على 1024 MB افتراضياً. أما النصف الآخر فهو MongoDB. يضبط محرك التخزين WiredTiger ذاكرة التخزين المؤقت على نصف RAM المتاحة فوق 1 GB، أو 256 MB، أيهما أكبر. في VPS بسعة 2 GB، يعني ذلك تقريباً 512 MB للتخزين المؤقت، إضافة إلى heap بسعة 1 GB، وذاكرة JVM الخاصة خارج heap، ونظام التشغيل. يعمل ذلك إلى أن يأتي يوم يرتفع فيه الحمل، ثم ينهي قاتل نفاد الذاكرة في النواة إحدى العمليتين. بعد أي إعادة تشغيل غير مفسَّرة، شغّل dmesg -T | grep -i 'killed process' للتحقق مما إذا كان ذلك قد حدث. أضف ملف swap إذا كانت السعة المتاحة لديك هي 2 GB.

لا تتطلب وحدة المعالجة المركزية والقرص موارد كبيرة. تكفي vCPU واحدة أو اثنتان للتعامل مع بضع عشرات من الأجهزة. ابدأ بسعة قرص قدرها 20 GB وراقب استخدامها، لأن قاعدة البيانات تكبر مع عدد العملاء الذين تراهم ومع مدة الاحتفاظ بالإحصاءات. يترك المتحكم وحده معظم خادم بسعة 4 GB دون استخدام، لذلك إذا كنت تخطط لتشغيل خدمة أخرى معه، فحدّد الموارد وفقاً للخدمة الأخرى أولاً، لأن PhotoPrism وImmich لهما حدّان أدنى مختلفان كثيراً لذاكرة RAM، وكل واحدة منهما تحتاج إلى سعة أكبر من المتحكم.

توجد ميزة واحدة في وحدة المعالجة المركزية مهمة، ومن السهل إغفالها في الخطط الرخيصة:

grep -m1 -o avx /proc/cpuinfo

تحتاج MongoDB 5.0 والإصدارات الأحدث إلى AVX (امتدادات المتجهات المتقدمة) على أجهزة x86_64. إذا لم يطبع ذلك الأمر أي شيء، تتوقف mongod أثناء بدء التشغيل وتُعاد حاويتها في حلقة، لأن الملف الثنائي ينفّذ تعليمة لا تدعمها وحدة المعالجة المركزية. تُعد مضيفات Intel Celeron وPentium الأقدم السبب المعتاد، وكذلك برامج Hypervisor التي تخفي أعلام وحدة المعالجة المركزية عن الضيف. لا تحتاج MongoDB 4.4 إلى AVX، وهي البديل الوحيد، لكن هذا إصدار قاعدة بيانات لم يعد المشروع الأصلي يوفّر له تصحيحات. الانتقال إلى مضيف مزوّد بوحدة معالجة مركزية أحدث هو الحل الأفضل. لا يطرح الأمر نفسه على VPS يعمل بمعمارية ARM، لأن AVX مجموعة تعليمات خاصة بـx86، كما أن كلتا الصورتين توفّران إصدارات arm64. إذا كنت تختار بين الخيارين، فإن الفروق بين خطط VPS بمعمارية ARM وx86 تتجاوز السعر.

ثبّت تطبيق UniFi Network باستخدام Docker Compose

يُعد Docker الخيار الأقل عرضة للمفاجآت، لأنّه يتيح لك تثبيت MongoDB على إصدار يدعمه التطبيق بدلاً من استخدام الإصدار الذي توفّره توزيعتك. إذا لم يكن Docker مثبتاً على الخادم بعد، فـثبّت Docker على VPS أولاً.

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

يحتاج MongoDB إلى مستخدم قبل أن يتمكن التطبيق من تسجيل الدخول. تشغّل صورة MongoDB الرسمية أي برنامج نصي تجده في /docker-entrypoint-initdb.d عند التشغيل الأول. احفظ ما يلي باسم ~/unifi/init-mongo.sh:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

يُشغَّل هذا البرنامج النصي فقط عندما يكون مجلد قاعدة البيانات فارغاً. إذا بدأت الحزمة مرة واحدة باستخدام كلمة المرور الخاطئة، فسيُنشأ المستخدم بهذه الكلمة، ولن يؤدي تعديل ملف Compose بعد ذلك إلى تغيير شيء، لأن البرنامج النصي لن يُشغَّل مجدداً. يتمثل العَرَض في تسجيل حاوية التطبيق أخطاء مصادقة MongoDB، بينما لا تظهر واجهة الويب إطلاقاً. في التثبيت الجديد، أوقف الحزمة، واحذف ~/unifi/db، ثم شغّلها مجدداً.

اكتب بعد ذلك ~/unifi/compose.yaml:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

تم تثبيت وسمَي الصورتين عمداً. كان 10.5.67-ls141 هو إصدار التطبيق الحالي في August 2026، لذلك تحقّق من قائمة إصدارات الصورة وثبّت الإصدار الحالي عند التثبيت. وسم قاعدة البيانات أهم. لا يرقّي MongoDB ملفات بياناته تلقائياً بين الإصدارات الرئيسية، لذلك سيجلب mongo:latest يوماً ما إصداراً رئيسياً جديداً، ويرفض فتح الملفات الموجودة، ثم يعيد التشغيل في حلقة متكررة. ثبّت الإصدار الرئيسي وانقله بصورة مقصودة. تدعم UniFi Network 8.1 والإصدارات الأحدث MongoDB من 3.6 إلى 7.0، وأضاف الإصدار 9.0 دعم MongoDB 8.0.

يجب أن يتطابق PUID وPGID مع مستخدم فعلي على الخادم، وإلا ستصبح الملفات الموجودة ضمن ./config مملوكة لهوية لا تستطيع الكتابة فيها. شغّل id لمعرفة القيم الخاصة بك. يوضّح كيفية عمل PUID وPGID في صور الحاويات شكل المشكلة عند عدم التطابق.

شغّلها وراقب السجل:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

يجب أن يعرض docker compose ps الحاويتين بالحالة running. تكون unifi-db العالقة في restarting ناتجة إما عن مشكلة AVX المذكورة أعلاه أو عن مشكلة صلاحيات في ./db. بعد استقرار السجل، تحقّق من المستمعَين:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

يعني ظهور أي رمز حالة HTTP أن المستمع مرتبط بمنفذ ويستجيب. يعني Connection refused أن التطبيق لا يزال قيد التشغيل، وقد يستغرق ذلك دقيقة أو دقيقتين على VPS صغير عند التشغيل الأول، أو أن التطبيق لم يبدأ مطلقاً.

الوصول إلى واجهة الإدارة دون تعريضها للعامة

المنفذ 8443 منشور على 127.0.0.1 في الملف أعلاه، لذلك لا يمكن لأي جهة خارج VPS الوصول إلى واجهة الإدارة. مرّره عبر SSH لتشغيل معالج الإعداد:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

اترك جلسة SSH مفتوحة وانتقل إلى https://127.0.0.1:8443. الشهادة موقّعة ذاتياً، لذلك يعرض المتصفح تحذيراً مرة واحدة. أنشئ حساب المسؤول، وسمِّ الموقع، وتخطَّ اعتماد الأجهزة الآن.

يُعد نفق SSH مناسباً لمسؤول واحد. أما إذا كان لديك فريق، فامنح VPS عنواناً خاصاً واربط الواجهة بهذا العنوان بدلاً من ذلك. يوفّر كل من VPN من نوع WireGuard على VPS تملكه وموجّه شبكة فرعية من Tailscale عنواناً يمكن لأفراد فريقك فقط الوصول إليه عبر التوجيه. غيّر المنفذ المنشور إلى 10.8.0.1:8443:8443 في حالة WireGuard، أو إلى العنوان الذي يعيّنه Tailscale. انتبه إلى أن Docker لا يستطيع النشر على عنوان غير موجود بعد، لذلك يجب أن تصبح واجهة النفق متاحة قبل بدء الحاوية، وإلا تفشل الحاوية بسبب خطأ في الربط.

لماذا لا يعتمد جهاز UniFi البعيد

يبحث جهاز UniFi افتراضياً عن وحدة التحكم عبر البث في الشبكة المحلية، باستخدام منفذ UDP ‏10001. لا يغادر البث الشبكة المحلية، لذلك لن يكتشف جهاز موجود في مكتب بمدينة أخرى وحدة تحكم تعمل على VPS. هذا هو الاعتماد عبر Layer 3، وهنا يواجه معظم المستخدمين المشكلة. الجهاز سليم ووحدة التحكم سليمة. لم يحدد أي شيء للجهاز المكان الذي يجب أن يبحث فيه.

أولاً، حدّد لوحدة التحكم العنوان الذي يجب أن توزّعه. في إعدادات وحدة التحكم، ضمن قسم System، يوجد إعداد inform host مع خيار override. اضبطه على اسم المضيف العام أو عنوان IP العام لـVPS. إذا لم تفعل ذلك، تعلن وحدة التحكم العنوان الذي تراه على واجهتها الخاصة. داخل شبكة Docker bridge يكون هذا عنواناً خاصاً مثل 172.18.0.3. يتلقى الجهاز هذا العنوان، ولا يستطيع توجيه traffic إليه، ثم يعود إلى البحث.

بعد ذلك، وجّه الجهاز إلى هذا العنوان. اتصل بالجهاز عبر SSH من الشبكة المحلية البعيدة. يقبل الجهاز الذي في حالة الإعداد الافتراضية اسم المستخدم ubnt وكلمة المرور ubnt:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

تفتح إصدارات firmware الأحدث قائمة بدلاً من shell. شغّل الأمر نفسه كأمر واحد:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

يظهر الجهاز الآن في وحدة التحكم بحالة جاهز للاعتماد. انقر على Adopt، فتتغير الحالة إلى Adopting. الجزء المفاجئ هنا هو أنّه يجب عليك عادةً تشغيل set-inform مرة ثانية. يعيد الجهاز التشغيل للدخول في عملية provisioning، ثم يعود إلى عنوان inform المحفوظ في إعداداته الخاصة، والذي لم تُكمل وحدة التحكم استبداله بعد. يؤدي تشغيل الأمر مرة أخرى أثناء ظهور الحالة Adopting إلى إكمال التسليم. اكتب info على الجهاز لعرض عنوان inform والحالة المحفوظين حالياً.

إذا كان الجهاز قد اعتمدته وحدة تحكم أخرى من قبل، فلن يكمل set-inform العملية وحده، لأن الجهاز لا يزال يحتفظ ببيانات اعتماد وحدة التحكم السابقة. أعده أولاً إلى إعدادات المصنع الافتراضية، إما باستخدام زر reset أو باستخدام set-default عبر SSH ببيانات الاعتماد القديمة.

إذا كان لديك أكثر من بضعة أجهزة، فاستخدم DHCP بدلاً من ذلك. يحمل خيار DHCP (dynamic host configuration protocol) رقم 43 قيمة خاصة بالمورّد، وتقرأ أجهزة UniFi عنوان inform من suboption 2. أنشئ السلسلة السداسية على أي جهاز Linux:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

بالنسبة إلى http://192.168.3.10:8080/inform، وهي سلسلة من 31 بايت، يطبع الأمر 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. الصق النتيجة في حقل DHCP option 43 في الموجّه باعتبارها قيمة سداسية. يتعلم كل جهاز يقلع على تلك الشبكة عنوان وحدة التحكم من lease الخاص به، من دون استخدام SSH إطلاقاً. تعرض الأدلة الأقدم suboption 1 بدلاً من ذلك، أي 0104 متبوعاً بالبايتات الأربعة لعنوان IPv4 بصيغة سداسية، ولا تزال الأجهزة تقبل هذا الشكل.

يوجد مسار ثالث إذا كنت تدير DNS في الموقع. يحاول جهاز UniFi حل اسم المضيف unifi عند الإقلاع، لذلك يؤدي إنشاء سجل A للاسم unifi وتوجيهه إلى عنوان VPS إلى اعتماد الأجهزة من دون إعداد كل جهاز على حدة. لا يفيد ذلك إلا في المواقع التي تتحكم فيها بمحلّل الأسماء الذي تستخدمه الأجهزة فعلياً.

منافذ UniFi التي يجب فتحها، والمنافذ التي يجب إبقاؤها خاصة

يجب أن يكون منفذان فقط قابلين للوصول من موقع بعيد.

TCP 8080 هو قناة inform، وتتصل به كل الأجهزة المعتمدة. تكون البيانات التي تحملها مشفّرة باستخدام AES بمفتاح منحه المتحكم للجهاز أثناء الاعتماد، ولذلك يكون HTTP العادي هو الإعداد المعتاد هنا.
UDP 3478 هو STUN (أدوات اجتياز الجلسات لـNAT)، وتستخدمه الأجهزة للحفاظ على مسار عودة إلى المتحكم.

تبقى جميع المنافذ الأخرى مغلقة على VPS.

TCP 8443 هو واجهة الإدارة. يجب ألا يكون هذا المنفذ متاحاً للعامة أبداً. فهو يحتوي على إعدادات كل المواقع التي يديرها المتحكم، خلف كلمة مرور واحدة.
UDP 10001 وUDP 1900 مخصصان لاكتشاف الأجهزة عبر البث. لا تعبر عمليات البث الإنترنت، لذلك لا يحقق فتحهما أي فائدة.
TCP 8880 وTCP 8843 مخصصان لإعادة توجيه بوابة الضيوف. افتحهما فقط إذا كنت تشغّل بوابة ضيوف.
TCP 6789 مخصص لاختبار سرعة الاتصال عبر الهاتف المحمول، وUDP 5514 مخصص لـremote syslog. أضفهما عند استخدامهما.
TCP 27117 هو MongoDB. في ملف compose أعلاه، لا تنشر قاعدة البيانات أي منافذ، ولذلك فهي موجودة فقط على شبكة Docker الداخلية. أبقها كذلك.

إذا كانت مواقعك تستخدم عناوين عامة ثابتة، فاسمح لهذه العناوين فقط:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

تغطي أساسيات ufw لجدار حماية VPS إعداد الرفض الافتراضي الذي تفترضه هذه القواعد.

توجد هنا مشكلة خفية تتسبب في إرباك المستخدمين في كل مرة. تتجاوز المنافذ التي ينشرها Docker قواعد ufw. يؤدي نشر منفذ إلى كتابة قواعد NAT وإعادة التوجيه مباشرة في iptables، وتُرشَّح حركة المرور هذه في سلسلة Docker الخاصة، وليس في سلسلة INPUT التي يديرها ufw. لذلك تبدو ufw deny 8443 صحيحة في ufw status، بينما يبقى المنفذ مفتوحاً للعالم. اختبر ذلك من جهاز آخر، وليس من VPS نفسه:

nc -vz vps.example.com 8443

الرفض أو انتهاء المهلة هو النتيجة المطلوبة. إذا تم الاتصال، فالمنفذ متاح للعامة بغض النظر عما يقوله ufw. الحل الموثوق هو الحل الموجود مسبقاً في ملف compose: انشر المنفذ على 127.0.0.1 أو على عنوان نفق، حتى لا يربطه Docker بالواجهة العامة. يعمل أيضاً وضع قاعدة في سلسلة DOCKER-USER، لكن الربط أبسط، ولا يمكن لخطأ في ترتيب القواعد إلغاء أثره.

ماذا عن أدوات التثبيت الخاصة بـUbiquiti؟

تنشر Ubiquiti حزمة Debian لتطبيق Network Application. تعمل هذه الحزمة، لكنها تطرح على Ubuntu الحالي سؤالاً يتعلق بـMongoDB لا تجيب عنه التوزيعة بعد الآن: لا يتضمن Ubuntu 22.04 و24.04 حزمة خادم MongoDB، لذلك ينتهي بك الأمر إلى إضافة مستودع MongoDB الخاص ومطابقة الإصدارات يدوياً. تنفّذ الحاوية أعلاه هذه المطابقة ضمن وسم واحد مثبّت، ولذلك فهي المسار المعتمد هنا.

منتج Ubiquiti الأحدث للاستضافة الذاتية هو UniFi OS Server. يشغّل هذا المنتج تطبيقات UniFi داخل حاويات Podman، ويوفّر لك نظام UniFi OS نفسه المتاح في وحدات التحكم العتادية الخاصة بها. اعتباراً من August 2026، يتطلب المنتج Ubuntu 22.04 أو 24.04 على بنية x86_64، وPodman 4.3.1 أو أحدث مع slirp4netns. كما يتطلب 2 vCPU و4 GB من RAM كحد أدنى، ويوصى باستخدام 4 vCPU و8 GB. يتوفر برنامج التثبيت خلف حساب Ubiquiti مجاني في صفحة التنزيلات الخاصة بها، لذلك لا يوجد عنوان URL ثابت من سطر واحد يمكن لصقه في الدليل. ينشئ البرنامج مستخدم نظام باسم uosserver، ويشغّل الحاويات بهذا المستخدم. اختره إذا كنت تريد حزم المورّد نفسه. اختر مكدس الحاويات إذا كنت تريد تثبيت الإصدارات بنفسك وإبقاء الخادم متاحاً لأعمال أخرى.

مكان نسخ UniFi الاحتياطية وكيفية إخراجها من الخادم

يكتب المتحكم نسخه الاحتياطية وفق جدول تحدده في Settings، ضمن قسم النسخ الاحتياطي، مع تحديد عدد النسخ التي يجب الاحتفاظ بها. تُحفظ الملفات في /config/data/backup/autobackup داخل الحاوية، وهو المسار ~/unifi/config/data/backup/autobackup على المضيف، وتكون أسماؤها بالصيغة autobackup_10.5.67_20260813_1200_1755086400004.unf.

تحقق من ظهورها فعلياً:

ls -l ~/unifi/config/data/backup/autobackup

يُعد بقاء الدليل فارغاً بعد مرور يوم على ضبط الجدول مشكلة معروفة في عمليات تثبيت الحاويات الجديدة. يتوقع التطبيق وجود الدليل autobackup ولا ينشئه، لذلك تكتب المهمة المجدولة لا شيء بصمت. أنشئ الدليل بنفسك باستخدام المستخدم الذي تعمل الحاوية بحسابه، ثم انتظر التشغيل التالي:

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

يحتوي ملف .unf على إعدادات الموقع وحسابات المسؤولين، لذلك تعامل معه مثل مفتاح تشفير. اسحب نسخاً منه إلى جهاز تتحكم فيه واحتفظ بها بشكل خاص:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

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

ما الذي يمكن أن يتعطل أثناء ترقية وحدة التحكم

أنشئ نسخة احتياطية يدوية ونزّلها قبل كل ترقية. ثم:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

قاعدة البيانات هي أول ما يتعطل عادةً. إن تغيير وسم mongo إلى إصدار رئيسي جديد في التعديل نفسه الذي يحدّث التطبيق هو أسرع طريقة للوصول إلى وحدة تحكم لا تبدأ، لأن MongoDB لا يفتح ملفات بيانات من إصدار رئيسي مختلف من دون ترقية مرحلية. حدّث التطبيق وحده. وانقل MongoDB بشكل منفصل، إصداراً رئيسياً واحداً في كل مرة، مع الاحتفاظ بنسخة احتياطية جديدة.

الذاكرة هي المشكلة التالية. يحتاج الإصدار الأكبر إلى heap أكبر. إذا بدأ التطبيق، وعمل بضع دقائق، ثم توقف، فارفع MEM_LIMIT وMEM_STARTUP إلى 1536 أو 2048 ثم أعد التشغيل. يؤكد dmesg -T | grep -i 'killed process' على المضيف ما إذا كانت النواة هي التي أنهت العملية.

البرنامج الثابت للأجهزة هو الخطر الذي ينساه الناس. بعد أن تُرقّي وحدة التحكم نفسها، ستعرض ترقيات للبرنامج الثابت للأجهزة المعتمدة. لا توافق عليها في الجلسة نفسها. إذا تزامنت ترقية جهاز مع ترقية وحدة التحكم وانقطع الرابط بينهما، فقد يبقى الجهاز في حالة تهيئة جزئية، وستعود إلى set-inform عبر SSH على جهاز موجود في مبنى آخر.

نافذة الترقية نفسها أقل إزعاجاً مما تبدو. تواصل الأجهزة تمرير حركة الشبكة أثناء إعادة تشغيل وحدة التحكم، لذلك لا يلاحظ المستخدمون شيئاً. لكن بوابة الضيوف وRADIUS يتوقفان إذا كانت وحدة التحكم تقدّمهما، لذا اختر وقتاً لا يستخدمهما فيه أحد. من المفيد معرفة ما إذا توقفت وحدة التحكم بصمت عند الساعة 3 صباحاً، لذلك وجّه مراقب حالة Uptime Kuma إلى المنفذ 8080 ودعه يخبرك.

البديل الصريح: وحدة التحكم المستضافة من Ubiquiti

توفّر Ubiquiti الوظيفة نفسها كخدمة. اعتباراً من August 2026، تبدأ Official UniFi Cloud Console بسعر $29 شهرياً، وتدير ما يصل إلى 500 جهاز من UniFi، بينما تتولى Ubiquiti تشغيل التحديثات والنسخ الاحتياطية. أما التطبيق المستضاف ذاتياً الذي ثبّتَّه للتو فهو مجاني ولا يتطلب اشتراكاً.

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

FAQ

لماذا لا يتبنّى جهاز UniFi وحدة تحكم مستضافة على VPS؟

تكتشف الأجهزة وحدات التحكم عبر البث على منفذ UDP 10001. ولا يغادر البث الشبكة المحلية، لذلك لا يستطيع جهاز في موقع بعيد العثور على وحدة تحكم على الإنترنت العام. عيّن تجاوز مضيف inform في إعدادات النظام بوحدة التحكم إلى اسم مضيف VPS، ثم وجّه الجهاز إليه باستخدام ssh ubnt@<device-ip> متبوعاً بـ set-inform http://vps.example.com:8080/inform. إذا بقي الجهاز في حالة Adopting، فنفّذ set-inform مرة أخرى أثناء وجوده فيها. إذا كانت وحدة تحكم أخرى قد تبنّت الجهاز من قبل، فأعد ضبطه إلى إعدادات المصنع أولاً، لأنه لا يزال يحتفظ ببيانات اعتماد وحدة التحكم القديمة.

ما مقدار RAM الذي تحتاج إليه وحدة تحكم UniFi مستضافة ذاتياً؟

يُعد 2 GB الحد الأدنى العملي، بينما يكون 4 GB مريحاً. التطبيق مبني على Java إضافة إلى MongoDB، ويحدّد كل منهما حجم الذاكرة بصورة مستقلة. تحدد صورة الحاوية كومة Java بسعة 1024 MB افتراضياً، بينما تستخدم ذاكرة التخزين المؤقت WiredTiger في MongoDB نصف RAM التي تتجاوز 1 GB. على x86_64، تحقّق أيضاً من أن وحدة المعالجة المركزية توفّر AVX باستخدام grep -m1 -o avx /proc/cpuinfo، لأن MongoDB 5.0 والإصدارات الأحدث لن تبدأ بدونه، وستُعاد حاوية قاعدة البيانات تشغيلها في حلقة متكررة.

هل ينبغي أن أعرّض المنفذ 8443 للإنترنت؟

لا. المنفذ 8443 هو واجهة الإدارة، ويحتوي على إعدادات كل موقع تديره وحدة التحكم. انشره على 127.0.0.1 ثم اتصل به باستخدام ssh -L 8443:127.0.0.1:8443 you@vps.example.com، أو اربطه بعنوان WireGuard أو Tailscale. لا يلزم أن تكون مواقعك قادرة على الوصول إلا إلى TCP 8080 وUDP 3478، ويمكنك تقييدهما بعناوين المواقع العامة عندما تكون ثابتة. تذكّر أن المنفذ المنشور بواسطة Docker لا يخضع للتصفية عبر ufw، لذلك اختبر من جهاز خارج الشبكة بدلاً من الاعتماد على ufw status.

هل تتوقف شبكتي عن العمل إذا تعطلت وحدة تحكم VPS؟

لا. تواصل نقاط الوصول والمبدّلات التي تم تبنّيها تمرير حركة الشبكة باستخدام الإعدادات التي دفعتها وحدة التحكم إليها مسبقاً، لذلك يبقى العملاء متصلين وتستمر شبكة Wi-Fi في العمل. ما يتوقف هو الإدارة. ستفقد لوحة المعلومات وجمع الإحصاءات، إضافة إلى أي ميزة فورية تقدمها وحدة التحكم، مثل مصادقة بوابة الضيوف أو RADIUS عندما تكون وحدة التحكم هي خادم RADIUS.

أين تخزّن وحدة تحكم UniFi نسخها الاحتياطية التلقائية؟

في صورة الحاوية المستخدمة هنا، تُحفظ النسخ في /config/data/backup/autobackup، الذي يُربط بمسار بياناتك مضافاً إليه data/backup/autobackup على المضيف، بوصفها ملفات .unf تحمل اسم الإصدار وطابعاً زمنياً. في بعض عمليات التثبيت الجديدة، لا يكون الدليل autobackup موجوداً، وعندها لا تنشئ النسخة الاحتياطية المجدولة أي ملف من دون الإبلاغ عن خطأ. لذلك اعرض محتويات هذا الدليل بعد يوم من ضبط الجدولة، وأنشئه بنفسك إذا كان فارغاً. انسخ الملفات إلى خارج VPS، لأن ملف .unf يحتوي على إعدادات الموقع وحسابات المسؤولين.

#unifi#ubiquiti#network-management#Docker #استضافة ذاتية