দ্বারা Matt Connor 2026-08-13 · আপডেট করা হয়েছে 2026-08-16

VPS-এ UniFi controller চালানোর সম্পূর্ণ নির্দেশিকা

Q: UniFi controller তার automatic backup কোথায় সংরক্ষণ করে?

এখানে ব্যবহৃত container image-এ backup-গুলো /config/data/backup/autobackup-এ সংরক্ষিত হয়। Host-এ এটি আপনার data path-এর সঙ্গে data/backup/autobackup-এর mapping তৈরি করে। Backup-গুলো .unf file হিসেবে থাকে, যেগুলোর নাম version ও timestamp অনুযায়ী নির্ধারিত হয়। কিছু fresh install-এ autobackup directory থাকে না। তখন scheduled backup কোনো error না দেখিয়েই কিছু লিখতে ব্যর্থ হয়। তাই schedule সেট করার এক দিন পর directory-টি list করুন। Directory খালি থাকলে নিজে তৈরি করুন। File-গুলো VPS-এর বাইরে copy করে রাখুন। কারণ একটি .unf-এ site configuration এবং administrator account থাকে।

VPS-এ UniFi Network Application চালাতে কত RAM লাগবে, MongoDB-সহ Docker কীভাবে ব্যবহার করবেন, set-inform দিয়ে Layer 3 adoption করবেন এবং কোন ports private রাখবেন জানুন।

একটি VPS-এ থাকা UniFi controller আসলে কী করে

একটি VPS-এ থাকা UniFi controller হলো এমন একটি management server, যা এটি পরিচালনা করা site-গুলো বন্ধ হয়ে গেলেও reachable থাকে। এই software হলো Ubiquiti-এর UniFi Network Application: এর পেছনে MongoDB database-সহ একটি Java program। এটি আপনার access point ও switch configure করে, তাদের statistics সংরক্ষণ করে এবং admin interface সরবরাহ করে। এটি client traffic বহন করে না।

এই শেষ বিষয়টিই নির্ধারণ করে controller কোথায় রাখা উচিত। যে office এটি পরিচালনা করে, সেই office-এর ভেতরের কোনো machine-এ controller রাখলে একই সময়ে network এবং network দেখার tool—দুটিই হারাবেন। স্থিতিশীল public address-সহ VPS-এ রাখলে এটি চালু থাকে, statistics সংগ্রহ করতে থাকে এবং এক জায়গা থেকে একাধিক site-এর device adopt করতে পারে। এর জন্য horsepower নয়, uptime প্রয়োজন।

controller offline থাকলেও adopted access point ও switch-গুলো তাদের কাছে আগে থেকে পাঠানো configuration অনুযায়ী traffic forward করতে থাকে। আপনি dashboard ও statistics হারাবেন। এ ছাড়া controller সচল থাকা প্রয়োজন এমন feature-ও কাজ করবে না, যেমন guest portal login বা controller আপনার RADIUS server হলে RADIUS (remote authentication dial-in user service)। তবে client-গুলো connected থাকবে।

একটি UniFi controller-এর কত RAM প্রয়োজন?

2 GB হলো সর্বনিম্ন সীমা, আর কেনার সময় 4 GB বেছে নিন। একই box-এ RAM ব্যবহারকারী দুটি উপাদান রয়েছে: Java এবং MongoDB। তারা একে অপরের থেকে স্বাধীনভাবে memory size নির্ধারণ করে।

