SSD Nodes Learn Hosting plans →
Посібники Matt ConnorВід Matt Connor · Оновлено 2026-08-16

Як запустити контролер UniFi на VPS

Дізнайтеся, як розмістити UniFi Network Application на VPS: скільки RAM потрібно, як налаштувати Docker і MongoDB, виконати set-inform та закрити порти.

Що насправді робить контролер UniFi на VPS

Контролер UniFi на VPS — це один сервер керування, який залишається доступним, навіть коли керовані ним сайти стають недоступними. Програмне забезпечення — UniFi Network Application від Ubiquiti: програма на Java з базою даних MongoDB. Воно налаштовує точки доступу та комутатори, зберігає їхню статистику й надає адміністративний інтерфейс. Воно не передає клієнтський трафік.

Саме це визначає, де має працювати контролер. Якщо розмістити його на машині в офісі, яким він керує, то в разі збою ви одночасно втратите мережу та інструмент для її перевірки. Якщо розмістити його на VPS зі стабільною публічною адресою, він продовжить працювати, збирати дані й приймати пристрої на кількох сайтах з одного місця. Йому потрібна безперервна доступність, а не висока обчислювальна потужність.

Коли контролер недоступний, прийняті точки доступу та комутатори продовжують передавати трафік із конфігурацією, яку їм уже передано. Ви втрачаєте інформаційну панель і статистику, а також усі функції, для яких контролер має бути доступним: вхід через гостьовий портал або RADIUS (remote authentication dial-in user service), якщо контролер виконує роль RADIUS-сервера. Клієнти залишаються підключеними.

Скільки RAM потрібно контролеру UniFi?

2 GB — це мінімум, а для купівлі слід обирати 4 GB. На одному сервері пам’ять споживають два компоненти: Java і MongoDB. Вони розподіляють пам’ять незалежно один від одного.

Розмір Java heap обмежує MEM_LIMIT. За замовчуванням container image встановлює це значення на рівні 1024 MB. Другу частину споживання становить MongoDB. Її storage engine WiredTiger виділяє для cache половину RAM понад 1 GB або 256 MB — залежно від того, яке значення більше. На VPS із 2 GB це приблизно 512 MB cache, 1 GB heap, власна non-heap memory JVM і пам’ять для operating system. Система працює, доки навантаження не зростає. Після цього kernel out-of-memory killer завершує один із двох процесів. Після будь-якого незрозумілого перезапуску виконайте dmesg -T | grep -i 'killed process', щоб перевірити, чи це стало причиною. Якщо у вас лише 2 GB, додайте swap file.

Вимоги до CPU і диска невисокі. Один або два vCPU достатні для кількох десятків пристроїв. Почніть із 20 GB дискового простору та стежте за його використанням. Розмір бази даних залежить від кількості клієнтів і тривалості зберігання статистики. Сам контролер залишає більшу частину сервера з 4 GB незадіяною. Якщо ви плануєте розмістити на ньому ще один сервіс, спочатку визначте вимоги для нього, оскільки PhotoPrism та Immich мають дуже різні мінімальні вимоги до RAM, і кожному з них потрібно більше пам’яті, ніж контролеру.

Є одна важлива функція CPU, яку легко не врахувати на дешевому тарифі:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 і новіші версії потребують AVX (advanced vector extensions) на обладнанні x86_64. Якщо команда не виводить нічого, mongod завершується під час запуску, а container перезапускається в циклі. Це відбувається тому, що binary виконує інструкцію, якої немає в CPU. Найчастіше причина — старі хости Intel Celeron і Pentium або hypervisor, який приховує CPU flags від guest. MongoDB 4.4 не потребує AVX і є єдиним fallback, але upstream більше не випускає для цієї версії database patches. Кращий варіант — перенести сервіс на хост із новішим CPU. На ARM VPS це питання не виникає, оскільки AVX — це набір інструкцій x86, а обидва images мають builds для arm64. Якщо ви обираєте між цими варіантами, відмінності між ARM і x86 VPS тарифами важливіші за ціну.

Встановлення UniFi Network Application за допомогою 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 приватну адресу та прив’яжіть інтерфейс до неї. WireGuard VPN на власному VPS і маршрутизатор підмережі Tailscale надають адресу, доступну лише вашим користувачам. Змініть опублікований порт на 10.8.0.1:8443:8443 для WireGuard або використайте адресу, яку призначає Tailscale. Є одна важлива особливість: Docker не може опублікувати порт на адресі, якої ще не існує. Тому tunnel-інтерфейс має бути запущений до старту контейнера, інакше контейнер завершить роботу з помилкою прив’язування.

Чому віддалений пристрій UniFi не проходить adopt

За замовчуванням пристрій UniFi знаходить свій controller через broadcast у локальній мережі, UDP-порт 10001. Broadcast не виходить за межі LAN, тому пристрій в офісі в іншому місті ніколи не виявить controller на VPS. Це Layer 3 adoption, і саме на цьому етапі найчастіше виникають проблеми. Пристрій справний, і controller справний. Просто ніхто не повідомив пристрою, куди надсилати запити.

