लेखक: Matt Connor 2026-08-13 · अपडेट किया गया: 2026-08-16

VPS पर UniFi Controller कैसे सेटअप करें

Q: UniFi controller अपने automatic backups कहाँ store करता है?

यहाँ उपयोग की गई container image में वे /config/data/backup/autobackup में जाते हैं, जो host पर आपके data path और data/backup/autobackup से map होता है, जहाँ वे वर्ज़न और timestamp के नाम वाली .unf files के रूप में होते हैं। कुछ नए installs पर autobackup directory मौजूद नहीं होती है, और ऐसी स्थिति में scheduled backup बिना किसी error की सूचना दिए कुछ भी save नहीं करता है, इसलिए schedule सेट करने के एक दिन बाद उस directory को check करें और यदि वह खाली है तो उसे स्वयं बनाएँ। Files को VPS से बाहर copy कर लें, क्योंकि .unf में site configuration और administrator accounts होते हैं।

VPS पर UniFi Network Application होस्ट करने का तरीका जानें। इसमें Docker और MongoDB कॉन्फ़िगरेशन, RAM की आवश्यकता, set-inform कमांड और सुरक्षित पोर्ट्स की पूरी जानकारी दी गई है।

VPS पर UniFi controller वास्तव में क्या करता है

VPS पर स्थित UniFi controller एक ऐसा प्रबंधन सर्वर है जो उन साइटों के डाउन होने पर भी चालू रहता है जिनका यह प्रबंधन करता है। यह सॉफ़्टवेयर Ubiquiti का UniFi Network Application है: एक Java प्रोग्राम जिसके पीछे MongoDB डेटाबेस होता है। यह आपके access points और switches को कॉन्फ़िगर करता है, उनके आँकड़े (statistics) संग्रहीत करता है, और एडमिन इंटरफ़ेस प्रदान करता है। यह क्लाइंट ट्रैफ़िक को प्रोसेस नहीं करता है।

यह अंतिम बिंदु तय करता है कि इसे कहाँ रखा जाना चाहिए। यदि आप controller को उस कार्यालय के भीतर किसी मशीन पर रखते हैं जिसका यह प्रबंधन करता है, तो नेटवर्क के डाउन होते ही आप उस टूल को भी खो देंगे जिससे आप नेटवर्क की स्थिति देख सकते हैं। यदि आप इसे एक स्थिर public IP पते वाले VPS पर रखते हैं, तो यह चलता रहता है, डेटा एकत्र करता रहता है, और एक ही स्थान से कई साइटों के उपकरणों को adopt कर सकता है। इसे उच्च प्रोसेसिंग पावर के बजाय निरंतर uptime की आवश्यकता होती है।

जब controller ऑफ़लाइन होता है, तो adopt किए गए access points और switches पहले से पुश की गई कॉन्फ़िगरेशन के साथ ट्रैफ़िक को फॉरवर्ड करना जारी रखते हैं। आप डैशबोर्ड और आँकड़े खो देते हैं, साथ ही ऐसी कोई भी सुविधा जो controller के चालू रहने पर निर्भर करती है: जैसे guest portal लॉगिन, या RADIUS (remote authentication dial-in user service) यदि controller आपका RADIUS सर्वर है। क्लाइंट्स कनेक्टेड रहते हैं।

UniFi controller को कितनी RAM की आवश्यकता होती है?

2 GB न्यूनतम आवश्यकता है और 4 GB वह मात्रा है जिसे आपको खरीदना चाहिए। एक बॉक्स में दो मेमोरी उपभोक्ता होते हैं, Java और MongoDB, और वे एक-दूसरे से स्वतंत्र रूप से अपना आकार निर्धारित करते हैं।

