Backups — qual usar e como usar

O Server Manager tem quatro áreas diferentes relacionadas a backup, cada uma para um objetivo diferente. Elas se sobrepõem conceitualmente ("salvar meus dados para eu não perdê-los"), mas, se você escolher a errada, vai acabar trabalhando mais do que precisa ou recebendo um arquivo que não faz o que você queria. Este artigo associa cada objetivo ao recurso certo e depois mostra cada fluxo.

Guia rápido — qual eu quero?

Recuperar um único arquivo (aba Arquivos → 🗑 Backups)

Use quando: você apagou ou sobrescreveu um arquivo pela aba Arquivos e quer recuperá-lo.

O Server Manager salva automaticamente todo arquivo que a aba Arquivos está prestes a sobrescrever ou apagar. A versão anterior vai para uma pasta .helm-backup/ no mesmo diretório em que o arquivo ficava. As 3 versões mais recentes de cada nome são mantidas; as mais antigas saem da rotação.

Importante — é por diretório. Se você apagou /var/www/site/blog/post.md, o backup fica em /var/www/site/blog/.helm-backup/, não dentro de /var/www/site/. Para encontrá-lo, primeiro você precisa navegar até o diretório onde o arquivo ficava.

Passos:

1. Abra o painel de serviço do site/app → aba Arquivos.

2. Navegue até a pasta onde o arquivo ficava — por exemplo, /var/www/mysite.example.com/blog/ se você apagou um arquivo em blog/.

3. Clique em 🗑 Backups na barra de ferramentas.

4. Encontre a entrada pelo nome + timestamp. Clique em Restaurar para colocá-la de volta, Baixar para salvar uma cópia no seu computador ou Apagar para remover o backup permanentemente do servidor.

A restauração também é reversível — antes de restaurar, o estado atual no caminho de destino é salvo em .helm-backup/, então você pode desfazer a restauração do mesmo jeito.

O que isto NÃO cobre: arquivos modificados via SFTP/FileZilla, SSH, pelo próprio app em execução ou por um redeploy. Só ações feitas na aba Arquivos acionam o backup automático. Para um redeploy em que você quer manter uma pasta, use .helm-keep.

Fazer backup de um site ou app inteiro (aba Backup)

Use quando: você quer um arquivo portátil de um site ou app inteiro — configurações, segredos, arquivos e, no caso de itens em contêineres, os volumes de dados — para guardar no seu computador com segurança ou transportar.

A aba Backup tem três ações, todas usando o mesmo formato de pacote. Elas formam o ciclo de vida de um pacote: criar → restaurar depois → ou transferir para outro servidor.

O que você verá no topo da aba. Se ainda houver pacotes deste serviço no servidor — normalmente porque você criou um backup e não baixou, ou porque um upload foi abandonado no meio da restauração — eles aparecem como uma lista no topo, com tamanho, timestamp e um botão Apagar em cada linha. Esta é sua área de limpeza: os pacotes não passam por rotação automática, então os antigos vão consumindo disco em silêncio até você removê-los. Se houver pacotes de outros serviços, você verá um pequeno aviso com a quantidade; abra a aba Backup do próprio serviço para limpá-los.

Fazer backup

1. Abra o painel de serviço → aba Backup.
2. Para WordPress, web apps e bancos de dados: marque Pausar o serviço durante o backup se este for um site movimentado (loja em funcionamento, área de membros, migração em andamento). O padrão é sem indisponibilidade — rápido e suficiente na maioria dos casos, mas qualquer coisa gravada durante a captura de ~30 s pode ficar capturada pela metade (normalmente um arquivo órfão: presente no backup, sem linha no banco). Com a pausa, o serviço para rapidamente (~30–60 s de indisponibilidade) para uma captura perfeitamente consistente. Sites estáticos não mostram esse alternador — não há processo gerenciado para pausar (Caddy serve os arquivos diretamente).
3. Clique em Fazer backup. O chat assume — o Faro prepara o comando tar, você aprova, e o pacote é criado no servidor.
4. Quando estiver pronto, um botão Baixar aparece no chat. Clique nele; o arquivo é transmitido via SFTP para o seu computador.

O que vem no pacote: o docker-compose.yml (ou o manifesto de serviço equivalente), todos os segredos em .env, todos os volumes nomeados (dados do banco de dados, arquivos enviados etc.) e um pequeno manifest.json descrevendo o serviço. Pacotes de sites estáticos incluem a árvore de arquivos em /var/www/<domain>/. O formato é autodescritivo — ao restaurar depois, o manifesto é lido e tudo é reconstruído no lugar certo.

Restaurar a partir de um pacote

Use quando: você tem um pacote que baixou antes (ou que alguém da equipe enviou) e quer trazer o serviço de volta — seja neste servidor, seja como um clone com um novo domínio.

1. Abra o painel de serviço → aba Backup.
2. Clique em Restaurar a partir de um pacote. Uma janela de upload é aberta (arraste e solte ou clique para escolher).
3. Escolha o pacote .tar.gz. Clique em Enviar.
4. Depois do upload, a restauração de fato acontece no chat. O Faro lê o manifesto do pacote e restaura no mesmo lugar ou — se a estrutura da receita do pacote não corresponder ao serviço atual, ou se você apontar para um domínio diferente — pergunta se deve cloná-lo para um novo domínio. Você revisa e aprova cada comando antes que qualquer coisa seja executada.

