Backups e Restauração

O PrimeForge inclui um sistema portátil e criptografado de backup e restauração para os seus sites gerenciados. Cada backup é criptografado com AES-256 antes de ser gravado em disco e pode ser guardado localmente no servidor, enviado para um bucket compatível com S3 ou gerado como um download único e temporário. O objetivo é simples: você deve conseguir recuperar um site depois de uma alteração arriscada, uma falha de disco ou até recriá-lo em outro servidor da sua organização — sem depender de acesso manual por SSH.

Esta página explica como criar e restaurar backups, como funciona a criptografia de chave dupla, quais destinos existem, como funciona a retenção e como restaurar um site em um servidor diferente daquele em que ele foi criado.

#Como o backup funciona

Todo backup é feito no próprio servidor onde o site roda: o Agent coleta os componentes escolhidos (banco de dados, storage/, .env, arquivos de configuração etc.), monta um arquivo tar.gz, criptografa esse arquivo e grava o resultado (.tar.gz.enc). O arquivo não criptografado é apagado imediatamente após a criptografia, e um checksum SHA-256 do arquivo cifrado é guardado para verificação de integridade na hora de restaurar.

#Criptografia de chave dupla

A criptografia usa um esquema de duas chaves combinadas, para que nem o painel sozinho nem você sozinho consigam abrir o backup:

1. Sua senha — informada por você no momento de criar o backup. Ela nunca é armazenada de forma permanente: fica apenas na cache do painel por, no máximo, 10 minutos enquanto o job de backup roda, e é apagada assim que a criptografia termina. Nunca é gravada em disco, em log, nem incluída no payload da fila.
2. Chave do servidor — 32 bytes aleatórios gerados exclusivamente para aquele backup e guardados de forma criptografada no banco do painel.

As duas são combinadas por uma derivação HKDF-SHA256 para produzir a chave final de 256 bits usada na criptografia:

chave_final = HKDF-SHA256(sua_senha + chave_do_servidor)

Na prática, isso significa que:

• Conhecer apenas a senha não basta para descriptografar — falta a chave do servidor.
• Conhecer apenas a chave do servidor não basta — falta a sua senha.
• Os dois fatores são obrigatórios para qualquer restauração.

Aviso importante sobre a senha. A sua senha de criptografia é a única forma de abrir o backup, e o PrimeForge não a armazena. Se você perdê-la, o backup se torna permanentemente irrecuperável — não existe recuperação, redefinição ou suporte que consiga abrir o arquivo. Guarde a senha em um gerenciador de senhas (1Password, Bitwarden etc.), rotulada com o nome do site e a data do backup.

#Aviso legal na primeira utilização

Na primeira vez que você usar o recurso de backups, o painel exibe um modal de aviso legal que você precisa aceitar antes de continuar. Ele cobre três pontos essenciais: a sua responsabilidade sobre a senha (o PrimeForge não pode recuperá-la), a política de "sem garantias" quanto à integridade dos dados restaurados, e os termos de retenção dos arquivos. Leia com atenção — ao aceitar, você confirma que entende que uma senha perdida significa um backup perdido.

#Criando um backup

1. Acesse Backups na barra lateral (ou use a ação Backup no menu Mais da página de visão geral de qualquer site).
2. Clique em Criar Backup.

3. Selecione o site de origem na lista.
4. Escolha quais componentes incluir (veja a tabela abaixo).
5. Escolha um destino: Armazenamento Local, S3-Compatível ou Somente Download.
6. Informe uma senha de criptografia.
7. Clique em Criar.

O job roda em segundo plano e o status é atualizado em tempo real na lista de backups. Cada linha mostra o site, o destino, o tamanho, o status e a data.

#Componentes do backup

Você escolhe exatamente o que entra em cada backup. Os padrões cobrem o essencial para recuperar um site funcional:

O componente Origens de serviço é o que viabiliza a restauração entre servidores (veja mais abaixo): ele registra, no momento do backup, se o banco, o Redis, o S3 e o Reverb estavam no próprio servidor (interno) ou em outro servidor da malha (externo).

#Destinos de armazenamento

#Armazenamento local

O arquivo criptografado fica no próprio servidor onde o site roda. É a opção mais simples e não exige nenhuma configuração externa.

• Retenção: 30 dias por padrão (configurável pela organização).
• Acesso: você pode baixar o backup pelo painel a qualquer momento dentro do período de retenção.
• Risco: se o disco do servidor falhar, os backups locais se perdem junto — por isso, para sites críticos, prefira um destino externo.

#Bucket compatível com S3

O arquivo é criptografado localmente e, em seguida, enviado para um bucket compatível com S3. É a opção recomendada para manter os backups fora do servidor — se o servidor falhar, os backups sobrevivem. É compatível com AWS S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, MinIO em outro servidor e qualquer API S3 (sempre com endereçamento path-style).