Спочатку вкажіть controller адресу, яку потрібно передавати пристроям. У Settings controller, у розділі System, є параметр inform host з опцією override. Укажіть публічне ім’я хоста або IP-адресу вашого VPS. Якщо цього не зробити, controller передаватиме адресу, яку бачить на власному інтерфейсі. У Docker bridge network це приватна адреса, наприклад 172.18.0.3. Пристрій отримує цю адресу, не може маршрутизувати до неї трафік і знову починає пошук.

Потім вкажіть цю адресу самому пристрою. Підключіться до пристрою через SSH у віддаленій LAN. Пристрій із заводськими налаштуваннями приймає ім’я користувача 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

Тепер пристрій з’явиться в controller у стані готовності до adoption. Натисніть Adopt, і стан зміниться на Adopting. Ось що часто стає несподіванкою: зазвичай потрібно виконати set-inform ще раз. Пристрій перезапускається для provisioning і використовує inform URL, збережений у власній конфігурації. Controller ще не встиг завершити його заміну. Повторне виконання команди, коли стан має значення Adopting, завершує передавання керування. Виконайте на пристрої info, щоб переглянути inform URL і поточний стан.

Якщо раніше пристрій уже був adopted іншим controller, самої команди set-inform буде недостатньо, оскільки пристрій усе ще зберігає облікові дані того controller. Спочатку скиньте його до заводських налаштувань кнопкою reset або виконайте set-default через SSH, використовуючи старі облікові дані.

Для більшої кількості пристроїв використовуйте DHCP. DHCP (dynamic host configuration protocol), option 43, передає значення, специфічне для виробника, а пристрої UniFi отримують inform URL із suboption 2. Сформуйте hex-рядок на будь-якому 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 byte, команда виводить 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Вставте результат у поле DHCP option 43 на router як hex-значення. Після цього кожен пристрій, який запускається в цій мережі, отримує адресу controller з DHCP lease без використання SSH. У старіших інструкціях замість цього вказано suboption 1: 0104, після якого передаються чотири bytes IPv4-адреси у hex. Пристрої досі приймають і такий формат.

Є ще один варіант, якщо на сайті працює DNS. Під час запуску пристрій UniFi намагається розв’язати hostname unifi, тому A record для unifi, що вказує на адресу вашого VPS, дає змогу виконати adoption без окремого налаштування кожного пристрою. Цей спосіб працює лише тоді, коли ви контролюєте resolver, який фактично використовують пристрої.

Які порти UniFi потрібно відкрити, а які залишити приватними

Лише два порти мають бути доступними з віддаленого майданчика.

  • TCP 8080 — це inform-канал, до якого підключається кожен adopted-пристрій. Дані всередині зашифровані AES ключем, який controller передав пристрою під час adoption. Тому стандартним налаштуванням для цього каналу є звичайний HTTP.
  • UDP 3478 — це STUN (session traversal utilities for NAT). Пристрої використовують його, щоб підтримувати зворотний шлях до controller.

На VPS усі інші порти мають залишатися закритими.

  • TCP 8443 — це адміністративний інтерфейс. Він ніколи не має бути публічним. У ньому зберігається конфігурація всіх site, якими керує controller, захищена одним паролем.
  • UDP 10001 і UDP 1900 — це broadcast discovery. Broadcast-пакети не проходять через інтернет, тому відкривати ці порти немає сенсу.
  • TCP 8880 і TCP 8843 — це перенаправлення до guest portal. Відкривайте їх лише якщо використовуєте guest portal.
  • TCP 6789 — це mobile speed test, а UDP 5514 — remote syslog. Додайте їх, якщо використовуєте ці функції.
  • TCP 27117 — це MongoDB. У наведеному вище compose-файлі database не публікує жодного порту, тому доступна лише у внутрішній Docker network. Залиште все саме так.

Якщо ваші site мають статичні публічні адреси, дозвольте доступ лише з них:

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 для firewall VPS описують налаштування заборони доступу за замовчуванням, на якому ґрунтуються ці правила.

Тут є пастка, у яку щоразу потрапляють багато користувачів. Опубліковані Docker порти обходять ufw. Публікація порту безпосередньо записує правила NAT і forwarding в 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 і узгоджувати версії. Наведений вище контейнер виконує це узгодження в одному зафіксованому тезі, тому саме цей варіант використано тут.

Новіший self-hosted продукт Ubiquiti — UniFi OS Server. Він запускає застосунки UniFi у контейнерах Podman і надає таку саму UniFi OS, як і їхні апаратні консолі. Станом на серпень 2026 року для нього потрібна система x86_64 з Ubuntu 22.04 або 24.04, Podman версії 4.3.1 або новішої з slirp4netns. Мінімальні вимоги — 2 vCPU і 4 GB RAM; рекомендовані — 4 vCPU і 8 GB RAM. Інсталятор доступний за безкоштовним обліковим записом 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 містить конфігурацію site та облікові записи адміністраторів, тому поводьтеся з ним як із криптографічним ключем. Копіюйте резервні файли на контрольований вами комп’ютер і зберігайте їх у приватному місці:

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

