Como rodar um controlador UniFi em uma VPS

O que um controlador UniFi numa VPS faz efetivamente

Um controlador UniFi numa VPS é um único servidor de gestão que continua acessível quando os sites que gere ficam indisponíveis. O software é a UniFi Network Application da Ubiquiti: um programa Java com uma base de dados MongoDB. Configura os seus pontos de acesso e switches, armazena as respetivas estatísticas e disponibiliza a interface de administração. Não transporta tráfego de clientes.

Este último ponto determina onde deve ficar. Se colocar o controlador numa máquina dentro do escritório que gere, perde a rede e a ferramenta de análise da rede no mesmo momento. Se o colocar numa VPS com um endereço público estável, ele continua a funcionar, continua a recolher dados e pode adotar dispositivos de vários sites a partir de um único local. Precisa de disponibilidade, não de capacidade de processamento.

Quando o controlador está offline, os pontos de acesso e switches adotados continuam a encaminhar tráfego com a configuração que já receberam. Perde o painel e as estatísticas, além de qualquer funcionalidade que exija o controlador ativo: o início de sessão num portal de convidados ou o RADIUS (remote authentication dial-in user service), se o controlador for o seu servidor RADIUS. Os clientes continuam ligados.

Quanta RAM um controlador UniFi precisa?

Dois GB são o mínimo e 4 GB é a capacidade recomendada. Há dois consumidores de memória no mesmo servidor: Java e MongoDB. Cada um dimensiona o seu uso de memória de forma independente.

O heap do Java é limitado por MEM_LIMIT, que a imagem do contentor define como 1024 MB por predefinição. MongoDB é a outra parte. O seu motor de armazenamento WiredTiger dimensiona a cache para metade da RAM acima de 1 GB, ou 256 MB, consoante o valor que for maior. Num VPS com 2 GB, isso corresponde aproximadamente a 512 MB de cache, 1 GB de heap, a memória não heap própria da JVM e o sistema operativo. Funciona até surgir um dia de maior carga. Nesse momento, o mecanismo de encerramento por falta de memória do kernel termina um dos dois processos. Depois de qualquer reinício sem explicação, execute dmesg -T | grep -i 'killed process' para verificar se foi isso que aconteceu. Adicione um ficheiro de swap se tiver apenas 2 GB.

O CPU e o disco não exigem muito. Um ou dois vCPU suportam algumas dezenas de dispositivos. Comece com 20 GB de disco e monitorize o consumo, porque a base de dados cresce com o número de clientes e com o período durante o qual mantém as estatísticas. Um controlador isolado deixa a maior parte de um servidor com 4 GB sem utilização. Se tenciona alojar outro serviço no mesmo servidor, dimensione primeiro para esse serviço, porque PhotoPrism e Immich têm requisitos mínimos de RAM muito diferentes e qualquer um deles precisa de mais memória do que o controlador.

Uma funcionalidade do CPU é importante e pode passar despercebida num plano barato:

grep -m1 -o avx /proc/cpuinfo

O MongoDB 5.0 e versões posteriores precisam de AVX (advanced vector extensions) em hardware x86_64. Se esse comando não produzir qualquer saída, o mongod termina durante o arranque e o contentor reinicia em ciclo, porque o binário executa uma instrução que o CPU não suporta. Hosts com Intel Celeron e Pentium antigos são a causa habitual. Hypervisors que ocultam as flags do CPU ao sistema convidado também causam este problema. O MongoDB 4.4 não precisa de AVX e é a única alternativa, mas essa versão da base de dados já não recebe correções do projeto. Migrar para um host com um CPU mais recente é a melhor solução. Num VPS ARM, a questão não se coloca, porque AVX é um conjunto de instruções x86 e ambas as imagens disponibilizam builds arm64. Se estiver a escolher entre as duas opções, as diferenças entre planos de VPS ARM e x86 vão além do preço.

Instale a aplicação UniFi Network com Docker Compose

O Docker é o caminho com menos surpresas, porque permite fixar o MongoDB numa versão compatível com a aplicação, em vez de aceitar a versão disponibilizada pela distribuição. Se o Docker ainda não estiver instalado no servidor, instale o Docker numa VPS primeiro.

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

O MongoDB precisa de um utilizador antes de a aplicação poder iniciar sessão. A imagem oficial do MongoDB executa qualquer script que encontre em /docker-entrypoint-initdb.d no primeiro arranque. Guarde este conteúdo 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