Java heap की सीमा MEM_LIMIT द्वारा तय होती है, जिसे container image डिफ़ॉल्ट रूप से 1024 MB पर सेट करती है। MongoDB दूसरा हिस्सा है। इसका WiredTiger storage engine अपने cache का आकार 1 GB से ऊपर की RAM के आधे हिस्से पर, या 256 MB, जो भी अधिक हो, पर सेट करता है। 2 GB के VPS पर यह लगभग 512 MB cache, 1 GB heap, JVM की अपनी non-heap मेमोरी और ऑपरेटिंग सिस्टम को मिलाकर होता है। यह सामान्य दिनों में ठीक चलता है, लेकिन व्यस्त दिनों में kernel का out-of-memory killer इन दो प्रक्रियाओं में से एक को समाप्त कर देता है। किसी भी अस्पष्ट restart के बाद, यह पता लगाने के लिए कि क्या यही हुआ था, dmesg -T | grep -i 'killed process' चलाएँ। यदि आपके पास 2 GB ही है, तो एक swap file जोड़ें।

CPU और disk की आवश्यकताएं कम हैं। एक या दो vCPU कुछ दर्जन उपकरणों को संभाल सकते हैं। 20 GB disk से शुरुआत करें और उस पर नज़र रखें, क्योंकि database का आकार आपके द्वारा देखे जाने वाले clients की संख्या और आप आँकड़ों (statistics) को कितने समय तक रखते हैं, इस पर निर्भर करता है। एक controller अकेले 4 GB के बॉक्स का अधिकांश हिस्सा खाली रखता है, इसलिए यदि आप इसे किसी अन्य service के साथ चलाना चाहते हैं, तो पहले उस दूसरी service के लिए आकार निर्धारित करें, क्योंकि PhotoPrism और Immich की RAM आवश्यकताएं बहुत अलग हैं और उनमें से कोई भी controller से अधिक RAM की मांग कर सकता है।

CPU की एक विशेषता मायने रखती है, और सस्ते प्लान में इसे नज़रअंदाज़ करना आसान है:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 और उसके बाद के संस्करणों को x86_64 हार्डवेयर पर AVX (advanced vector extensions) की आवश्यकता होती है। यदि वह command कुछ भी प्रिंट नहीं करती है, तो startup के दौरान mongod बंद हो जाता है और container लूप में restart होता रहता है, क्योंकि binary एक ऐसा instruction चलाती है जो CPU में नहीं है। पुराने Intel Celeron और Pentium होस्ट इसके सामान्य कारण हैं, साथ ही ऐसे hypervisors भी जो guest से CPU flags छिपाते हैं। MongoDB 4.4 को AVX की आवश्यकता नहीं होती है और यही एकमात्र विकल्प है, लेकिन यह database का वह संस्करण है जिसे upstream अब पैच नहीं करता है। नए CPU वाले होस्ट पर जाना बेहतर समाधान है। ARM VPS पर यह प्रश्न उत्पन्न नहीं होता है, क्योंकि AVX एक x86 instruction set है, और दोनों images arm64 builds प्रकाशित करती हैं। यदि आप दोनों के बीच चयन कर रहे हैं, तो ARM और x86 VPS प्लान के बीच के अंतर केवल कीमत से कहीं अधिक हैं।

Docker Compose के साथ UniFi Network Application इंस्टॉल करें

Docker सबसे सुरक्षित तरीका है, क्योंकि यह आपको MongoDB को उस वर्ज़न पर पिन करने की सुविधा देता है जिसे एप्लिकेशन सपोर्ट करती है, बजाय इसके कि आप अपनी डिस्ट्रिब्यूशन द्वारा प्रदान किए गए वर्ज़न पर निर्भर रहें। यदि Docker अभी तक सर्वर पर नहीं है, तो पहले VPS पर Docker इंस्टॉल करें।

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 अगस्त 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 के रूप में दिखने चाहिए। restarting में फंसा हुआ unifi-db या तो ऊपर बताई गई 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

