Cómo instalar UniFi Network Application en un VPS

Qué hace realmente un controlador UniFi en un VPS

Un controlador UniFi en un VPS es un servidor de gestión que sigue siendo accesible cuando los sitios que administra dejan de estar disponibles. El software es UniFi Network Application de Ubiquiti: un programa Java con una base de datos MongoDB detrás. Configura los puntos de acceso y switches, almacena sus estadísticas y ofrece la interfaz de administración. No transporta el tráfico de los clientes.

Este último punto determina dónde debe ubicarse. Si instala el controlador en una máquina dentro de la oficina que administra, perderá la red y la herramienta para examinarla al mismo tiempo. Si lo instala en un VPS con una dirección pública estable, seguirá ejecutándose, recopilando datos y permitiendo adoptar dispositivos de varios sitios desde un solo lugar. Necesita disponibilidad, no potencia de procesamiento.

Cuando el controlador está fuera de línea, los puntos de acceso y switches adoptados siguen reenviando el tráfico con la configuración que ya se les envió. Perderá el panel y las estadísticas, además de cualquier función que necesite que el controlador esté activo: el inicio de sesión de un portal de invitados o RADIUS (remote authentication dial-in user service) si el controlador es su servidor RADIUS. Los clientes permanecen conectados.

¿Cuánta RAM necesita un controlador UniFi?

Dos GB es el mínimo y 4 GB es la cantidad que conviene contratar. En un mismo sistema hay dos consumidores de memoria: Java y MongoDB. Cada uno calcula sus necesidades de forma independiente.

El heap de Java está limitado por MEM_LIMIT, que la imagen del contenedor establece en 1024 MB de forma predeterminada. MongoDB es la otra mitad. Su motor de almacenamiento WiredTiger establece la caché en la mitad de la RAM que supera 1 GB, o en 256 MB, lo que sea mayor. En un VPS de 2 GB, esto equivale aproximadamente a 512 MB de caché, un heap de 1 GB, la memoria no heap propia de la JVM y la memoria del sistema operativo. Funciona hasta que llega un día con mucha carga. Entonces, el asesino de procesos por falta de memoria del kernel termina uno de los dos procesos. Después de cualquier reinicio sin explicación, ejecute dmesg -T | grep -i 'killed process' para comprobar si eso ocurrió. Añada un archivo de swap si sólo dispone de 2 GB.

La CPU y el disco no requieren mucho. Una o dos vCPU son suficientes para unas pocas decenas de dispositivos. Empiece con 20 GB de disco y vigílelo, porque la base de datos crece según el número de clientes que tenga y el tiempo durante el que conserve las estadísticas. Un controlador por sí solo deja inactiva la mayor parte de un sistema de 4 GB. Si planea alojar otro servicio, calcule primero los recursos para ese servicio, porque PhotoPrism e Immich tienen mínimos de RAM muy diferentes y cualquiera de los dos necesita más memoria que el controlador.

Hay una característica de la CPU que importa y que es fácil pasar por alto en un plan económico:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 y posteriores necesitan AVX (extensiones vectoriales avanzadas) en hardware x86_64. Si ese comando no muestra nada, mongod termina durante el arranque y el contenedor se reinicia en bucle, porque el binario ejecuta una instrucción que la CPU no admite. Los hosts antiguos con Intel Celeron y Pentium son la causa habitual. También lo son los hipervisores que ocultan las flags de CPU al guest. MongoDB 4.4 no necesita AVX y es la única alternativa, pero esa versión de la base de datos ya no recibe parches del proyecto upstream. La mejor solución es trasladarse a un host con una CPU más nueva. En un VPS ARM esta cuestión no se plantea, porque AVX es un conjunto de instrucciones x86 y ambas imágenes publican builds arm64. Si está eligiendo entre las dos opciones, las diferencias entre los planes VPS ARM y x86 van más allá del precio.

Instalar UniFi Network Application con Docker Compose

Docker es la opción que suele causar menos problemas, porque permite fijar MongoDB en una versión compatible con la aplicación en lugar de usar la versión que incluya la distribución. Si Docker todavía no está instalado en el servidor, instale Docker en un VPS primero.

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

MongoDB necesita un usuario antes de que la aplicación pueda iniciar sesión. La imagen oficial de MongoDB ejecuta cualquier script que encuentre en /docker-entrypoint-initdb.d durante el primer arranque. Guarde lo siguiente como ~/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