Esse script é executado apenas quando o diretório da base de dados está vazio. Se iniciar a stack uma vez com a palavra-passe errada, o utilizador será criado com essa palavra-passe. Alterar o ficheiro Compose depois disso não terá efeito, porque o script não volta a ser executado. O sintoma é o contentor da aplicação registar falhas de autenticação no MongoDB, enquanto a interface web nunca fica disponível. Numa instalação nova, a correção consiste em parar a stack, eliminar ~/unifi/db e iniciá-la novamente.

Depois, escreva ~/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

As duas tags de imagem estão fixadas de propósito. 10.5.67-ls141 era a versão atual da aplicação em agosto de 2026, por isso consulte a lista de versões da imagem e fixe a versão que estiver atual quando fizer a instalação. A tag da base de dados é mais importante. O MongoDB não atualiza automaticamente os ficheiros de dados entre versões principais. Por isso, mongo:latest acabará por obter uma nova versão principal, recusará abrir os ficheiros existentes e reiniciará continuamente. Fixe a versão principal e altere-a de forma deliberada. O UniFi Network 8.1 e versões posteriores suportam MongoDB 3.6 a 7.0, e a versão 9.0 acrescentou suporte para MongoDB 8.0.

PUID e PGID têm de corresponder a um utilizador real no host. Caso contrário, os ficheiros em ./config ficarão pertencentes a uma identidade que não pode escrevê-los. Execute id para obter os seus valores. como funcionam PUID e PGID em imagens de contentores explica como se manifesta uma incompatibilidade.

Inicie a stack e monitorize os logs:

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

docker compose ps deve mostrar os dois contentores com o estado running. Um unifi-db bloqueado em restarting indica um problema de AVX ou de permissões em ./db. Quando os logs estabilizarem, verifique os dois listeners:

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

Qualquer código de estado HTTP significa que o listener está associado à porta e a responder. Connection refused significa que a aplicação ainda está a iniciar. Na primeira execução, esse processo demora um ou dois minutos numa VPS pequena. Também pode significar que a aplicação nunca arrancou.

Aceder à interface de administração sem a expor

A porta 8443 é publicada em 127.0.0.1 no ficheiro acima, por isso nada fora da VPS consegue aceder à interface de administração. Encaminhe-a através de SSH para executar o assistente de configuração:

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

Mantenha essa sessão aberta e aceda a https://127.0.0.1:8443 no navegador. O certificado é autoassinado, por isso o navegador apresenta um aviso uma vez. Crie a conta de administrador, atribua um nome ao site e ignore a adoção de dispositivos por agora.

Um túnel SSH é suficiente para um administrador. Para uma equipa, atribua um endereço privado à VPS e faça o bind da interface nesse endereço. uma VPN WireGuard na sua própria VPS e um router de sub-rede Tailscale fornecem um endereço ao qual apenas as pessoas da sua equipa conseguem encaminhar tráfego. Altere a porta publicada para 10.8.0.1:8443:8443 no caso do WireGuard ou para o endereço atribuído pelo Tailscale. Há uma limitação: o Docker não consegue publicar numa address que ainda não existe. Por isso, a interface do túnel tem de estar ativa antes de o contentor arrancar; caso contrário, o contentor falha com um erro de bind.

Por que um dispositivo UniFi remoto não é adotado

Por padrão, um dispositivo UniFi encontra o seu controlador através de uma transmissão na rede local, na porta UDP 10001. Uma transmissão não sai da LAN, portanto um dispositivo num escritório noutra cidade nunca descobrirá um controlador num VPS. Isto é a adoção de Layer 3 e é onde a maioria das pessoas fica bloqueada. O dispositivo está funcional e o controlador também. Ninguém informou o dispositivo sobre onde procurar.

Primeiro, informe ao controlador qual endereço deve fornecer. Nas Settings do controlador, na secção System, existe uma definição de inform host com uma opção de override. Defina-a para o hostname público ou o IP do seu VPS. Sem essa definição, o controlador anuncia o endereço que vê na sua própria interface, que dentro de uma rede bridge do Docker é um endereço privado como 172.18.0.3. O dispositivo recebe esse endereço, não consegue encaminhar tráfego para ele e volta a procurar.

Depois, indique esse endereço ao dispositivo. Ligue-se por SSH ao dispositivo na LAN remota. Um dispositivo com as predefinições de fábrica aceita o nome de utilizador ubnt e a palavra-passe ubnt:

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

O firmware mais recente do dispositivo apresenta um menu em vez de uma shell. Execute o mesmo procedimento como um único comando:

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