Java heap-এর সর্বোচ্চ সীমা MEM_LIMIT নির্ধারণ করে। Container image-এ এর default মান 1024 MB। MongoDB হলো অন্য memory consumer। এর WiredTiger storage engine 1 GB-এর বেশি RAM-এর অর্ধেক, অথবা 256 MB—যেটি বেশি—সেই পরিমাণ cache নির্ধারণ করে। 2 GB VPS-এ এটি প্রায় 512 MB cache, 1 GB heap, JVM-এর নিজস্ব non-heap memory এবং operating system-এর memory নিয়ে গঠিত। ব্যস্ত দিনে kernel-এর out-of-memory killer দুটি process-এর একটিকে বন্ধ করে দিতে পারে। কোনো ব্যাখ্যা ছাড়া restart হলে dmesg -T | grep -i 'killed process' চালিয়ে দেখুন ঘটনাটি ঘটেছিল কি না। আপনার কাছে 2 GB থাকলে একটি swap file যোগ করুন।

CPU এবং disk-এর চাহিদা কম। 1 বা 2 vCPU কয়েক ডজন device সামলাতে পারে। শুরুতে 20 GB disk বরাদ্দ করুন এবং ব্যবহার পর্যবেক্ষণ করুন, কারণ client-এর সংখ্যা এবং কতদিন statistics সংরক্ষণ করেন তার সঙ্গে database-এর আকার বাড়ে। শুধু controller চালালে 4 GB-এর বেশিরভাগ memory অব্যবহৃত থাকে। তাই এর সঙ্গে অন্য কোনো service চালানোর পরিকল্পনা থাকলে আগে সেই service-এর প্রয়োজন অনুযায়ী resource নির্ধারণ করুন, কারণ PhotoPrism ও Immich-এর RAM-এর সর্বনিম্ন চাহিদা এক নয় এবং দুটির যেকোনো একটির চাহিদাই controller-এর চেয়ে বেশি।

একটি CPU feature গুরুত্বপূর্ণ, কিন্তু সস্তা plan-এ এটি সহজেই চোখ এড়িয়ে যায়:

grep -m1 -o avx /proc/cpuinfo

x86_64 hardware-এ MongoDB 5.0 এবং পরবর্তী সংস্করণগুলোর AVX (advanced vector extensions) প্রয়োজন। ওই command কোনো output না দিলে startup-এর সময় mongod বন্ধ হয়ে যায় এবং container বারবার restart হতে থাকে, কারণ binary এমন একটি instruction চালায় যা CPU-তে নেই। পুরোনো Intel Celeron এবং Pentium host সাধারণত এর কারণ। Hypervisor guest-এর কাছ থেকে CPU flag গোপন করলেও একই সমস্যা হয়। MongoDB 4.4-এ AVX প্রয়োজন হয় না এবং এটিই একমাত্র fallback। তবে upstream এখন আর ওই database version-এ patch দেয় না। নতুন CPU-যুক্ত host-এ স্থানান্তর করাই ভালো সমাধান। ARM VPS-এ এই সমস্যা দেখা দেয় না, কারণ AVX হলো x86 instruction set-এর অংশ এবং উভয় image-ই arm64 build প্রকাশ করে। দুটির মধ্যে বেছে নেওয়ার সময় ARM এবং x86 VPS plan-এর পার্থক্য শুধু দামের চেয়ে অনেক বেশি গুরুত্বপূর্ণ।

Docker Compose ব্যবহার করে UniFi Network Application ইনস্টল করুন

Docker ব্যবহার করলে অনিশ্চয়তা সবচেয়ে কম থাকে, কারণ distribution যে MongoDB version সরবরাহ করে সেটি নেওয়ার পরিবর্তে application-সমর্থিত একটি version নির্দিষ্ট করে রাখা যায়। সার্ভারে Docker না থাকলে আগে VPS-এ Docker ইনস্টল করুন।

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

Application লগ ইন করতে পারার আগে MongoDB-তে একজন user থাকতে হবে। Official MongoDB image প্রথমবার চালুর সময় /docker-entrypoint-initdb.d-এ পাওয়া যেকোনো script চালায়। এটি ~/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