उस सेशन को खुला रखें और https://127.0.0.1:8443 पर ब्राउज़ करें। सर्टिफिकेट सेल्फ-साइन्ड है, इसलिए ब्राउज़र एक बार चेतावनी देगा। एडमिनिस्ट्रेटर अकाउंट बनाएँ, साइट का नाम रखें और अभी के लिए डिवाइस एडॉप्शन को छोड़ दें।

एक एडमिनिस्ट्रेटर के लिए SSH टनल ठीक है। यदि टीम है, तो VPS को एक प्राइवेट एड्रेस दें और इंटरफेस को उस पर बाइंड करें। अपने खुद के VPS पर WireGuard VPN और Tailscale सबनेट राउटर दोनों आपको एक ऐसा एड्रेस देते हैं जिस पर केवल आपके लोग ही रूट कर सकते हैं। WireGuard के लिए पब्लिश पोर्ट को 10.8.0.1:8443:8443 में बदलें, या Tailscale द्वारा असाइन किए गए एड्रेस का उपयोग करें। एक समस्या यह है कि Docker ऐसे एड्रेस पर पब्लिश नहीं कर सकता जो अभी मौजूद नहीं है, इसलिए कंटेनर शुरू होने से पहले टनल इंटरफेस का चालू होना आवश्यक है, अन्यथा कंटेनर बाइंड एरर के साथ फेल हो जाएगा।

रिमोट UniFi डिवाइस adopt क्यों नहीं होता है

UniFi डिवाइस डिफ़ॉल्ट रूप से local network पर UDP port 10001 का उपयोग करके broadcast के माध्यम से अपने controller को खोजता है। Broadcast LAN से बाहर नहीं जाता है, इसलिए किसी दूसरे शहर के ऑफिस में लगा डिवाइस VPS पर मौजूद controller को कभी नहीं खोज पाएगा। इसे Layer 3 adoption कहते हैं, और यहीं पर अधिकांश लोग अटक जाते हैं। डिवाइस और controller दोनों सही स्थिति में होते हैं, लेकिन डिवाइस को यह नहीं पता होता कि उसे कहाँ देखना है।

सबसे पहले, controller को यह बताएं कि उसे कौन सा address देना है। Controller की Settings में, System section के अंतर्गत, एक inform host setting होती है जिसमें override का विकल्प होता है। इसे अपने VPS के public hostname या IP पर सेट करें। इसके बिना, controller उस address का विज्ञापन करता है जिसे वह अपने interface पर देखता है, जो Docker bridge network के अंदर 172.18.0.3 जैसा एक private address होता है। डिवाइस को वह address मिलता है, वह उस तक route नहीं कर पाता, और वापस खोज शुरू कर देता है।

इसके बाद, डिवाइस को उस address की ओर निर्देशित करें। Remote LAN पर मौजूद डिवाइस में SSH करें। Factory default डिवाइस ubnt username और ubnt password स्वीकार करता है:

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

नए device firmware में आपको shell के बजाय एक menu मिलता है। वही निर्देश एक single command के रूप में चलाएं:

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

अब डिवाइस controller में adopt होने के लिए तैयार दिखाई देगा। Adopt पर क्लिक करें, और स्थिति Adopting में बदल जाएगी। यहाँ वह हिस्सा है जो सबको हैरान करता है: आपको आमतौर पर set-inform को दूसरी बार चलाना पड़ता है। डिवाइस provisioning के लिए restart होता है और अपनी configuration में सेव inform URL पर वापस चला जाता है, जिसे controller ने अभी तक पूरी तरह से बदला नहीं होता है। जब स्थिति Adopting दिखाई दे रही हो, तब command को दोबारा चलाने से handover पूरा हो जाता है। डिवाइस पर inform URL और उसकी वर्तमान स्थिति देखने के लिए info टाइप करें।

यदि डिवाइस पहले किसी अन्य controller द्वारा adopt किया गया था, तो केवल set-inform से काम पूरा नहीं होगा, क्योंकि उसमें अभी भी पुराने controller के credentials मौजूद होते हैं। पहले उसे factory default पर reset करें, या तो reset button से या पुराने credentials का उपयोग करके SSH के माध्यम से set-default चलाकर।