Відновлення виконується в один крок. На першій сторінці майстра налаштування нової інсталяції можна відновити дані з файлу резервної копії. Для запущеного контролера це можна зробити на тій самій сторінці Settings. Відновлюйте дані в ту саму або новішу версію. Резервна копія, створена новішою версією застосунку, ніж версія, у яку виконується відновлення, буде відхилена. Тому разом із файлом слід записувати номер версії.

Що може зламатися під час оновлення контролера

Перед кожним оновленням створюйте резервну копію вручну та завантажуйте її. Потім:

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' на хості підтвердить, чи саме kernel завершив процес.

Про ризик із firmware пристроїв часто забувають. Після самостійного оновлення контролер пропонує оновити firmware прийнятих пристроїв. Не погоджуйтеся на це в тому самому сеансі. Якщо оновлення пристрою та контролера накладаються в часі й зв’язок між ними переривається, пристрій може залишитися частково налаштованим, і вам знову доведеться виконувати set-inform через SSH на обладнанні в іншій будівлі.

Саме вікно оновлення менш проблемне, ніж може здатися. Пристрої продовжують пересилати network traffic, поки контролер перезапускається, тому користувачі нічого не помічають. Зупиняються guest portal і RADIUS, якщо їх обслуговує контролер, тому виберіть час, коли вони не використовуються. Варто знати, якщо контролер непомітно завершив роботу о 3 a.m., тому налаштуйте моніторинг стану в Uptime Kuma для порту 8080 і доручіть йому повідомити вас.

Чесна альтернатива: хостована консоль Ubiquiti

Ubiquiti пропонує такий самий варіант як сервіс. Станом на August 2026 Official UniFi Cloud Console коштує від $29 на місяць і керує до 500 UniFi devices, а Ubiquiti самостійно виконує оновлення та резервне копіювання. Self-hosted застосунок, який ви щойно встановили, безкоштовний і не потребує передплати.

Оберіть хостовану консоль, якщо керуєте одним сайтом і готові платити замість самостійного встановлення патчів. Оберіть VPS, якщо керуєте кількома сайтами або хочете розмістити controller у мережі, яку контролюєте, на одному сервері з іншими сервісами. На малому масштабі різниця у вартості помітна, але це не єдиний критерій: доступність хостованої консолі залежить від чужої інфраструктури, а VPS належить вам — разом із ніччю, коли на його диску закінчиться місце. Якщо сервер у будь-якому разі має виправдовувати витрати, далі варто прочитати що ще можна запускати на VPS.

FAQ

Чому мій пристрій UniFi не приймається контролером на VPS?

Пристрої виявляють контролери через широкомовні повідомлення на UDP-порті 10001. Таке повідомлення не виходить за межі локальної мережі, тому пристрій на віддаленому майданчику не може знайти контролер у публічному інтернеті. У системних налаштуваннях контролера задайте перевизначення inform host на ім’я хоста VPS, а потім вкажіть пристрою цей хост за допомогою ssh ubnt@<device-ip>, а після цього set-inform http://vps.example.com:8080/inform. Якщо пристрій завис у стані Adopting, повторно виконайте set-inform, поки він перебуває в цьому стані. Якщо раніше пристрій уже прийняв інший контролер, спочатку скиньте його до заводських налаштувань, оскільки він досі зберігає облікові дані старого контролера.

Скільки RAM потрібно self-hosted контролеру UniFi?

Два GB — мінімальний робочий обсяг, а 4 GB забезпечують комфортну роботу. Застосунок працює на Java та MongoDB, і кожен із них окремо використовує пам’ять: за замовчуванням container image обмежує Java heap до 1024 MB, а кеш WiredTiger у MongoDB займає половину обсягу RAM понад 1 GB. На x86_64 також перевірте, чи процесор підтримує AVX, за допомогою grep -m1 -o avx /proc/cpuinfo, оскільки MongoDB 5.0 і новіші версії не запускаються без цієї підтримки, а database container перезапускається в циклі.

Чи слід відкривати порт 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 продовжує працювати. Припиняється лише керування. Ви втрачаєте dashboard і збирання статистики, а також роботу функцій, які безпосередньо надає контролер, наприклад автентифікацію через гостьовий портал або RADIUS, якщо контролер виконує роль RADIUS-сервера.

Де контролер UniFi зберігає автоматичні резервні копії?

У використаному тут container image вони зберігаються в /config/data/backup/autobackup. Цей шлях відповідає шляху до даних плюс data/backup/autobackup на хості, у вигляді файлів .unf з назвами, що містять версію та часову позначку. У деяких нових інсталяціях каталог autobackup відсутній. У такому разі заплановане резервне копіювання не записує нічого й не повідомляє про помилку. Через день після налаштування розкладу перевірте цей каталог і створіть його самостійно, якщо він порожній. Скопіюйте файли з VPS, оскільки .unf містить конфігурацію сайту та облікові записи адміністраторів.

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