এই script শুধু তখনই চলে, যখন database directory খালি থাকে। ভুল password দিয়ে প্রথমবার stack চালালে user-টি ভুল password-সহ তৈরি হয়। পরে compose file সম্পাদনা করলেও কিছু পরিবর্তন হয় না, কারণ script আর চালানো হয় না। এর লক্ষণ হলো application container-এ MongoDB authentication failure লগ হয়, কিন্তু web interface কখনও দেখা যায় না। নতুন install-এর ক্ষেত্রে stack বন্ধ করে ~/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

উভয় image tag ইচ্ছাকৃতভাবে নির্দিষ্ট করা হয়েছে। 10.5.67-ls141 ছিল August 2026-এ বর্তমান application release। তাই install করার সময় image-এর release list পরীক্ষা করে তখনকার বর্তমান version নির্দিষ্ট করুন। Database tag আরও গুরুত্বপূর্ণ। MongoDB নিজে থেকে major version-এর মধ্যে data file upgrade করে না। তাই mongo:latest একদিন নতুন major version টেনে আনবে, পাওয়া file খুলতে অস্বীকার করবে এবং বারবার restart হবে। Major version নির্দিষ্ট করে রাখুন এবং পরিকল্পনা অনুযায়ী পরিবর্তন করুন। UniFi Network 8.1 এবং পরবর্তী version MongoDB 3.6 থেকে 7.0 পর্যন্ত সমর্থন করে। 9.0 MongoDB 8.0-এর সমর্থন যোগ করেছে।

PUID এবং PGID-কে host-এর কোনো বাস্তব user-এর সঙ্গে মিলতে হবে। নইলে ./config-এর file এমন একটি identity-এর মালিকানাধীন হবে, যে সেগুলোতে লিখতে পারে না। আপনার মান পেতে id চালান। container image-এ PUID এবং PGID কীভাবে কাজ করে mismatch-এর লক্ষণ ব্যাখ্যা করে।

এটি চালু করে লগ পর্যবেক্ষণ করুন:

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

docker compose ps-এ উভয় container-এর অবস্থা running হিসেবে দেখা উচিত। unifi-db যদি restarting-এ আটকে থাকে, তবে কারণ হয় উপরের AVX সমস্যা, নয়তো ./db-এ permission সমস্যা। লগ স্থির হওয়ার পরে দুইটি listener পরীক্ষা করুন:

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 status code পাওয়া মানে listener bind হয়েছে এবং উত্তর দিচ্ছে। Connection refused মানে application এখনও start হচ্ছে। প্রথমবার চালু হলে ছোট VPS-এ এতে এক বা দুই মিনিট লাগতে পারে। অথবা application আদৌ start হয়নি।

প্রশাসনিক ইন্টারফেসে এটি প্রকাশ না করেই প্রবেশ করুন

উপরের ফাইলে 8443 port-টি 127.0.0.1-এ publish করা হয়েছে, তাই VPS-এর বাইরের কোনো স্থান থেকে প্রশাসনিক ইন্টারফেসে প্রবেশ করা যায় না। setup wizard চালানোর জন্য SSH-এর মাধ্যমে port-টি forward করুন:

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

সেই session খোলা রাখুন এবং https://127.0.0.1:8443-এ browse করুন। Certificate-টি self-signed, তাই browser একবার সতর্কবার্তা দেখাবে। Administrator account তৈরি করুন, site-এর নাম দিন, এবং আপাতত device adoption এড়িয়ে যান।

একজন administrator-এর জন্য SSH tunnel যথেষ্ট। একটি team-এর জন্য VPS-কে একটি private address দিন এবং ইন্টারফেসটি সেই address-এ bind করুন। নিজের VPS-এ WireGuard VPN এবং Tailscale subnet router—উভয়ই এমন একটি address দেয়, যেখানে শুধু আপনার team-এর সদস্যরা route করতে পারে। WireGuard-এর ক্ষেত্রে published port-টি 10.8.0.1:8443:8443-এ পরিবর্তন করুন, অথবা Tailscale যে address দেয় সেটি ব্যবহার করুন। একটি বিষয় মনে রাখুন: Docker এমন address-এ publish করতে পারে না, যা তখনও সিস্টেমে নেই। তাই container শুরু হওয়ার আগে tunnel interface চালু হতে হবে। তা না হলে bind error-এর কারণে container ব্যর্থ হবে।

