Fazer backup no Dokploy exige mais do que guardar um arquivo de configuração. Para recuperar uma aplicação, você precisa proteger os dados do banco, os arquivos persistentes e as informações usadas no deploy. Cada parte tem seu próprio procedimento.
Neste guia, vamos organizar uma estratégia para uma VPS com Docker e Dokploy, diferenciar backups do painel e das aplicações, configurar cópias externas e planejar a restauração. Os exemplos de comandos são para adaptar ao seu ambiente; não foram executados na sua VPS.
O que precisa entrar no backup
- Banco: posts, usuários, pedidos, configurações e outros registros.
- Arquivos persistentes: uploads, anexos e dados produzidos pela aplicação.
- Configuração: Compose, versões das imagens, variáveis e ajustes de proxy.
- Segredos: credenciais e chaves necessárias à recuperação, guardadas de forma protegida.
- Painel Dokploy: sua configuração e banco próprios, em uma rotina separada.
Containers podem ser recriados a partir das imagens e da configuração. Os dados que eles produzem precisam de cópias próprias. Um deploy bem-sucedido não demonstra que o backup funciona.
Se ainda está organizando sua infraestrutura, consulte Deploy de aplicações com Dokploy em uma VPS.
Defina quanto você pode perder e quanto tempo pode ficar fora do ar
Duas decisões orientam a frequência de backup: a quantidade de dados que você aceita perder e o tempo máximo para recuperar o serviço. Esses objetivos são conhecidos como RPO e RTO.
Para um blog atualizado algumas vezes por semana, uma cópia diária pode ser um ponto de partida. Para pedidos de uma loja ou eventos de uma aplicação, perder um dia pode ser inaceitável. Quanto menor o intervalo tolerado, mais você precisa considerar backups frequentes e recursos específicos do banco para recuperação contínua.
O tempo de recuperação também inclui preparar uma nova VPS, baixar arquivos, importar banco, validar o site e alterar DNS. Meça o processo completo.
Entendendo persistência no Docker
Volumes nomeados
Volumes nomeados são gerenciados pelo Docker e continuam disponíveis quando um container é recriado. O Dokploy documenta backups de volumes nomeados para destinos S3. Registre o nome real no host: ele pode incluir um prefixo do projeto.
Bind mounts
Bind mounts ligam um caminho do host a um diretório do container. Eles precisam de uma rotina que cubra esse caminho. Não presuma que uma funcionalidade de backup de volumes nomeados também inclui bind mounts.
Dados dentro do container
Arquivos gravados apenas na camada gravável do container podem desaparecer quando ele é substituído. Corrija a montagem persistente antes de automatizar backups. Também não trate docker export como backup de volumes: os dados desses mounts exigem procedimento separado.
docker ps --format "table {{.Names}}\t{{.Status}}"
docker volume ls
docker inspect NOME_DO_CONTAINER --format '{{json .Mounts}}'Execute os comandos no host que realmente executa a aplicação. Confira o campo de mounts e identifique o volume ou caminho que contém os dados. Não faça limpeza enquanto esse inventário estiver incompleto.
Backup do painel Dokploy
Na documentação atual, a rotina em Web Server → Backups salva o banco dokploy-postgres e os arquivos de /etc/dokploy, enviando o conjunto para um destino S3 configurado. Essa é a recuperação da instância do painel.
Configure essa rotina separadamente dos backups da aplicação. Uma restauração do painel substitui sua configuração e banco existentes; ensaie em um ambiente de recuperação. Se a VPS mudar de IP, revise endereço do servidor, DNS e integrações.
Configurando armazenamento externo
Cadastre um destino S3 ou compatível no Dokploy e confira endpoint, bucket, região e credenciais. O nome e a localização dos campos podem variar conforme a versão instalada.
- Use um bucket privado com permissões restritas ao necessário.
- Proteja as credenciais e mantenha uma forma de recuperar o acesso fora da VPS.
- Habilite criptografia no armazenamento e considere criptografia antes do upload conforme os dados.
- Configure retenção e confirme se a exclusão é feita pelo painel ou por lifecycle do bucket.
- Verifique custos de armazenamento, versões e tráfego de recuperação.
Uma cópia em outra pasta da mesma VPS ajuda em erros pontuais, mas não cobre perda do servidor. Se o bucket estiver no mesmo domínio administrativo, avalie proteção contra exclusão e cópias adicionais.
Backup de bancos de dados
Usando os recursos do Dokploy
Para um banco criado como recurso de banco no painel, configure a aba Backup com destino, nome do banco, agendamento e prefixo. Execute o teste disponível e confirme o arquivo no bucket.
Um banco incluído em um Compose pode ter um fluxo diferente de um banco provisionado separadamente. Confira os recursos disponíveis nessa modalidade e versão. Se for necessário, use uma rotina de dump própria: copiar o volume do banco em atividade não garante consistência.
PostgreSQL
O pg_dump permite gerar uma cópia lógica de um banco. O formato customizado pode ser inspecionado e restaurado com pg_restore. Papéis e outros objetos globais precisam de tratamento adicional, por exemplo com pg_dumpall --globals-only, quando necessários.
Exemplo executado no host, usando o cliente disponível no container. Substitua os nomes e configure a autenticação de forma segura. O comando não usa TTY para evitar interferência no arquivo binário:
umask 077
mkdir -p /srv/backups/app
docker exec NOME_DO_CONTAINER_POSTGRES \
pg_dump -U USUARIO -d BANCO -Fc \
> /srv/backups/app/postgres.dumpConfira o código de saída e os logs. Um arquivo existente ou grande não demonstra integridade. Use um cliente compatível com o servidor e teste a restauração na versão de destino antes de depender da cópia.
MySQL e MariaDB
Use o utilitário correspondente ao motor: mysqldump para MySQL e mariadb-dump para MariaDB. Para tabelas transacionais InnoDB, --single-transaction permite uma leitura consistente sem a mesma abordagem de bloqueio global. Mudanças de estrutura durante o dump e tabelas não transacionais exigem planejamento próprio.
No exemplo abaixo, /run/secrets/backup.cnf é um arquivo previamente preparado dentro do container, legível somente pelo usuário autorizado, com as credenciais da conta de backup. Não passe a senha em texto na linha de comando.
docker exec NOME_DO_CONTAINER_MARIADB \
mariadb-dump --defaults-extra-file=/run/secrets/backup.cnf \
--single-transaction --quick --routines --events \
BANCO > /srv/backups/app/mariadb.sqlA conta precisa de permissões para os objetos incluídos. Caso a aplicação use rotinas, eventos ou usuários especiais, verifique a cobertura do dump e como recriá-los. Não presuma que exportar um banco inclui todas as contas do servidor.
Backup dos volumes Docker
Na área de Volume Backups, selecione serviço e volume, destino externo, agendamento e prefixo. A documentação diferencia execução com container parado e com container em funcionamento; parar o processo durante a cópia reduz o risco de arquivos sendo alterados.
Planeje a janela de indisponibilidade. Se vários serviços escrevem no mesmo volume, interromper apenas um pode ser insuficiente. Para dados de banco, prefira uma estratégia suportada pelo motor; arquivos de um banco não devem ser tratados como arquivos estáticos.
Em WordPress, coordene dump e arquivos para que representem um estado compatível, especialmente durante uploads e atualizações. Veja nossa instalação de WordPress com Dokploy para identificar os volumes da stack.
Automatizando backups
Agendamento e fuso horário
Use o agendador do painel quando ele cobrir o recurso. Para rotinas próprias, cron ou um timer do sistema são alternativas. Confirme o fuso utilizado pelo agendador: configurar o WordPress como America/Campo_Grande não altera automaticamente o relógio da VPS ou do Dokploy.
# Exemplo: executar diariamente às 02:00 no fuso do cron
0 2 * * * /usr/local/sbin/backup-app.shO script precisa controlar concorrência, falhas de dump, compressão, upload e retenção. Use nomes únicos com data, caminhos absolutos e uma conta com permissões adequadas. Não apague a última cópia válida antes de confirmar a nova.
Falhas que devem gerar alerta
- Dump ou cópia encerrados com erro.
- Upload não concluído ou destino sem permissão.
- Backup mais antigo que o intervalo permitido.
- Disco local ou quota do bucket próximos do limite.
- Teste de restauração que não consegue abrir a aplicação.
Se usar pipelines no Bash, habilite set -o pipefail para detectar falhas no comando anterior à compressão. Também limpe temporários com cuidado: a regra de limpeza deve atingir somente os arquivos dessa rotina.
Como restaurar uma aplicação
1. Prepare um destino separado
Crie um projeto de recuperação, volumes novos e banco vazio. Use versões compatíveis e restrinja o acesso. Desabilite e-mails, pagamentos, webhooks e tarefas que possam afetar sistemas reais.
2. Restaure o banco
Para backups nativos do Dokploy, use o fluxo de restauração correspondente. A documentação informa que arquivos produzidos pelo próprio painel têm formato reconhecido; dumps externos podem exigir importação manual.
Para um dump customizado do PostgreSQL, restaure em um banco de teste vazio, com autenticação configurada. Sem --clean, o exemplo evita uma etapa de remoção de objetos, mas ainda deve ser executado apenas no destino de teste preparado:
docker exec -i CONTAINER_POSTGRES_TESTE \
pg_restore -U USUARIO_TESTE -d BANCO_TESTE \
--no-owner --no-acl --exit-on-error \
< /srv/backups/app/postgres.dumpAo omitir owner e ACL, você precisa configurar os proprietários e permissões adequados no destino. Para SQL de MariaDB, use o cliente correspondente e revise comandos do arquivo que possam selecionar ou criar bancos antes de importar.
3. Restaure os arquivos e a configuração
Reponha os arquivos no volume correto antes de iniciar os processos que escrevem nele. Confira proprietário, permissões, variáveis, credenciais e montagem. Em uma recuperação em novo host, revise proxy, DNS e certificados.
4. Valide o funcionamento
- Faça login com um usuário de teste.
- Abra páginas e registros importantes.
- Verifique uploads e anexos.
- Execute uma escrita controlada e confirme a leitura.
- Confira logs, tarefas e conectividade com o banco.
- Registre data da cópia utilizada e duração total da recuperação.
Em WordPress, se usar outro domínio no teste, ajuste as URLs com uma ferramenta que respeite dados serializados. Não faça substituição indiscriminada diretamente no SQL.
Estratégia recomendada para uma VPS pequena
Como exemplo inicial, use cópia diária do banco e arquivos, backup anterior a mudanças importantes e teste mensal de recuperação. Mantenha sete cópias diárias, quatro semanais e três mensais se isso couber no orçamento e na necessidade do projeto. Essa retenção é uma sugestão, não uma regra universal.
Para reduzir riscos, mantenha uma cópia externa, uma segunda forma de recuperação das credenciais e um procedimento escrito. Aumente a frequência quando a perda tolerada for menor que um dia.
Se está comparando plataformas, nosso artigo Dokploy vs Coolify ajuda a avaliar a operação. A ferramenta escolhida não elimina a necessidade de testar restauração.
Checklist de backup
- Inventário de bancos, volumes e bind mounts atualizado.
- Backup do painel separado dos dados das aplicações.
- Cópias consistentes com logs de execução.
- Armazenamento externo privado e credenciais recuperáveis.
- Retenção definida e alertas de falha ativos.
- Restauração testada em ambiente isolado.
- Tempo de recuperação e perda máxima de dados registrados.
Para integrar essa rotina à manutenção do site, leia também WordPress em VPS: desempenho, segurança e manutenção.
Conclusão
Um plano de backup no Dokploy precisa responder três perguntas: quais dados estão protegidos, onde estão as cópias e como a aplicação será recuperada. Volumes preservam dados entre deploys; backups preservam uma possibilidade de recuperação.
Comece com uma rotina simples, confirme cada execução e ensaie a restauração. O teste transforma um arquivo no bucket em evidência de que você consegue voltar a operar.
Referências oficiais
- Dokploy: backup da instância
- Dokploy: backup de bancos
- Dokploy: restauração de bancos
- Dokploy: backup de volumes
- Docker: volumes e recuperação
- PostgreSQL: pg_dump
- PostgreSQL: pg_restore
- MariaDB: mariadb-dump