O dispositivo aparece agora no controlador como pronto para adoção. Clique em Adopt e o estado muda para Adopting. Esta é a parte que surpreende toda a gente: normalmente é necessário executar set-inform uma segunda vez. O dispositivo reinicia para o aprovisionamento e recorre ao URL de inform guardado na sua própria configuração, que o controlador ainda não terminou de substituir. Executar o comando novamente enquanto o estado apresenta Adopting conclui a transferência. Introduza info no dispositivo para ver o URL de inform e o estado atualmente guardados.

Se o dispositivo tiver sido adotado anteriormente por outro controlador, set-inform não será suficiente, porque o dispositivo ainda mantém as credenciais desse controlador. Reponha primeiro as predefinições de fábrica, utilizando o botão de reset ou set-default por SSH com as credenciais antigas.

Para mais do que alguns dispositivos, utilize DHCP. A opção 43 do DHCP (dynamic host configuration protocol) transporta um valor específico do fabricante, e os dispositivos UniFi leem o URL de inform a partir da subopção 2. Crie a cadeia hexadecimal em qualquer máquina 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, uma cadeia de 31 bytes, o comando apresenta 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Cole o resultado no campo da opção 43 do DHCP do seu router como valor hexadecimal. Todos os dispositivos que arrancarem nessa rede aprendem então o endereço do controlador a partir do respetivo lease, sem qualquer ligação SSH. Os guias mais antigos mostram a subopção 1 em vez disso, 0104 seguida dos quatro bytes de um endereço IPv4 em hexadecimal, e os dispositivos continuam a aceitar esse formato.

Existe uma terceira opção se executar DNS no local. Um dispositivo UniFi tenta resolver o hostname unifi durante o arranque, portanto um registo A para unifi apontado para o endereço do seu VPS adota os dispositivos sem intervenção individual. Esta opção só funciona quando controla o resolver que os dispositivos utilizam efetivamente.

Quais portas do UniFi abrir e quais manter privadas

Apenas duas portas precisam de ser acessíveis a partir de um site remoto.

• TCP 8080 é o canal inform. Todos os dispositivos adotados ligam-se a ele. O conteúdo é encriptado com AES usando uma chave que o controlador forneceu ao dispositivo durante a adoção. Por isso, HTTP simples é a configuração normal neste caso.
• UDP 3478 é STUN (utilitários de travessia de sessões para NAT). Os dispositivos usam-no para manter um caminho de volta para o controlador.

Num VPS, todas as outras portas devem permanecer fechadas.

• TCP 8443 é a interface de administração. Esta porta nunca deve ser pública. Contém a configuração de todos os sites geridos pelo controlador, protegida por uma única palavra-passe.
• UDP 10001 e UDP 1900 são usadas pela descoberta por broadcast. Os broadcasts não atravessam a Internet, por isso abri-las não produz qualquer efeito.
• TCP 8880 e TCP 8843 são usadas pelos redirecionamentos do portal de convidados. Abra-as apenas se executar um portal de convidados.
• TCP 6789 é usada pelo teste de velocidade móvel e UDP 5514 pelo syslog remoto. Adicione-as quando utilizar essas funcionalidades.
• TCP 27117 é o MongoDB. No ficheiro compose acima, a base de dados não publica qualquer porta, por isso existe apenas na rede Docker interna. Mantenha essa configuração.

Se os seus sites tiverem endereços públicos estáticos, permita apenas esses endereços:

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

os fundamentos do ufw para uma firewall de VPS explica a configuração de bloqueio por predefinição que essas regras pressupõem.

Existe uma armadilha que apanha utilizadores repetidamente. As portas publicadas pelo Docker contornam o ufw. A publicação de uma porta escreve regras de NAT e encaminhamento diretamente no iptables, e esse tráfego é filtrado na própria cadeia do Docker, não na cadeia INPUT gerida pelo ufw. Assim, ufw deny 8443 parece correto em ufw status, enquanto a porta permanece aberta para toda a Internet. Teste a partir de outra máquina, nunca a partir do próprio VPS:

nc -vz vps.example.com 8443

Uma recusa ou um timeout é o resultado esperado. Se houver ligação, a porta está pública, independentemente do que o ufw indicar. A correção fiável é a que já está no ficheiro compose: publique a porta em 127.0.0.1 ou num endereço do túnel, para que o Docker nunca a associe à interface pública. Também pode usar uma regra na cadeia DOCKER-USER, mas associar a porta a um endereço é mais simples e um erro na ordem das regras não pode anulá-lo.