কেন দূরবর্তী UniFi ডিভাইস adopt হবে না

ডিফল্ট অবস্থায় UniFi ডিভাইস স্থানীয় নেটওয়ার্কে UDP port 10001-এ broadcast করে তার controller খুঁজে পায়। Broadcast LAN-এর বাইরে যায় না। তাই অন্য শহরের কোনো office-এ থাকা ডিভাইস VPS-এ থাকা controller আবিষ্কার করতে পারবে না। এটি Layer 3 adoption। এখানেই অধিকাংশ ব্যবহারকারী আটকে যান। ডিভাইসটি ঠিক আছে এবং controller-ও ঠিক আছে। কিন্তু কোথায় খুঁজতে হবে, তা ডিভাইসটিকে কেউ জানায়নি।

প্রথমে controller-কে জানান, কোন address বিতরণ করতে হবে। Controller-এর Settings-এর System section-এ override option-সহ inform host setting আছে। এখানে আপনার VPS-এর public hostname অথবা IP নির্ধারণ করুন। এটি না করলে controller তার নিজের interface-এ দেখা address প্রচার করে। 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-এ adoption-এর জন্য প্রস্তুত হিসেবে দেখা যাবে। Adopt-এ click করুন। State Adopting-এ পরিবর্তিত হবে। এখানে একটি বিষয় অনেকের কাছে অপ্রত্যাশিত: সাধারণত set-inform দ্বিতীয়বার চালাতে হয়। ডিভাইসটি provisioning-এর জন্য restart হয় এবং নিজের configuration-এ সংরক্ষিত inform URL ব্যবহার করে। Controller সেটি প্রতিস্থাপন করা শেষ করেনি। State Adopting দেখানোর সময় আবার command চালালে handover সম্পূর্ণ হয়। ডিভাইসটিতে info লিখে বর্তমানে সংরক্ষিত inform URL এবং state দেখুন।

ডিভাইসটি আগে অন্য controller দ্বারা adopted হয়ে থাকলে শুধু set-inform চালালে কাজ সম্পূর্ণ হবে না। কারণ ডিভাইসটিতে এখনও আগের controller-এর credentials সংরক্ষিত থাকে। প্রথমে reset button ব্যবহার করে অথবা পুরোনো credentials দিয়ে SSH-এর মাধ্যমে set-default চালিয়ে সেটিকে factory 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 প্রদর্শন করে। ফলাফলটি hex value হিসেবে আপনার router-এর DHCP option 43 field-এ paste করুন। এরপর ওই network-এ boot করা প্রতিটি ডিভাইস SSH ছাড়াই DHCP lease থেকে controller address শিখবে। পুরোনো guide-গুলোতে suboption 1 দেখানো হয়। সেখানে 0104-এর পরে IPv4 address-এর চারটি byte hex আকারে দিতে হয়। ডিভাইসগুলো এখনও ওই format গ্রহণ করে।

আপনি site-এ DNS চালালে তৃতীয় একটি পদ্ধতিও আছে। UniFi ডিভাইস boot হওয়ার সময় unifi hostname resolve করার চেষ্টা করে। তাই unifi-এর জন্য আপনার VPS address-এ নির্দেশ করা একটি A record থাকলে কোনো ডিভাইসে আলাদাভাবে কাজ না করেই adoption করা যায়। তবে এটি তখনই কার্যকর, যখন ডিভাইসগুলো বাস্তবে যে resolver ব্যবহার করে সেটি আপনার নিয়ন্ত্রণে থাকে।

কোন UniFi port খোলা রাখবেন এবং কোনগুলো private রাখবেন