यदि उपकरणों की संख्या अधिक है, तो इसके बजाय DHCP का उपयोग करें। DHCP (dynamic host configuration protocol) option 43 में एक vendor-specific value होती है, और UniFi डिवाइस suboption 2 से inform URL पढ़ लेते हैं। किसी भी Linux box पर hex string बनाएं:

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 byte की string है, यह 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d प्रिंट करता है। इस परिणाम को अपने router के DHCP option 43 field में hex value के रूप में पेस्ट करें। उस network पर boot होने वाला हर डिवाइस अपने lease से controller का address जान लेगा, और आपको SSH करने की आवश्यकता नहीं होगी। पुराने guides में suboption 1 का उपयोग दिखाया गया है, जिसमें 0104 के बाद IPv4 address के चार bytes hex में लिखे जाते हैं, और डिवाइस अभी भी उस format को स्वीकार करते हैं।

यदि आप उस site पर DNS चलाते हैं, तो एक तीसरा रास्ता भी है। UniFi डिवाइस boot होने पर unifi hostname को resolve करने का प्रयास करता है, इसलिए unifi के लिए एक A record जो आपके VPS address की ओर इशारा करता हो, बिना किसी device-level कार्य के डिवाइस को adopt कर लेगा। यह केवल तभी काम करता है जब आप उस resolver को नियंत्रित करते हैं जिसका उपयोग डिवाइस वास्तव में करते हैं।

UniFi के किन ports को open रखें और किन को private रखें

रिमोट साइट से केवल दो ports तक पहुँच होनी चाहिए।

TCP 8080 inform channel है, और हर adopted device इससे connect होता है। इसके अंदर का payload उस key के साथ AES encrypted होता है जो controller ने adoption के दौरान device को दी थी, इसीलिए यहाँ plain HTTP सामान्य setting है।
UDP 3478 STUN (session traversal utilities for NAT) है, जिसका उपयोग devices controller तक का रास्ता बनाए रखने के लिए करते हैं।

बाकी सब कुछ VPS पर बंद रहना चाहिए।

TCP 8443 admin interface है। इसे कभी भी public नहीं होना चाहिए। इसमें controller द्वारा manage की जाने वाली हर साइट की configuration एक password के पीछे सुरक्षित रहती है।
UDP 10001 और UDP 1900 broadcast discovery के लिए हैं। Broadcasts internet के पार नहीं जाते, इसलिए इन्हें open करने का कोई लाभ नहीं है।
TCP 8880 और TCP 8843 guest portal redirects हैं। इन्हें केवल तभी open करें यदि आप guest portal चला रहे हैं।
TCP 6789 mobile speed test के लिए है और UDP 5514 remote syslog के लिए है। जब आप इनका उपयोग करें, तभी इन्हें add करें।
TCP 27117 MongoDB है। ऊपर दिए गए compose file में database कोई भी port publish नहीं करता है, इसलिए यह केवल internal Docker network पर मौजूद रहता है। इसे वैसा ही रहने दें।

यदि आपकी साइट्स के पास static public addresses हैं, तो केवल उन्हीं को allow करें:

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

VPS firewall के लिए ufw की बुनियादी जानकारी उन default deny setup को कवर करती है जिन्हें ये rules मानकर चलते हैं।

यहाँ एक ऐसी समस्या है जिसमें लोग अक्सर फंस जाते हैं। Docker के published ports ufw को दरकिनार कर देते हैं। Port publish करने पर NAT और forwarding rules सीधे iptables में लिख दिए जाते हैं, और वह traffic Docker की अपनी chain में filter होता है, न कि उस INPUT chain में जिसे ufw manage करता है। इसलिए ufw deny 8443 देखने में ufw status में सही लग सकता है, जबकि वह port दुनिया के लिए open रहता है। इसे किसी दूसरी machine से test करें, कभी भी खुद VPS से नहीं:

nc -vz vps.example.com 8443

आपको connection refusal या timeout मिलना चाहिए। यदि यह connect हो जाता है, तो ufw की setting चाहे जो भी हो, port public है। इसका विश्वसनीय समाधान वही है जो पहले से compose file में दिया गया है: port को 127.0.0.1 या tunnel address पर publish करें, ताकि Docker उसे कभी भी public interface पर bind न करे। DOCKER-USER chain में एक rule भी काम करता है, लेकिन binding अधिक सरल है, और rule ordering की गलती इसे undo नहीं कर सकती।

Ubiquiti के अपने इंस्टालर के बारे में क्या?

Ubiquiti, Network Application के लिए एक Debian पैकेज प्रकाशित करता है। यह काम करता है, लेकिन वर्तमान Ubuntu पर यह MongoDB से जुड़ा एक ऐसा प्रश्न खड़ा करता है जिसका उत्तर अब distribution नहीं देता है: Ubuntu 22.04 और 24.04 में कोई MongoDB सर्वर पैकेज नहीं आता है, इसलिए आपको अंततः MongoDB की अपनी repository जोड़नी पड़ती है और संस्करणों (versions) का मिलान मैन्युअल रूप से करना पड़ता है। ऊपर दिया गया container उस मिलान को एक ही pinned tag में पूरा कर देता है, इसीलिए यहाँ इसी तरीके को अपनाया गया है।

Ubiquiti का नया self-hosted उत्पाद UniFi OS Server है, जो UniFi applications को Podman containers में चलाता है और आपको वही UniFi OS देता है जो उनके हार्डवेयर कंसोल में होता है। अगस्त 2026 तक, इसके लिए x86_64 Ubuntu 22.04 या 24.04, slirp4netns के साथ Podman 4.3.1 या उससे नया संस्करण चाहिए, और यह न्यूनतम 2 vCPU के साथ 4 GB RAM, तथा अनुशंसित 4 vCPU के साथ 8 GB RAM की मांग करता है। इंस्टालर उनके डाउनलोड पेज पर एक मुफ्त Ubiquiti अकाउंट के पीछे स्थित है, इसलिए गाइड में पेस्ट करने के लिए कोई स्थिर वन-लाइन URL उपलब्ध नहीं है। यह uosserver नामक एक सिस्टम यूजर बनाता है और containers को उसी यूजर के रूप में चलाता है। यदि आप वेंडर की अपनी पैकेजिंग चाहते हैं तो इसे चुनें। यदि आप स्वयं संस्करणों को पिन करना चाहते हैं और सर्वर को अन्य कार्यों के लिए खाली रखना चाहते हैं, तो container stack चुनें।

UniFi बैकअप कहाँ रहते हैं, और उन्हें सर्वर से बाहर कैसे निकालें

Controller आपके द्वारा 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 फाइल में साइट कॉन्फ़िगरेशन और एडमिनिस्ट्रेटर अकाउंट्स होते हैं, इसलिए इसे एक cryptographic key की तरह सुरक्षित रखें। इसकी प्रतियाँ अपने नियंत्रण वाली मशीन पर डाउनलोड करें और उन्हें निजी रखें:

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

रिस्टोर करना एक आसान प्रक्रिया है। नए इंस्टॉलेशन पर सेटअप विज़ार्ड का पहला पेज बैकअप फाइल से रिस्टोर करने का विकल्प देता है, और एक चल रहे controller में उसी सेटिंग्स पेज से रिस्टोर किया जा सकता है। उसी वर्जन या उससे नए वर्जन में रिस्टोर करें। यदि बैकअप उस एप्लिकेशन वर्जन से बनाया गया है जो वर्तमान में चल रहे वर्जन से नया है, तो उसे रिजेक्ट कर दिया जाएगा, इसीलिए फाइल के साथ वर्जन नंबर को रिकॉर्ड करना आवश्यक है।