Ese script se ejecuta sólo cuando el directorio de la base de datos está vacío. Si inicia la pila una vez con la contraseña incorrecta, el usuario se crea con esa contraseña. Editar después el archivo compose no cambia nada, porque el script no vuelve a ejecutarse. El síntoma es que el contenedor de la aplicación registra errores de autenticación de MongoDB y la interfaz web nunca aparece. En una instalación nueva, la solución es detener la pila, eliminar ~/unifi/db y volver a iniciarla.

Después, escriba ~/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

Las dos etiquetas de imagen están fijadas de forma intencionada. 10.5.67-ls141 era la versión actual de la aplicación en agosto de 2026, así que compruebe la lista de versiones de la imagen y fije la versión que esté disponible cuando realice la instalación. La etiqueta de la base de datos es más importante. MongoDB no actualiza por sí solo los archivos de datos entre versiones principales, por lo que algún día mongo:latest descargará una nueva versión principal, se negará a abrir los archivos existentes y se reiniciará en bucle. Fije la versión principal y actualícela de forma deliberada. UniFi Network 8.1 y posteriores admiten MongoDB 3.6 a 7.0, y 9.0 añadió compatibilidad con MongoDB 8.0.

PUID y PGID deben coincidir con un usuario real del host. De lo contrario, los archivos de ./config quedarán asignados a una identidad que no puede escribir en ellos. Ejecute id para obtener los suyos. cómo funcionan PUID y PGID en las imágenes de contenedor explica cómo se manifiesta una discrepancia.

Inícielo y supervise los registros:

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

docker compose ps debe mostrar ambos contenedores como running. Un unifi-db atascado en restarting indica un problema de AVX, descrito arriba, o un problema de permisos en ./db. Cuando los registros se estabilicen, compruebe los dos servicios que escuchan:

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

Cualquier código de estado HTTP indica que el servicio está enlazado y responde. Connection refused indica que la aplicación todavía se está iniciando, lo que tarda uno o dos minutos en un VPS pequeño durante el primer arranque, o que nunca se inició.

Acceda a la interfaz de administración sin exponerla

El puerto 8443 está publicado en 127.0.0.1 en el archivo anterior, por lo que nada fuera del VPS puede acceder a la interfaz de administración. Reenvíelo mediante SSH para ejecutar el asistente de configuración:

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

Mantenga abierta esa sesión y acceda a https://127.0.0.1:8443 desde el navegador. El certificado es autofirmado, por lo que el navegador muestra una advertencia una sola vez. Cree la cuenta de administrador, asigne un nombre al sitio y omita por ahora la adopción de dispositivos.

Un túnel SSH es suficiente para un administrador. Para un equipo, asigne una dirección privada al VPS y vincule la interfaz a esa dirección. Una VPN WireGuard en su propio VPS y un router de subred de Tailscale proporcionan una dirección a la que sólo pueden acceder sus usuarios. Cambie el puerto publicado a 10.8.0.1:8443:8443 para WireGuard o a la dirección que asigne Tailscale. Hay una limitación: Docker no puede publicar un puerto en una dirección que todavía no existe. Por tanto, la interfaz del túnel debe estar activa antes de iniciar el contenedor. De lo contrario, el contenedor falla con un error de vinculación.

Por qué un dispositivo UniFi remoto no se adopta

De forma predeterminada, un dispositivo UniFi encuentra su controlador mediante una difusión en la red local, por el puerto UDP 10001. Una difusión no sale de la LAN, por lo que un dispositivo ubicado en una oficina de otra ciudad nunca descubrirá un controlador en un VPS. Esto es una adopción de capa 3, y es donde la mayoría de las personas se bloquea. El dispositivo funciona y el controlador también. Nadie le ha indicado al dispositivo dónde buscar.

Primero, indique al controlador qué dirección debe entregar. En Settings del controlador, dentro de la sección System, hay un ajuste de inform host con una opción de override. Establézcalo con el nombre de host público o la IP de su VPS. Sin este ajuste, el controlador anuncia la dirección que ve en su propia interfaz, que dentro de una red de puente de Docker es una dirección privada como 172.18.0.3. El dispositivo recibe esa dirección, no puede enrutar hacia ella y vuelve a buscar.

Después, dirija el dispositivo a esa dirección. Conéctese por SSH al dispositivo desde la LAN remota. Un dispositivo con los valores de fábrica acepta el nombre de usuario ubnt y la contraseña ubnt:

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

El firmware más reciente del dispositivo abre un menú en lugar de un shell. Ejecute lo mismo como un único comando:

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