Remote site থেকে শুধু 2টি port-এ পৌঁছানো প্রয়োজন।

TCP 8080 হলো inform channel, এবং adopted প্রতিটি device এতে সংযোগ করে। এর ভেতরের payload adoption-এর সময় controller device-কে দেওয়া একটি key দিয়ে AES encrypted থাকে। তাই এখানে plain HTTP ব্যবহার করাই স্বাভাবিক সেটিং।
UDP 3478 হলো STUN (session traversal utilities for NAT)। device-গুলো controller-এ ফেরার পথ বজায় রাখতে এটি ব্যবহার করে।

VPS-এ অন্য সব port বন্ধ রাখুন।

TCP 8443 হলো admin interface। এটি কখনো public করা যাবে না। controller যে প্রতিটি site পরিচালনা করে, সেগুলোর configuration একটি password-এর সুরক্ষায় এখানে থাকে।
UDP 10001 এবং UDP 1900 হলো broadcast discovery। Broadcast Internet অতিক্রম করে না, তাই এগুলো খুলে কোনো লাভ নেই।
TCP 8880 এবং TCP 8843 হলো guest portal redirect। শুধু guest portal চালালে এগুলো খুলুন।
TCP 6789 হলো mobile speed test এবং UDP 5514 হলো remote syslog। ব্যবহার করলে এগুলো যোগ করুন।
TCP 27117 হলো MongoDB। উপরের compose file-এ database কোনো port publish করে না, তাই এটি শুধু internal Docker network-এ থাকে। এভাবেই রাখুন।

আপনার site-গুলোর static public address থাকলে শুধু সেগুলো অনুমোদন করুন:

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-এর মৌলিক বিষয়গুলো এই rule-গুলো যে default deny setup ধরে নেয়, তা ব্যাখ্যা করে।

এখানে এমন একটি ফাঁদ আছে, যা বারবার সমস্যার কারণ হয়। Docker-এর published port ufw-কে পাশ কাটায়। কোনো port publish করলে Docker সরাসরি iptables-এ NAT এবং forwarding rule লেখে। সেই traffic ufw পরিচালিত INPUT chain-এ নয়, Docker-এর নিজস্ব chain-এ filter করা হয়। তাই ufw deny 8443-এ সঠিক মনে হলেও ufw status-এ port-টি সবার জন্য খোলা থাকতে পারে। এটি অন্য একটি machine থেকে পরীক্ষা করুন, VPS নিজে থেকে নয়:

nc -vz vps.example.com 8443

Connection refusal বা timeout পাওয়াই প্রত্যাশিত ফল। Connection স্থাপিত হলে ufw যা-ই বলুক, port-টি public। নির্ভরযোগ্য সমাধানটি compose file-এই আছে: port-টি 127.0.0.1-এ অথবা কোনো tunnel address-এ publish করুন, যাতে Docker এটি কখনো public interface-এ bind না করে। DOCKER-USER chain-এ rule দিয়েও কাজ হবে। তবে bind করা সহজ, এবং rule ordering-এর ভুলে এটি অকার্যকর হবে না।

Ubiquiti-এর নিজস্ব installer সম্পর্কে কী জানা দরকার?

Ubiquiti Network Application-এর জন্য একটি Debian package প্রকাশ করে। এটি কাজ করে, কিন্তু বর্তমান Ubuntu-তে MongoDB নিয়ে একটি সমস্যা তৈরি করে, যার সমাধান distribution আর দেয় না: Ubuntu 22.04 এবং 24.04-এ কোনো MongoDB server package নেই। তাই আপনাকে MongoDB-এর নিজস্ব repository যোগ করে সংস্করণগুলো হাতে মিলিয়ে নিতে হয়। উপরের container একটি pinned tag-এ এই সংস্করণ মিলিয়ে নেয়। তাই এখানে এটিই ব্যবহার করা হয়েছে।