E os instaladores da própria Ubiquiti?

A Ubiquiti publica um pacote Debian para a Network Application. Ele funciona, mas no Ubuntu atual levanta uma questão sobre o MongoDB que a distribuição já não resolve: o Ubuntu 22.04 e o 24.04 não incluem um pacote de servidor MongoDB, por isso é necessário adicionar o repositório do próprio MongoDB e compatibilizar as versões manualmente. O contentor acima faz essa compatibilização numa única tag fixada. É por isso que este é o caminho escolhido aqui.

O produto self-hosted mais recente da Ubiquiti é o UniFi OS Server. Ele executa as aplicações UniFi em contentores Podman e fornece o mesmo UniFi OS das consolas de hardware da empresa. Em agosto de 2026, requer Ubuntu 22.04 ou 24.04 em x86_64, Podman 4.3.1 ou posterior com slirp4netns, e pede 2 vCPU com 4 GB de RAM como mínimo; a recomendação é 4 vCPU com 8 GB. O instalador está disponível por trás de uma conta Ubiquiti gratuita na página de downloads. Por isso, não existe um URL estável de uma linha para colar num guia. Ele cria um utilizador de sistema chamado uosserver e executa os contentores com esse utilizador. Escolha-o se quiser o empacotamento da própria fabricante. Escolha a stack de contentores se quiser fixar as versões por conta própria e manter o servidor disponível para outras tarefas.

Onde ficam os backups do UniFi e como removê-los do servidor

O controlador grava os próprios backups de acordo com a agenda definida em Settings, na secção de backups, juntamente com o número de backups a manter. Os ficheiros ficam em /config/data/backup/autobackup dentro do contentor, que corresponde a ~/unifi/config/data/backup/autobackup no host, com nomes no formato autobackup_10.5.67_20260813_1200_1755086400004.unf.

Confirme se os ficheiros são realmente criados:

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

Um diretório vazio um dia depois de definir uma agenda é uma falha conhecida em instalações novas do contentor. A aplicação espera que o diretório autobackup exista e não o cria, pelo que a tarefa agendada não grava nada. Crie-o manualmente com o mesmo utilizador com que o contentor é executado e aguarde pela próxima execução:

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

Um ficheiro .unf contém a configuração do site e as contas de administrador, pelo que deve ser tratado como uma chave criptográfica. Transfira cópias para uma máquina sob o seu controlo e mantenha-as privadas:

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

A restauração é simples. A primeira página do assistente de configuração de uma instalação nova permite restaurar a partir de um ficheiro de backup, e um controlador em execução permite iniciar a restauração na mesma página de definições. Restaure para a mesma versão ou para uma versão mais recente. Um backup criado por uma aplicação mais recente do que a aplicação para a qual está a restaurar é rejeitado. Por isso, registe o número da versão juntamente com o ficheiro.

O que uma atualização do controlador pode interromper

Faça um backup manual e transfira-o antes de cada atualização. Depois:

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

A base de dados é o primeiro componente a falhar. Alterar a tag mongo para uma nova versão principal na mesma edição em que atualiza a aplicação é a forma mais rápida de ficar com um controlador que não inicia, porque o MongoDB não abre ficheiros de dados de outra versão principal sem uma atualização faseada. Atualize apenas a aplicação. Atualize o MongoDB separadamente, uma versão principal de cada vez, mantendo um backup recente disponível.

A memória é o problema seguinte. Uma versão maior precisa de mais heap. Se a aplicação iniciar, funcionar durante alguns minutos e terminar, aumente MEM_LIMIT e MEM_STARTUP para 1536 ou 2048 e reinicie. dmesg -T | grep -i 'killed process' no host confirma se foi o kernel que terminou o processo.

O firmware dos dispositivos é o risco que muitas pessoas esquecem. Depois de o controlador se atualizar, ele disponibiliza atualizações de firmware para os dispositivos adotados. Não as aceite na mesma sessão. Se uma atualização de dispositivo coincidir com uma atualização do controlador e a ligação entre ambos cair, o dispositivo pode ficar parcialmente provisionado, e terá novamente de usar set-inform por SSH num equipamento situado noutro edifício.

A própria janela de atualização é menos problemática do que parece. Os dispositivos continuam a encaminhar tráfego enquanto o controlador reinicia, por isso os utilizadores não notam nada. O portal de convidados e o RADIUS deixam de funcionar se forem fornecidos pelo controlador. Escolha um horário em que nenhum dos dois esteja a ser utilizado. É importante saber se um controlador termina silenciosamente às 3 a.m., por isso aponte um monitor de estado do Uptime Kuma para a porta 8080 e deixe-o avisá-lo.