El dispositivo aparece ahora en el controlador listo para adoptarlo. Haga clic en Adopt y el estado cambia a Adopting. Esta es la parte que sorprende a todo el mundo: normalmente debe ejecutar set-inform una segunda vez. El dispositivo se reinicia para iniciar el aprovisionamiento y vuelve a la URL de inform guardada en su propia configuración, que el controlador todavía no ha terminado de reemplazar. Ejecutar el comando de nuevo mientras el estado muestra Adopting completa la transferencia. Escriba info en el dispositivo para ver la URL de inform y el estado que tiene actualmente.

Si el dispositivo ya fue adoptado por otro controlador, set-inform por sí solo no terminará el proceso, porque todavía conserva las credenciales de ese controlador. Restablézcalo primero a los valores de fábrica, mediante el botón de reset o con set-default por SSH usando las credenciales anteriores.

Para más de unos pocos dispositivos, use DHCP. La opción 43 de DHCP (protocolo de configuración dinámica de host) transporta un valor específico del fabricante, y los dispositivos UniFi leen la URL de inform desde la subopción 2. Construya la cadena hexadecimal en cualquier equipo 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"

Para http://192.168.3.10:8080/inform, una cadena de 31 bytes, el comando imprime 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Pegue el resultado en el campo de la opción 43 de DHCP de su router como valor hexadecimal. Todos los dispositivos que arranquen en esa red aprenderán la dirección del controlador a partir de su concesión, sin usar SSH. Las guías antiguas muestran la subopción 1 en su lugar, 0104 seguida de los cuatro bytes de una dirección IPv4 en hexadecimal, y los dispositivos todavía aceptan ese formato.

Existe una tercera opción si ejecuta DNS en el sitio. Un dispositivo UniFi intenta resolver el nombre de host unifi durante el arranque, por lo que un registro A para unifi que apunte a la dirección de su VPS adopta los dispositivos sin trabajo individual. Sólo sirve si controla el resolvedor que usan realmente los dispositivos.

Qué puertos de UniFi abrir y cuáles mantener privados

Sólo 2 puertos deben ser accesibles desde un sitio remoto.

• TCP 8080 es el canal inform y todos los dispositivos adoptados se conectan a él. La carga útil está cifrada con AES mediante una clave que el controlador entregó al dispositivo durante la adopción. Por eso, HTTP sin cifrar es la configuración normal en este caso.
• UDP 3478 es STUN (utilidades de recorrido de sesiones para NAT), que los dispositivos usan para mantener una ruta de vuelta al controlador.

Todo lo demás debe permanecer cerrado en un VPS.

• TCP 8443 es la interfaz de administración. Este puerto nunca debe ser público. Contiene la configuración de todos los sitios que administra el controlador y está protegido por una sola contraseña.
• UDP 10001 y UDP 1900 se usan para la detección mediante broadcast. Los broadcasts no atraviesan Internet, por lo que abrirlos no sirve de nada.
• TCP 8880 y TCP 8843 son redirecciones del portal de invitados. Ábralos sólo si ejecuta un portal de invitados.
• TCP 6789 es la prueba de velocidad móvil y UDP 5514 es syslog remoto. Añádalos cuando los use.
• TCP 27117 es MongoDB. En el archivo compose anterior, la base de datos no publica ningún puerto, por lo que sólo existe en la red interna de Docker. Manténgalo así.

Si sus sitios tienen direcciones públicas estáticas, permita sólo esas direcciones:

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

los conceptos básicos de ufw para el firewall de un VPS explica la configuración de denegación predeterminada que dan por supuestas esas reglas.

Hay una trampa que sorprende a los usuarios cada vez. Los puertos publicados por Docker evitan ufw. Publicar un puerto escribe reglas de NAT y de reenvío directamente en iptables, y ese tráfico se filtra en la cadena propia de Docker, no en la cadena INPUT que administra ufw. Por tanto, ufw deny 8443 parece correcto en ufw status, aunque el puerto siga abierto a todo Internet. Pruébelo desde otra máquina, nunca desde el propio VPS:

nc -vz vps.example.com 8443

Debe obtener un rechazo o un tiempo de espera. Si se establece la conexión, el puerto es público independientemente de lo que indique ufw. La solución fiable es la que ya aparece en el archivo compose: publique el puerto en 127.0.0.1 o en una dirección del túnel, para que Docker nunca lo asocie a la interfaz pública. También funciona una regla en la cadena DOCKER-USER, pero asociar el puerto es más sencillo y un error en el orden de las reglas no puede anularlo.

¿Qué ocurre con los instaladores propios de Ubiquiti?