Ubiquiti-এর নতুন self-hosted product হলো UniFi OS Server। এটি Podman container-এ UniFi application চালায় এবং তাদের hardware console-এর মতো একই UniFi OS প্রদান করে। August 2026 অনুযায়ী, এর জন্য x86_64 Ubuntu 22.04 বা 24.04, slirp4netns-সহ Podman 4.3.1 বা পরবর্তী সংস্করণ প্রয়োজন। সর্বনিম্ন হিসেবে 2 vCPU ও 4 GB RAM এবং সুপারিশ হিসেবে 4 vCPU ও 8 GB RAM চাওয়া হয়। Installer-টি তাদের downloads page-এ একটি বিনামূল্যের Ubiquiti account-এর পেছনে রাখা আছে। তাই guide-এ paste করার মতো স্থিতিশীল one-line URL নেই। এটি uosserver নামে একটি system user তৈরি করে এবং সেই user হিসেবে container-গুলো চালায়। আপনি যদি vendor-এর নিজস্ব packaging ব্যবহার করতে চান, এটি বেছে নিন। আর নিজে version pin করতে এবং server-টি অন্য কাজের জন্যও খালি রাখতে চাইলে container stack বেছে নিন।

UniFi backup কোথায় থাকে এবং কীভাবে সার্ভারের বাইরে নেওয়া যায়

Controller আপনার Settings-এ নির্ধারিত সময়সূচি অনুযায়ী backup section-এ নিজস্ব backup তৈরি করে। একই জায়গায় কতগুলো backup রাখতে হবে, সেটিও নির্ধারণ করা যায়। ফাইলগুলো container-এর /config/data/backup/autobackup-এ তৈরি হয়, যা host-এ ~/unifi/config/data/backup/autobackup হিসেবে মাউন্ট করা আছে। ফাইলের নাম সাধারণত autobackup_10.5.67_20260813_1200_1755086400004.unf-এর মতো হয়।

ফাইলগুলো সত্যিই তৈরি হচ্ছে কি না পরীক্ষা করুন:

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

সময়সূচি নির্ধারণের এক দিন পরেও directory খালি থাকা fresh container install-এর একটি পরিচিত সমস্যা। Application-এর autobackup directory থাকা প্রত্যাশিত, কিন্তু এটি নিজে directory তৈরি করে না। ফলে scheduled job নীরবে কোনো ফাইল লিখতে পারে না। Container যে user হিসেবে চলছে, সেই user হিসেবেই directory তৈরি করুন। এরপর পরবর্তী run পর্যন্ত অপেক্ষা করুন:

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

একটি .unf file-এ site configuration এবং administrator account থাকে। তাই এটিকে cryptographic key-এর মতো সংবেদনশীল হিসেবে বিবেচনা করুন। কপি এমন একটি machine-এ নিয়ে রাখুন যা আপনার নিয়ন্ত্রণে আছে, এবং ফাইলগুলো private রাখুন:

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

Restore করার পদ্ধতি সরাসরি। নতুন install-এর setup wizard-এর প্রথম page-এ backup file থেকে restore করার option থাকে। Running controller-ও একই settings page থেকে restore গ্রহণ করে। একই version অথবা আরও নতুন version-এ restore করুন। যে application version backup তৈরি করেছে, সেটি restore করার target version-এর চেয়ে নতুন হলে backup প্রত্যাখ্যান করা হয়। তাই file-এর সঙ্গে version number-ও সংরক্ষণ করুন।

কন্ট্রোলার আপগ্রেডে কী কী নষ্ট হতে পারে

প্রতিটি আপগ্রেডের আগে ম্যানুয়াল backup নিন এবং সেটি download করুন। এরপর:

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