Os destinos S3 e as suas credenciais são configurados na página de preferências de backup da organização (veja a seção a seguir). Se o envio ao S3 falhar, o backup cai automaticamente para armazenamento local e o erro é registrado nos metadados — você não fica sem cópia. Há também a opção de manter uma cópia local após o envio (habilitada por padrão), para que o backup continue baixável e restaurável sem precisar buscar no S3.

#Somente download

O arquivo é criado no servidor e fica disponível para download imediato. Depois de um tempo de vida configurável (TTL, por padrão 24 horas), ele é apagado automaticamente do servidor. É ideal para um backup rápido e único antes de uma alteração arriscada — você baixa o arquivo, guarda onde quiser e o painel limpa o servidor sozinho.

#Restaurando um backup

#Pré-requisitos

Antes de restaurar, confirme que:

• O site de destino existe e tem o modo de banco e os serviços corretos habilitados.
• O servidor de destino oferece os serviços necessários (PostgreSQL, Redis etc.) compatíveis com as origens de serviço do backup.
• Você tem em mãos a senha de criptografia usada quando o backup foi criado.

#Processo de restauração

1. Na lista de Backups, localize um backup com status Pronto.
2. Clique em Restaurar.
3. Informe a senha de criptografia.
4. Confirme a restauração.

O PrimeForge então: verifica o checksum SHA-256 do arquivo criptografado, descriptografa o backup usando a sua senha combinada com a chave do servidor, para os containers do site, substitui o banco de dados, o storage/, o ambiente e os arquivos de configuração, e reinicia os containers.

#Restauração entre servidores (cross-server)

O modal de restauração oferece dois alvos: mesmo site e servidor diferente. Escolha servidor diferente para recriar o site em outro servidor da sua organização — útil para migrar um site de um servidor para outro, ou para recuperar um site em um servidor novo depois de uma falha.

Aqui é onde o componente Origens de serviço entra em ação. Como o backup registra se cada serviço era interno ou externo, o painel valida o destino antes de começar:

• Se nenhum servidor da organização oferecer um serviço interno obrigatório (por exemplo, não há PostgreSQL disponível), o painel bloqueia a restauração antes de prosseguir e avisa o que falta.
• Nesse caso, provisione os serviços ausentes no servidor de destino e tente novamente.
• As referências a serviços cross-server (host de DB / Redis / S3 / Reverb) são preservadas a partir dos metadados do backup, de modo que o site recriado se reconecta aos mesmos hosts.

Isso significa que um site do Servidor de Sites que usa o PostgreSQL e o Redis do Servidor Principal pela malha WireGuard pode ser restaurado corretamente, contanto que o painel encontre esses serviços na organização.

#Retenção e limpeza

O PrimeForge roda uma rotina diária de limpeza que gerencia o ciclo de vida dos arquivos de backup:

Os registros no banco (metadados, checksums, datas) são sempre preservados, mesmo depois que o arquivo é removido. Assim, o histórico de backups continua visível no painel, mesmo para backups já expirados.

#Preferências e destinos de backup da organização

As configurações globais de backup ficam na página de preferências de backup da organização. É aqui que você define os destinos disponíveis (além do disco local de cada servidor) e os padrões de retenção que valem para toda a organização.

Nessa página você configura:

• Destino S3-compatível — chave de acesso, chave secreta, região, nome do bucket, endpoint e prefixo de caminho dentro do bucket. Uma vez configurado, o destino S3 passa a aparecer como opção no modal de criação de backup. Compatível com AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean Spaces e MinIO em outro servidor.
• Manter cópia local — se, após o envio ao S3, o arquivo criptografado também deve permanecer no servidor (habilitado por padrão).
• Somente download — o backup é gerado, criptografado e mantido por um curto período para um download único, sem armazenamento de longo prazo.
• Padrões de retenção — por quantos dias manter os backups locais e por quantas horas manter os backups de somente download.

#Boas práticas

• Teste as suas restaurações. Um backup que você nunca restaurou não é um backup de verdade. Periodicamente, restaure um backup de produção em um site de teste (no mesmo servidor ou em outro) e confirme que a aplicação funciona.
• Guarde os backups fora do servidor. Backups locais são práticos, mas ficam no mesmo disco da aplicação. Use um destino S3-compatível para manter cópias em outro sistema.
• Mantenha várias gerações. Não dependa de um único backup. Com a retenção padrão de 30 dias, o painel mantém várias versões; para sites críticos, faça backups diários ou antes de cada deploy.
• Documente as senhas. Use um gerenciador de senhas e rotule cada senha com o nome do site e a data. Uma senha perdida é um backup perdido.

#Próximos passos

• Deploys e Rollback — como o pipeline de deploy e as releases atômicas protegem o site durante mudanças.
• Gerenciando Sites — configuração de serviços (banco, Redis, S3) que definem o que entra em cada backup.
• Segurança — como o PrimeForge criptografa dados em trânsito e em repouso.