Controller upgrade से क्या-क्या खराब हो सकता है

हर upgrade से पहले एक manual backup लें और उसे download करें। उसके बाद:

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

Database सबसे पहले खराब होने वाली चीज है। Application के साथ ही mongo tag को एक नए major version में बदलना, controller के start न होने का सबसे तेज़ तरीका है, क्योंकि MongoDB बिना staged upgrade के अलग major version की data files को open नहीं करेगा। Application को अकेले upgrade करें। MongoDB को अलग से, एक बार में एक major version करके, और हाथ में ताज़ा backup लेकर upgrade करें।

Memory अगली समस्या है। बड़े release को बड़े heap की आवश्यकता होती है। यदि application start होता है, कुछ मिनट चलता है और फिर बंद हो जाता है, तो MEM_LIMIT और MEM_STARTUP को 1536 या 2048 तक बढ़ाएँ और restart करें। Host पर dmesg -T | grep -i 'killed process' यह पुष्टि करता है कि क्या kernel ने ही इसे बंद किया है।

Device firmware वह जोखिम है जिसे लोग भूल जाते हैं। Controller के खुद upgrade होने के बाद, वह adopted devices के लिए firmware upgrades का सुझाव देता है। उन्हें एक ही session में स्वीकार न करें। यदि device upgrade और controller upgrade एक साथ होते हैं और उनके बीच का link टूट जाता है, तो device आधा-अधूरा provisioned रह सकता है, और आपको दूसरी इमारत में स्थित hardware पर SSH के माध्यम से set-inform करना पड़ सकता है।

Upgrade की प्रक्रिया सुनने में जितनी कठिन लगती है, उतनी है नहीं। Controller के restart होने के दौरान भी devices traffic forward करना जारी रखते हैं, इसलिए users को कुछ पता नहीं चलता। जो सेवाएँ रुक जाती हैं, वे हैं guest portal और RADIUS (यदि controller उन्हें serve करता है), इसलिए ऐसा समय चुनें जब इनका उपयोग न हो रहा हो। रात के 3 बजे चुपचाप बंद होने वाले controller के बारे में पता होना ज़रूरी है, इसलिए port 8080 पर an Uptime Kuma status monitor लगाएँ और उसे आपको सूचित करने दें।

एक ईमानदार विकल्प: Ubiquiti का hosted console

Ubiquiti इसी काम को एक सेवा के रूप में बेचता है। अगस्त 2026 तक, Official UniFi Cloud Console की कीमत $29 प्रति माह से शुरू होती है और यह 500 तक UniFi devices को manage कर सकता है, जिसमें updates और backups की जिम्मेदारी Ubiquiti की होती है। जो self-hosted application आपने अभी install की है, वह मुफ्त है और इसमें कोई subscription नहीं है।

यदि आप केवल एक site manage करते हैं और patch करने के बजाय भुगतान करना पसंद करते हैं, तो hosted console चुनें। यदि आप कई sites manage करते हैं, या आप controller को अपने नियंत्रण वाले network के भीतर रखना चाहते हैं और उसे अन्य services के साथ एक ही box पर चलाना चाहते हैं, तो VPS चुनें। छोटे स्तर पर लागत का अंतर वास्तविक है, लेकिन यह विचार करने वाली एकमात्र चीज नहीं है: hosted console का uptime किसी और की जिम्मेदारी है, जबकि VPS आपका अपना है, जिसमें वह रात भी शामिल है जब इसकी disk भर जाती है। यदि box को किसी भी तरह से अपना खर्च निकालना है, तो VPS पर आप और क्या चला सकते हैं वह सूची है जिसे आपको आगे पढ़ना चाहिए।

FAQ

मेरा UniFi device VPS पर मौजूद controller के साथ adopt क्यों नहीं हो रहा है?