প্রথমে database-এই সমস্যা দেখা দেয়। অ্যাপ্লিকেশনের সঙ্গে একই edit-এ mongo tag-টি নতুন major version-এ পরিবর্তন করলে controller আর start না হওয়ার সম্ভাবনা সবচেয়ে বেশি। কারণ staged upgrade ছাড়া MongoDB ভিন্ন major version-এর data file খুলবে না। আগে শুধু অ্যাপ্লিকেশন আপগ্রেড করুন। MongoDB আলাদাভাবে, একবারে একটি major version করে সরান। হাতে একটি নতুন backup রাখুন।

পরের সমস্যা হলো memory। বড় release-এর জন্য বড় heap প্রয়োজন। অ্যাপ্লিকেশন start হয়ে কয়েক মিনিট চলার পর বন্ধ হয়ে গেলে MEM_LIMIT এবং MEM_STARTUP-এর মান 1536 বা 2048 করে restart করুন। Host-এ dmesg -T | grep -i 'killed process' চালালে kernel নিজে প্রক্রিয়াটি বন্ধ করেছে কি না নিশ্চিত হওয়া যায়।

Device firmware এমন একটি ঝুঁকি, যা অনেকে ভুলে যান। Controller নিজে আপগ্রেড হওয়ার পর adopted device-গুলোর জন্য firmware upgrade প্রস্তাব করে। একই session-এ সেগুলো গ্রহণ করবেন না। Device upgrade এবং controller upgrade একই সময়ে চললে এবং তাদের মধ্যকার link বিচ্ছিন্ন হলে device-এর provisioning অসম্পূর্ণ অবস্থায় আটকে যেতে পারে। তখন অন্য ভবনের hardware-এ SSH করে আবার set-inform চালানোর পরিস্থিতি তৈরি হবে।

Upgrade window যতটা কঠিন মনে হয়, বাস্তবে তা ততটা নয়। Controller restart হওয়ার সময় device-গুলো traffic forwarding চালিয়ে যায়, তাই ব্যবহারকারীরা কিছু টের পান না। তবে controller guest portal এবং RADIUS সরবরাহ করলে সেগুলো বন্ধ থাকে। তাই এমন সময় বেছে নিন, যখন কোনোটিই ব্যবহৃত হচ্ছে না। ভোর 3টায় নীরবে বন্ধ হয়ে যাওয়া controller-এর বিষয়টি জানা দরকার। তাই port 8080-এ একটি Uptime Kuma status monitor নির্দেশ করুন এবং সেটিকে আপনাকে জানাতে দিন।

সৎ বিকল্প: Ubiquiti-এর hosted console

Ubiquiti একই কাজ একটি service হিসেবে বিক্রি করে। August 2026 অনুযায়ী Official UniFi Cloud Console-এর দাম মাসে $29 থেকে শুরু হয় এবং এটি সর্বোচ্চ 500টি UniFi device পরিচালনা করতে পারে; Ubiquiti update ও backup চালায়। আপনি যে self-hosted applicationটি ইনস্টল করেছেন, সেটি বিনামূল্যে এবং এতে কোনো subscription নেই।

আপনি যদি একটি site পরিচালনা করেন এবং patch করার বদলে অর্থ দিতে চান, তাহলে hosted console বেছে নিন। আপনি যদি একাধিক site পরিচালনা করেন, অথবা আপনার নিয়ন্ত্রণাধীন network-এর ভেতরে controller রাখতে চান এবং আপনার চালানো অন্যান্য service-এর সঙ্গে একই box ব্যবহার করতে চান, তাহলে VPS বেছে নিন। ছোট পরিসরে খরচের পার্থক্য বাস্তব, তবে বিবেচনার বিষয় এটিই একমাত্র নয়: hosted console-এর uptime অন্য কারও দায়িত্বে থাকে, আর আপনার VPS-এর সবকিছু আপনার দায়িত্বে—যে রাতের disk পূর্ণ হয়ে যায়, সেটিও। যেভাবেই হোক box-টি যদি নিজের খরচ তুলে আনে, তাহলে VPS-এ আর কী চালানো যায়—পরেরবার পড়ার জন্য সেটিই তালিকা।