Para clonar: o pacote contém o domínio original no manifesto. O Faro pede o novo domínio e reescreve o Caddyfile + as referências equivalentes às do wp-config.php para que o clone responda no novo endereço. O servidor original continua rodando sem alterações.

Mover para outro servidor

Use quando: você tem um serviço em um dos seus servidores salvos e quer movê-lo (ou copiá-lo) para outro — sem precisar baixar manualmente o pacote para o seu computador e reenviá-lo do outro lado.

Este botão só aparece se você tiver pelo menos dois servidores salvos no Server Manager — o seletor de destino precisa ter para onde apontar.

Pré-requisito: faça um backup na origem primeiro (o passo Fazer backup acima).

1. No serviço do servidor de origem, abra o painel de serviço → aba Backup.
2. Clique em Mover para outro servidor. Um assistente de três etapas é aberto: - Etapa 1: Escolha o destino. Escolha um servidor de destino na sua lista de servidores salvos e informe a frase secreta de criptografia do destino. - Etapa 2: Escolha o backup. Escolha qual pacote transferir (lista todos os pacotes na origem). Clique em Iniciar transferência. - Etapa 3: Transferência. O pacote é transmitido da origem → destino pelo Server Manager — sem cópia no seu computador, sem S3 público no meio.
3. Quando o pacote chega ao destino, o Server Manager leva você para o servidor de destino e oferece restaurar o pacote que acabou de chegar (com um clique).

Fazer backup só do banco de dados (aba SQL Dumps)

Use quando: você só quer o conteúdo do banco de dados, não a stack inteira. Casos comuns: entregar os dados a um desenvolvedor para testes, importar em um mecanismo diferente (bem, tentar) ou salvar uma rede de segurança rápida antes de uma migração destrutiva.

Esta aba só existe para serviços de banco de dados (Postgres, MySQL, MariaDB).

1. Abra o painel de serviço do banco de dados → aba SQL Dumps.
2. Clique em Fazer dump. O Faro executa pg_dump / mysqldump (adequado ao mecanismo) e salva a saída como .sql.gz em /var/backups/<engine>/.
3. O novo dump aparece na lista. Baixar envia o arquivo para o seu computador; Apagar o remove do servidor.

SQL Dumps vs. aba Backup — mesmo serviço, artefatos diferentes:

• O .sql.gz da aba SQL Dumps é SQL bruto — psql my-app < dump.sql restaura em qualquer Postgres da versão principal correta, incluindo um Postgres rodando no seu notebook.
• O pacote da aba Backup é um .tar.gz de stack completa — o banco de dados, o arquivo compose, os segredos, os volumes nomeados. A restauração recria a stack inteira de contêineres.

Se você só precisa inspecionar ou mover dados: SQL Dumps. Se quer clonar o serviço de banco de dados inteiro em outro lugar: aba Backup.

Outras coisas que costumam ser confundidas com backups

**Marcadores .helm-keep* — preservam uma pasta entre redeploys* (não é backup, não ajuda em caso de exclusão acidental). Use quando você tem uma pasta usada em tempo de execução, como uploads/, e não quer que ela seja apagada ao enviar código novo. Explicado em Vários sites no mesmo servidor.

Mover um servidor inteiro. Não existe um único botão "mover tudo" — o Server Manager move um serviço por vez. Para migrar um servidor com vários sites/apps, repita o fluxo Fazer backup → Mover para outro servidor → Restaurar no destino para cada serviço (a ação Mover para outro servidor fica na aba Backup de cada serviço).

Referência

Onde os backups ficam no disco:

• Backups da aba Arquivos → <original-dir>/.helm-backup/<name>.<timestamp> (uma pasta por diretório)
• Pacotes da aba Backup → /tmp/helm-backups/<id>/<bundle>.tar.gz no servidor de origem (até você baixá-los ou apagá-los)
• Uploads da aba Restauração → /tmp/helm-restore/<id>/<bundle>.tar.gz (até a restauração terminar ou você apagá-los)
• SQL Dumps → /var/backups/<engine>/<dbname>-<timestamp>.sql.gz

Retenção:

• Aba Arquivos: as 3 versões mais recentes por nome original; a mais antiga sai da rotação.
• Aba Backup + SQL Dumps: sem rotação automática — os pacotes permanecem no servidor até você apagá-los pelo painel.

Ficar de olho no disco. Cada cartão de serviço na tela inicial mostra uma etiqueta · N GB ao lado do nome assim que há dados. Para ver uma análise mais detalhada, no cartão do servidor, Detalhes do servidor → abre Informações do servidor com uma aba Armazenamento que lista o uso de disco por serviço (do maior para o menor, com links para abrir o painel com um clique), dumps SQL de todos os mecanismos e uma visualização de limpeza em massa de todos os pacotes temporários no servidor. A tela inicial também mostra um cartão de alerta amarelo/vermelho quando o uso de disco passa de 80% / 90%.

Segredos nos pacotes: os arquivos .env dentro de um pacote da aba Backup contêm segredos em texto puro (senhas de banco de dados, chaves de API etc.). Trate os pacotes baixados como trataria os arquivos .env originais — não envie por e-mail, não faça commit, não deixe em drives compartilhados. Os pacotes são apagados do servidor de origem após o download (o arquivo transmitido para você era uma cópia).