Como hospedar o Duplicati por conta própria em 2026: backups criptografados, mounts e testes de restauração

Se você já tentou hospedar o Duplicati por conta própria, provavelmente conhece bem este estado frustrante: a UI aparece, mas o container vê um caminho vazio porque as fontes do host foram montadas em outro lugar. Recriar o container raramente resolve um conflito entre URLs, estado e dependências.

Este passo a passo usa um critério concreto de conclusão: fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo. Cada decisão de configuração é avaliada com base nesse critério, e não em um indicador verde do container.

Portas, processos e serviços privados

Um diagrama útil do Duplicati mostra a rota pública, a porta privada 8200, o limite do estado e todos os requisitos de suporte. Marque quais setas transportam credenciais e quais representam tráfego comum de usuários. O contrato de rede do Duplicati consiste em mounts de origem somente leitura e no armazenamento de destino do backup acessível. Mantenha os endpoints privados no DNS interno, permita apenas as chamadas de saída necessárias e forneça ao Duplicati uma credencial de serviço com escopo limitado.

Comprove o diagrama com uma ação real: faça backup de um diretório de teste no destino escolhido, exclua um arquivo de origem e restaure-o em um caminho alternativo limpo. A carga mais provável vem da quantidade de arquivos de origem, da compressão, da criptografia, da latência do destino e da sobreposição entre jobs agendados; monitore esse fluxo em vez de tratar todas as requisições HTTP como equivalentes.

Diagnostique um Duplicati com aparência saudável

Crie dashboards com base na quantidade de arquivos de origem, na compressão, na criptografia, na latência do destino e na sobreposição entre jobs agendados. Um gráfico de CPU sem o contexto dessa carga não consegue explicar por que o Duplicati está lento. Adicione uma verificação sintética ou agendada que tente fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo usando dados de teste inofensivos.

Antes de fazer upgrade, considere este risco específico da aplicação: as alterações no banco de dados de configuração e no formato de backup do Duplicati devem ser testadas sem reescrever o único conjunto de backup remoto. Restaure um backup recente em um deployment isolado, execute as migrations nesse ambiente e compare o comportamento. Se o container vir um caminho vazio porque as fontes do host foram montadas em outro lugar, inspecione o limite envolvido — origem pública, armazenamento ou dependência — antes de alterar configurações não relacionadas.

O que deve passar antes que os dados reais do Duplicati cheguem

O registro de release do Duplicati precisa de fatos, não de um “parece bom”. Armazene o digest da image selecionada, o checksum da configuração, o hostname público e o resultado com timestamp para: fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo. Use dados de exemplo que não sejam de produção para que a verificação possa ser executada após cada deployment.

Comprove separadamente dois eventos do ciclo de vida. A substituição de um container deve preservar a operação normal; uma recuperação limpa deve mostrar que uma nova instância do Duplicati consegue importar a configuração e restaurar os arquivos selecionados com hashes verificados. Enquanto as verificações são executadas, meça a quantidade de arquivos de origem, a compressão, a criptografia, a latência do destino e a sobreposição entre jobs agendados, e preserve o resultado como o envelope esperado para esta versão.

Teste também uma condição negada ou inválida: negue temporariamente à identidade de teste o acesso aos mounts de origem somente leitura e ao armazenamento de destino do backup acessível. O Duplicati deve falhar de forma diagnosticável e não deve sobrescrever um estado saudável. Restaure a condição válida, execute novamente o exemplo e anexe os logs relevantes com os dados confidenciais removidos. Esses artefatos fornecem evidências concretas para uma futura decisão de rollback.

Transforme o comando local em um serviço inspecionável

O comando a seguir torna o limite do container visível sem fingir provisionar todos os serviços externos.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Antes de abrir o ingresso, inspecione o ambiente resolvido, os mounts e o listener. Adicione as configurações de conexão revisadas para os mounts de origem somente leitura e para o armazenamento de destino do backup acessível; use nomes privados para serviços privados. Um lançamento bem-sucedido termina quando você consegue fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo, e não quando docker ps exibe Up.

Torne a recuperação do Duplicati mensurável