A alternativa honesta: a consola alojada da Ubiquiti

A Ubiquiti disponibiliza a mesma função como serviço. Em agosto de 2026, a Official UniFi Cloud Console começa nos $29 por mês e gere até 500 dispositivos UniFi, enquanto a Ubiquiti trata das atualizações e das cópias de segurança. A aplicação autoalojada que acabou de instalar é gratuita e não tem subscrição.

Escolha a consola alojada se gere um único site e preferir pagar a aplicar correções. Escolha um VPS se gere vários sites, ou se quiser manter o controlador numa rede que controla e partilhar um servidor com os outros serviços que executa. A diferença de custo em pequena escala é real, mas não é o único fator a considerar: a disponibilidade de uma consola alojada depende de terceiros, enquanto o VPS é seu, incluindo a noite em que o disco fica cheio. Se o servidor vai justificar o custo de qualquer forma, o que mais pode executar num VPS é o próximo conteúdo a consultar.

FAQ

Porque é que o meu dispositivo UniFi não é adotado pelo controller numa VPS?

Os dispositivos descobrem os controllers através de broadcast na porta UDP 10001. Um broadcast nunca sai da rede local. Por isso, um dispositivo num site remoto não consegue encontrar um controller na Internet pública. Defina o override do host inform nas definições do sistema do controller para o hostname da sua VPS. Em seguida, aponte o dispositivo para esse host com ssh ubnt@<device-ip> seguido de set-inform http://vps.example.com:8080/inform. Se o dispositivo ficar no estado Adopting, execute novamente set-inform enquanto ele estiver nesse estado. Se outro controller o tiver adotado anteriormente, reponha primeiro as predefinições de fábrica. O dispositivo ainda mantém as credenciais do controller antigo.

De quanta RAM precisa um controller UniFi autoalojado?

2 GB é o mínimo funcional. 4 GB oferece uma margem confortável. A aplicação é composta por Java e MongoDB. Cada componente dimensiona a memória separadamente. Por predefinição, a imagem do contentor limita o heap do Java a 1024 MB. A cache WiredTiger do MongoDB usa metade da RAM acima de 1 GB. Em x86_64, confirme também que a CPU expõe AVX com grep -m1 -o avx /proc/cpuinfo. O MongoDB 5.0 e versões posteriores não iniciam sem essa extensão, e o contentor da base de dados entra num ciclo de reinícios.

Devo expor a porta 8443 à Internet?

Não. A porta 8443 é a interface de administração. Contém a configuração de todos os sites geridos pelo controller. Publique-a em 127.0.0.1 e aceda-lhe com ssh -L 8443:127.0.0.1:8443 you@vps.example.com, ou associe-a a um endereço WireGuard ou Tailscale. Apenas as portas TCP 8080 e UDP 3478 precisam de estar acessíveis a partir dos seus sites. Pode restringi-las aos endereços públicos dos sites quando estes forem estáticos. Lembre-se de que uma porta publicada pelo Docker não é filtrada pelo ufw. Por isso, teste a partir de uma máquina externa em vez de confiar em ufw status.

A minha rede deixa de funcionar se o controller da VPS ficar indisponível?

Não. Os access points e switches adotados continuam a encaminhar tráfego com a configuração que o controller já lhes enviou. Os clientes permanecem ligados e o Wi-Fi continua a funcionar. O que deixa de funcionar é a gestão. Perde o dashboard e a recolha de estatísticas, além de qualquer funcionalidade em tempo real fornecida pelo controller, como a autenticação do portal de convidados ou o RADIUS quando o controller é o servidor RADIUS.

Onde guarda o controller UniFi as cópias de segurança automáticas?

Na imagem do contentor usada neste procedimento, as cópias ficam em /config/data/backup/autobackup. Esse caminho corresponde ao seu caminho de dados, seguido de data/backup/autobackup, no host, como ficheiros .unf com nomes baseados na versão e num timestamp. Em algumas instalações novas, o diretório autobackup não existe. Nesse caso, a cópia de segurança agendada não escreve nada e não comunica um erro. Por isso, liste esse diretório um dia depois de configurar um agendamento e crie-o manualmente se estiver vazio. Copie os ficheiros para fora da VPS, porque um .unf contém a configuração dos sites e as contas dos administradores.