FAQ

আমার UniFi device কেন VPS-এ থাকা controller-এ adopt হচ্ছে না?

Device-গুলো UDP port 10001-এ broadcast করে controller খুঁজে পায়। Broadcast কখনও local network-এর বাইরে যায় না। তাই remote site-এর কোনো device public internet-এ থাকা controller খুঁজে পায় না। Controller-এর system settings-এ inform host override হিসেবে আপনার VPS hostname সেট করুন। এরপর ssh ubnt@<device-ip> দিয়ে device-টিকে নির্দেশ করুন এবং তারপর set-inform http://vps.example.com:8080/inform চালান। Device যদি Adopting অবস্থায় থাকে, সেই অবস্থায় আবার set-inform চালান। অন্য কোনো controller যদি আগে device-টিকে adopt করে থাকে, প্রথমে সেটিকে factory default-এ reset করুন। কারণ device-এ আগের 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-এ grep -m1 -o avx /proc/cpuinfo চালিয়ে CPU-তে AVX আছে কি না নিশ্চিত করুন। MongoDB 5.0 এবং পরবর্তী সংস্করণ AVX ছাড়া start হবে না। তখন database container বারবার restart হবে।

আমার কি port 8443 internet-এ উন্মুক্ত করা উচিত?

না। Port 8443 হলো admin interface। এখানে controller যে প্রতিটি site পরিচালনা করে, তার configuration থাকে। এটি 127.0.0.1-এ publish করুন এবং ssh -L 8443:127.0.0.1:8443 you@vps.example.com দিয়ে access করুন। অথবা এটিকে WireGuard বা Tailscale address-এ bind করুন। আপনার site-গুলো থেকে শুধু TCP 8080 এবং UDP 3478 reachable হতে হবে। Site-গুলোর public address স্থির হলে এই port-গুলো শুধু সেই address-গুলোর জন্য অনুমোদন করতে পারেন। মনে রাখবেন, Docker published port-এ ufw filtering প্রয়োগ করে না। তাই ufw status-এর ওপর নির্ভর না করে বাইরের কোনো machine থেকে পরীক্ষা করুন।

VPS controller বন্ধ হয়ে গেলে কি আমার network কাজ করা বন্ধ করবে?

না। Adopt করা access point এবং switch-গুলো controller আগে যে configuration পাঠিয়েছে, সেটি ব্যবহার করে traffic forward করতে থাকে। তাই client-গুলো connected থাকে এবং Wi-Fi কাজ করতে থাকে। বন্ধ হবে management। Dashboard ও statistics collection আর পাওয়া যাবে না। Controller যে live feature সরবরাহ করে, সেগুলোও বন্ধ হবে। যেমন guest portal authentication অথবা controller RADIUS server হলে RADIUS।

UniFi controller তার automatic backup কোথায় সংরক্ষণ করে?

এখানে ব্যবহৃত container image-এ backup-গুলো /config/data/backup/autobackup-এ সংরক্ষিত হয়। Host-এ এটি আপনার data path-এর সঙ্গে data/backup/autobackup-এর mapping তৈরি করে। Backup-গুলো .unf file হিসেবে থাকে, যেগুলোর নাম version ও timestamp অনুযায়ী নির্ধারিত হয়। কিছু fresh install-এ autobackup directory থাকে না। তখন scheduled backup কোনো error না দেখিয়েই কিছু লিখতে ব্যর্থ হয়। তাই schedule সেট করার এক দিন পর directory-টি list করুন। Directory খালি থাকলে নিজে তৈরি করুন। File-গুলো VPS-এর বাইরে copy করে রাখুন। কারণ একটি .unf-এ site configuration এবং administrator account থাকে।

#unifi#ubiquiti#network-management#docker #self-hosting