Ubiquiti publica un paquete Debian para Network Application. Funciona, pero en las versiones actuales de Ubuntu plantea una cuestión sobre MongoDB que la distribución ya no resuelve: Ubuntu 22.04 y 24.04 no incluyen ningún paquete de servidor de MongoDB, por lo que hay que añadir el repositorio propio de MongoDB y hacer coincidir las versiones manualmente. El contenedor anterior resuelve esa correspondencia en una única etiqueta fijada. Por eso se utiliza aquí.

El producto más reciente de Ubiquiti para alojarlo por cuenta propia es UniFi OS Server. Ejecuta las aplicaciones UniFi en contenedores Podman y proporciona el mismo UniFi OS que sus consolas de hardware. En agosto de 2026 requiere Ubuntu 22.04 o 24.04 en x86_64, Podman 4.3.1 o posterior con slirp4netns, y solicita 2 vCPU con 4 GB de RAM como mínimo; se recomiendan 4 vCPU con 8 GB. El instalador está disponible detrás de una cuenta gratuita de Ubiquiti en su página de descargas, por lo que no existe una URL estable de una sola línea que se pueda pegar en una guía. Crea un usuario del sistema llamado uosserver y ejecuta los contenedores con ese usuario. Elija esta opción si quiere utilizar el empaquetado propio del fabricante. Elija la pila de contenedores si quiere fijar las versiones por su cuenta y mantener el servidor disponible para otras tareas.

Dónde se guardan las copias de seguridad de UniFi y cómo sacarlas del equipo

El controlador escribe sus propias copias de seguridad según el calendario que configure en Settings, en la sección de copias de seguridad, junto con el número de copias que debe conservar. Los archivos se guardan en /config/data/backup/autobackup dentro del contenedor, que corresponde a ~/unifi/config/data/backup/autobackup en el host, con nombres como autobackup_10.5.67_20260813_1200_1755086400004.unf.

Compruebe que realmente aparezcan:

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

Un directorio vacío un día después de configurar un calendario es un fallo conocido en instalaciones nuevas del contenedor. La aplicación espera que exista el directorio autobackup y no lo crea, por lo que la tarea programada no escribe nada y no muestra ningún error. Créelo manualmente con el mismo usuario con el que se ejecuta el contenedor y espere a la siguiente ejecución:

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

Un archivo .unf contiene la configuración del sitio y las cuentas de administrador, por lo que debe tratarlo como una clave criptográfica. Descargue copias a una máquina bajo su control y manténgalas privadas:

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

La restauración requiere un solo paso. La primera página del asistente de configuración de una instalación nueva permite restaurar desde un archivo de copia de seguridad. Un controlador en ejecución también permite restaurarla desde la misma página de configuración. Restaure en la misma versión o en una versión posterior. Se rechaza una copia de seguridad escrita por una aplicación más reciente que la instalación donde intenta restaurarla. Por eso debe registrar el número de versión junto con el archivo.

Qué puede romper una actualización del controlador

Haga una copia de seguridad manual y descárguela antes de cada actualización. Después:

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

La base de datos es lo primero que suele fallar. Cambiar la etiqueta mongo a una versión principal nueva en la misma edición que la aplicación es la forma más rápida de dejar un controlador que no arranca, porque MongoDB no abre archivos de datos de otra versión principal sin una actualización escalonada. Actualice la aplicación por separado. Actualice MongoDB por separado, una versión principal cada vez, con una copia de seguridad reciente disponible.

La memoria es el siguiente problema. Una versión más grande necesita un heap mayor. Si la aplicación arranca, funciona durante unos minutos y termina, aumente MEM_LIMIT y MEM_STARTUP a 1536 o 2048 y reinicie. dmesg -T | grep -i 'killed process' en el host confirma si el kernel es el que la termina.

El firmware de los dispositivos es el riesgo que suele olvidarse. Después de actualizarse, el controlador ofrece actualizaciones de firmware para los dispositivos adoptados. No las acepte en la misma sesión. Si coinciden una actualización del dispositivo y una actualización del controlador y se pierde el enlace entre ambos, el dispositivo puede quedar aprovisionado a medias, y tendrá que volver a usar set-inform por SSH en hardware ubicado en otro edificio.

La ventana de actualización es menos problemática de lo que parece. Los dispositivos siguen reenviando tráfico mientras se reinicia el controlador, por lo que los usuarios no notan nada. Lo que sí se detiene es el portal de invitados y RADIUS si el controlador los proporciona. Elija un horario en el que no se utilice ninguno de los dos. Conviene saber si un controlador deja de responder en silencio a las 3 a.m., así que apunte un monitor de estado de Uptime Kuma al puerto 8080 y deje que se lo indique.