Devices UDP port 10001 पर broadcast करके controllers को खोजते हैं, और broadcast कभी भी local network से बाहर नहीं जाता है, इसलिए किसी remote site पर मौजूद device public internet पर स्थित controller को नहीं ढूंढ सकता है। Controller की system settings में inform host override को अपने VPS hostname पर सेट करें, फिर device पर ssh ubnt@<device-ip> के बाद set-inform http://vps.example.com:8080/inform चलाकर उसे point करें। यदि device Adopting state में अटका हुआ है, तो उस दौरान फिर से set-inform चलाएं। यदि किसी अन्य controller ने इसे पहले adopt किया था, तो पहले इसे factory default पर reset करें, क्योंकि इसमें पुराने controller के credentials मौजूद होते हैं।

self-hosted UniFi controller को कितनी RAM की आवश्यकता होती है?

2 GB न्यूनतम आवश्यकता है और 4 GB पर्याप्त है। यह application Java और MongoDB का मिश्रण है, और दोनों अपनी memory का आकार अलग-अलग निर्धारित करते हैं: container image डिफ़ॉल्ट रूप से Java heap को 1024 MB पर सीमित रखती है, जबकि MongoDB का WiredTiger cache 1 GB से ऊपर की RAM का आधा हिस्सा ले लेता है। x86_64 पर, यह भी सुनिश्चित करें कि CPU grep -m1 -o avx /proc/cpuinfo के साथ AVX को expose करता है, क्योंकि MongoDB 5.0 और उसके बाद के वर्ज़न इसके बिना start नहीं होंगे और database container बार-बार restart होता रहेगा।

क्या मुझे port 8443 को internet पर expose करना चाहिए?

नहीं। Port 8443 admin interface है, और इसमें controller द्वारा manage किए जाने वाले हर site का configuration होता है। इसे 127.0.0.1 पर publish करें और ssh -L 8443:127.0.0.1:8443 you@vps.example.com के माध्यम से access करें, या इसे WireGuard या Tailscale address पर bind करें। केवल TCP 8080 और UDP 3478 को ही आपकी sites से reachable होने की आवश्यकता है, और यदि sites के public addresses static हैं, तो आप उन्हें केवल उन तक सीमित कर सकते हैं। याद रखें कि Docker द्वारा published port ufw द्वारा filter नहीं होता है, इसलिए ufw status पर भरोसा करने के बजाय किसी बाहरी machine से test करें।

यदि VPS controller down हो जाए तो क्या मेरा network काम करना बंद कर देता है?

नहीं। Adopt किए गए access points और switches उस configuration का उपयोग करके traffic forward करना जारी रखते हैं जिसे controller पहले ही push कर चुका है, इसलिए clients connected रहते हैं और Wi-Fi काम करता रहता है। जो रुक जाता है वह है management। आप dashboard और statistics collection खो देते हैं, साथ ही controller द्वारा प्रदान की जाने वाली कोई भी live सुविधा, जैसे कि guest portal authentication या RADIUS (यदि controller ही RADIUS server है)।

UniFi controller अपने automatic backups कहाँ store करता है?

यहाँ उपयोग की गई container image में वे /config/data/backup/autobackup में जाते हैं, जो host पर आपके data path और data/backup/autobackup से map होता है, जहाँ वे वर्ज़न और timestamp के नाम वाली .unf files के रूप में होते हैं। कुछ नए installs पर autobackup directory मौजूद नहीं होती है, और ऐसी स्थिति में scheduled backup बिना किसी error की सूचना दिए कुछ भी save नहीं करता है, इसलिए schedule सेट करने के एक दिन बाद उस directory को check करें और यदि वह खाली है तो उसे स्वयं बनाएँ। Files को VPS से बाहर copy कर लें, क्योंकि .unf में site configuration और administrator accounts होते हैं।

#unifi#ubiquiti#network-management#Docker #सेल्फ़-होस्टिंग