Liste o estado antes de criar o primeiro registro real: o banco de dados de configuração do Duplicati e os conjuntos de backup verificados separadamente. Monte /config antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Confirme o mount gravando dados inofensivos, substituindo o Duplicati e lendo-os novamente.

Snapshots são úteis para um rollback rápido, mas é necessário um backup independente quando o host ou o volume desaparece. Restaure em um ambiente vazio com a image fixada e verifique se uma nova instância do Duplicati consegue importar a configuração e restaurar os arquivos selecionados com hashes verificados. Use volumes persistentes e snapshots para manter esses dois mecanismos de recuperação distintos.

TLS é fácil; URLs geradas, não

Exponha um único hostname HTTPS para o Duplicati; mantenha a porta 8200 privada. Mantenha a UI de gerenciamento privada ou fortemente autenticada atrás de HTTPS. Isso impede que browsers e clientes de API descubram dois endereços concorrentes.

Em um client limpo, execute a transação conhecida como válida e inspecione a primeira requisição que falhar. Use o guia de domínio personalizado quando houver problemas de DNS ou TLS. Trate “o container vê um caminho vazio porque as fontes do host foram montadas em outro lugar” como um diagnóstico separado da aplicação depois que a rota estiver comprovada.

Proteja o Duplicati após o bootstrap

As credenciais de bootstrap são temporárias; o modelo de confiança é permanente. Com o Duplicati, fique atento à montagem das fontes de backup com acesso de leitura e escrita ou à perda da passphrase de criptografia, monte as fontes como somente leitura, mantenha a UI de gerenciamento privada e armazene a passphrase do backup fora do servidor.

Gere SETTINGS_ENCRYPTION_KEY uma única vez, mantenha-o fora do Git e preserve-o com o manifesto de recuperação, pois alterá-lo pode invalidar o estado criptografado ou assinado da aplicação. Execute a image sem capabilities Linux desnecessárias e exponha apenas a rota pública da aplicação. Mantenha a atividade dos administradores visível sem registrar valores secretos.

Use o Dockup para a camada de plataforma

Para o Duplicati, o Dockup pode criar a rota e o certificado TLS, preservar mounts, entregar secrets e colocar os mounts de origem somente leitura e o armazenamento de destino do backup acessível em uma rede privada, com deployment no Dockup ou em servidores conectados.

O gate de release continua sendo a transação concreta do Duplicati: fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo. Verifique também a condição de restauração: uma nova instância do Duplicati consegue importar a configuração e restaurar os arquivos selecionados com hashes verificados. Essas duas verificações mostram se o deployment funciona e se pode ser recuperado.

Perguntas frequentes

Do que o Duplicati precisa para um deployment em produção?

Encaminhe o container do Duplicati na porta 8200 por meio de uma única origem HTTPS. O requisito de rede de suporte consiste em mounts de origem somente leitura e no armazenamento de destino do backup acessível. Não considere o Duplicati pronto até conseguir fazer backup de um diretório de teste no destino escolhido, excluir um arquivo de origem e restaurá-lo em um caminho alternativo limpo.

Quais dados do Duplicati devem fazer parte de um backup?

Persista /config e inclua o banco de dados de configuração do Duplicati e os conjuntos de backup verificados separadamente no mesmo manifesto de recuperação. Uma restauração limpa do Duplicati só será bem-sucedida quando uma nova instância do Duplicati conseguir importar a configuração e restaurar os arquivos selecionados com hashes verificados.

O Duplicati precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Duplicati e mantenha a porta 8200 na rota interna. Aplique corretamente a configuração do Duplicati: mantenha a UI de gerenciamento privada ou fortemente autenticada atrás de HTTPS. No Duplicati, o HTTPS protege credenciais ou conteúdo de usuários durante o trânsito e mantém consistente o comportamento do client sensível à origem.

Como testar um upgrade do Duplicati?

Restaure o estado atual do Duplicati em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Dê atenção especial a esse ponto, pois as alterações no banco de dados de configuração e no formato de backup do Duplicati devem ser testadas sem reescrever o único conjunto de backup remoto. Mantenha a image anterior do Duplicati até entender os limites da migração de dados e do rollback.