La alternativa directa: la consola alojada de Ubiquiti

Ubiquiti ofrece el mismo servicio como una solución alojada. En agosto de 2026, la Official UniFi Cloud Console cuesta desde $29 al mes y administra hasta 500 dispositivos UniFi. Ubiquiti se encarga de las actualizaciones y las copias de seguridad. La aplicación autohospedada que acaba de instalar es gratuita y no requiere suscripción.

Elija la consola alojada si administra un solo sitio y prefiere pagar en lugar de aplicar parches. Elija una VPS si administra varios sitios, si quiere que el controlador esté dentro de una red que controla o si quiere compartir el servidor con los demás servicios que ejecuta. La diferencia de coste a pequeña escala es real, pero no es el único factor que debe valorar: la disponibilidad de una consola alojada depende de otra empresa, mientras que la VPS es responsabilidad suya, incluida la noche en que se llene el disco. Si el servidor va a justificar su coste de todos modos, qué más puede ejecutar en una VPS es la lista que debe leer a continuación.

FAQ

¿Por qué mi dispositivo UniFi no se adopta en un controlador alojado en una VPS?

Los dispositivos detectan los controladores mediante difusión en el puerto UDP 10001. La difusión nunca sale de la red local, por lo que un dispositivo de un sitio remoto no puede encontrar un controlador en Internet. Configure la anulación del host inform en los ajustes del sistema del controlador para usar el nombre de host de su VPS. Después, indique ese host al dispositivo con ssh ubnt@<device-ip> seguido de set-inform http://vps.example.com:8080/inform. Si el dispositivo permanece en el estado Adopting, vuelva a ejecutar set-inform mientras se encuentre en ese estado. Si otro controlador lo adoptó anteriormente, restablézcalo primero a los valores de fábrica, porque todavía conserva las credenciales del controlador anterior.

¿Cuánta RAM necesita un controlador UniFi autohospedado?

2 GB es el mínimo operativo y 4 GB ofrecen un margen adecuado. La aplicación usa Java y MongoDB, y cada uno reserva memoria por separado. De forma predeterminada, la imagen del contenedor limita el heap de Java a 1024 MB, mientras que la caché WiredTiger de MongoDB utiliza la mitad de la RAM por encima de 1 GB. En x86_64, confirme también que la CPU exponga AVX con grep -m1 -o avx /proc/cpuinfo, porque MongoDB 5.0 y versiones posteriores no arrancan sin esta extensión y el contenedor de la base de datos entra en un ciclo de reinicios.

¿Debo exponer el puerto 8443 a Internet?

No. El puerto 8443 es la interfaz de administración y contiene la configuración de todos los sitios que gestiona el controlador. Publíquelo en 127.0.0.1 y acceda a él con ssh -L 8443:127.0.0.1:8443 you@vps.example.com, o asígnelo a una dirección de WireGuard o Tailscale. Desde sus sitios sólo deben poder alcanzarse TCP 8080 y UDP 3478. Si las direcciones públicas de los sitios son estáticas, puede restringir esos puertos a dichas direcciones. Recuerde que ufw no filtra un puerto publicado por Docker. Por tanto, pruebe desde una máquina externa en lugar de confiar en ufw status.

¿Deja de funcionar mi red si el controlador UniFi de la VPS se detiene?

No. Los puntos de acceso y switches adoptados siguen reenviando el tráfico con la configuración que el controlador ya les envió. Por tanto, los clientes permanecen conectados y la red Wi-Fi sigue funcionando. Lo que se detiene es la administración. Se pierde el panel y la recopilación de estadísticas, además de cualquier función en tiempo real que proporcione el controlador, como la autenticación del portal de invitados o RADIUS cuando el controlador actúa como servidor RADIUS.

¿Dónde almacena el controlador UniFi sus copias de seguridad automáticas?

En la imagen del contenedor utilizada aquí, se guardan en /config/data/backup/autobackup. Esta ruta corresponde a la ruta de datos del host más data/backup/autobackup y contiene archivos .unf cuyos nombres incluyen la versión y una marca de tiempo. En algunas instalaciones nuevas no existe el directorio autobackup. En ese caso, la copia programada no escribe nada ni informa de un error. Un día después de configurar una programación, liste ese directorio y créelo manualmente si está vacío. Copie los archivos fuera de la VPS, porque un .unf contiene la configuración de los sitios y las cuentas de administrador.