Como configurar backup de site em VPS e testar a restauração

Configurar o backup de site em VPS é uma daquelas tarefas que parecem simples até o dia em que a cópia precisa funcionar. Em um servidor virtual, quem cuida dos dados é você: o provedor entrega a máquina, e a responsabilidade pelo conteúdo, pelo banco de dados e pelas configurações fica com o dono do projeto.

Este guia é para quem mantém um blog, uma loja virtual, uma automação com n8n ou sites de clientes em um VPS. Vamos mostrar o que copiar, onde guardar, como automatizar a rotina e, principalmente, como testar a restauração. Uma cópia que nunca foi restaurada é só uma promessa, e boa parte deste texto existe para transformar essa promessa em algo comprovado.

Backup, snapshot e cópia incremental: o que muda na prática?

Antes de configurar qualquer coisa, vale alinhar alguns termos. Eles aparecem em todos os painéis de hospedagem e costumam ser confundidos.

• Backup é uma cópia de segurança guardada em outro lugar, que permite recuperar arquivos perdidos, apagados ou corrompidos.

• Snapshot é uma “fotografia” do disco inteiro em um momento exato. Serve para voltar atrás depois de uma atualização que deu errado, mas normalmente fica na mesma infraestrutura do servidor.

• Backup completo copia tudo, toda vez.

• Backup incremental salva apenas o que mudou desde a última cópia, por isso é mais rápido e ocupa menos espaço.

• Backup diferencial salva o que mudou desde o último backup completo.

• Dump é a exportação do banco de dados para um arquivo, geralmente .sql, que pode ser importado de volta.

Na prática, o snapshot funciona como um botão de desfazer, e o backup funciona como um seguro. Em alguns provedores o limite fica bem claro: há painéis que guardam apenas um snapshot por vez e o apagam quando o sistema operacional é reinstalado. Por isso o snapshot complementa a rotina de backup e nunca ocupa o lugar dela.

O que precisa entrar no backup para o site voltar a funcionar?

Muita gente copia só a pasta do site e descobre o problema na hora da restauração. Um site em VPS depende de várias peças, e todas precisam estar na cópia:

• arquivos do site: código, temas, plugins e imagens enviadas pelos usuários (no WordPress, a pasta wp-content);

• dump do banco de dados: posts, pedidos, cadastros e configurações;

• configurações do servidor web: arquivos do Nginx ou Apache e do PHP;

• variáveis de ambiente: arquivos como .env, com senhas e chaves de API;

• tarefas agendadas: o crontab;

• certificados SSL e as configurações de renovação.

O banco de dados pede um cuidado extra. Copiar os arquivos internos do MySQL ou do PostgreSQL enquanto o serviço está rodando pode gerar uma cópia inconsistente, que não abre depois. O caminho seguro é gerar um dump e incluir esse arquivo no backup.

Com que frequência fazer backup e quanto tempo você aceita ficar fora do ar?

Duas siglas ajudam a responder essa pergunta sem chute:

• RPO (Recovery Point Objective) é quanto dado você aceita perder. Ele define a frequência das cópias.

• RTO (Recovery Time Objective) é quanto tempo o site pode ficar fora do ar até voltar a funcionar.

Um exemplo simples: uma loja virtual recebe pedidos o dia todo. Se a última cópia é de ontem à noite e o servidor falha às 16h, todos os pedidos do dia somem. Para ela, faz sentido um RPO de poucas horas. Um site institucional que muda uma vez por mês pode viver bem com cópias semanais.

Como referência geral:

• lojas virtuais e sistemas com cadastro: dump do banco várias vezes ao dia e arquivos diariamente;

• blogs e portais com publicações frequentes: cópia diária;

• sites estáticos ou pouco atualizados: semanal ou mensal, e sempre antes de mudanças.

Onde guardar as cópias para que um ataque não leve tudo junto?

O lugar da cópia importa tanto quanto a cópia. Um backup guardado na mesma pasta, no mesmo disco ou no mesmo VPS some junto com o servidor.

A referência mais usada é a regra 3-2-1:

• 3 cópias dos dados (a original e mais duas);

• 2 tipos de armazenamento diferentes;

• 1 cópia fora do local principal, como um armazenamento em nuvem ou outro servidor.

A Veeam propõe uma versão ampliada, a 3-2-1-1-0. Ela acrescenta uma cópia imutável ou offline, que ninguém consegue alterar, e zero erros nos testes de restauração.

Esse cuidado extra tem motivo. Segundo levantamento da ISH Tecnologia, os ataques de ransomware cresceram 17,8% no mundo em 2025, e o Brasil ficou em 9º lugar no ranking global, liderando a América Latina. O mesmo estudo aponta que destruir os backups da vítima virou etapa padrão dos ataques mais sofisticados. Se o invasor alcança o servidor e as cópias com a mesma senha, a regra 3-2-1 perde o efeito.

Boas opções para a cópia externa:

• armazenamento de objetos compatível com S3;

• um segundo VPS dedicado só a receber backups;

• serviços de nuvem como Google Drive ou Backblaze B2, para projetos menores.

Como configurar o backup automático VPS passo a passo?

A rotina abaixo combina a proteção do provedor com uma cópia própria, fora do servidor. Ela funciona para a maioria dos sites em Linux.

Passo 1. Ative o backup oferecido pelo provedor

O backup do provedor é a primeira camada e exige poucos cliques. Na Serverspace, a cópia de reserva é feita uma vez por dia em um array de discos geograficamente separado, e no painel você escolhe por quanto tempo guardar as cópias, de uma a quatro semanas. As cópias mais antigas que o período escolhido são apagadas automaticamente. Antes de contar com o recurso, confirme no painel se ele está disponível para o tipo de servidor que você usa.

Essa camada cobre falhas de disco e erros graves no sistema. Ela fica sob a mesma conta do servidor, então a cópia própria continua necessária.

Passo 2. Gere o dump do banco de dados antes da cópia

Crie um script que exporte o banco para um arquivo antes de cada backup. Para MySQL ou MariaDB:

Para PostgreSQL, o equivalente é o pg_dump:

Em produção, guarde a senha em um arquivo de configuração protegido em vez de digitá-la no comando.

Passo 3. Escolha a ferramenta que vai enviar a cópia para fora do servidor

A escolha depende da sua familiaridade com o terminal:

• Painéis como cPanel/WHM ou CyberPanel. Têm assistentes visuais para agendar cópias diárias ou semanais e enviá-las para um destino externo. O CyberPanel, por exemplo, consegue mandar o arquivo direto para o Google Drive.

• Restic. Faz cópias incrementais, sempre criptografadas e com deduplicação. Grava em pasta local, SFTP, S3, Backblaze B2 e outros destinos. Em VPS com pouca memória pode travar durante tarefas pesadas de manutenção.

• BorgBackup. Também criptografa e deduplica, e costuma ser mais rápido quando o destino é outro servidor Linux acessível por SSH.

Um exemplo mínimo com Restic enviando a cópia para outro servidor:

A tabela resume as opções mais comuns:

Passo 4. Agende a rotina e configure alertas de falha

Junte o dump e o envio em um script e agende com o cron. Para rodar todo dia às 3h da manhã:

Escolha um horário de pouco acesso. Depois, configure um aviso por e-mail, Telegram ou Slack para quando o script falhar. Sem alerta, uma rotina quebrada pode passar semanas despercebida.

Defina também a retenção, ou seja, quantas cópias manter. Um esquema comum é guardar 7 cópias diárias, 4 semanais e 6 mensais. Retenção longa dá tempo de perceber um ataque silencioso antes que todas as cópias estejam contaminadas.

Passo 5. Faça um snapshot antes de qualquer atualização

Antes de atualizar o PHP, o sistema operacional, o WordPress ou plugins importantes, crie um snapshot manual. Se algo quebrar, você volta ao estado anterior em minutos, sem mexer na rotina de backup.

Como testar a restauração sem derrubar o site em produção?

Esta é a etapa que quase todo mundo pula. Testar a restauração mostra se a cópia abre, se está completa e quanto tempo leva para colocar o site no ar.

O jeito mais seguro é fazer um simulado em um servidor separado, sem tocar no site em produção. Um VPS temporário serve bem para isso. Na Serverspace, um servidor VPS no data center de São Paulo fica pronto em cerca de 40 segundos, e a cobrança é feita a cada 10 minutos. Você cria a máquina, faz o teste e a exclui, pagando apenas pelo tempo de uso.

Roteiro do simulado:

1. Crie o servidor de teste com o mesmo sistema operacional do servidor principal.

2. Baixe a cópia do armazenamento externo e descompacte em uma pasta temporária.

3. Restaure os arquivos do site no diretório correto e ajuste dono e permissões (no Nginx com PHP, geralmente o usuário www-data).

4. Crie o banco vazio e importe o dump, por exemplo com mysql -u root -p nome_do_banco < site.sql.

5. Restaure configurações e crontab e reinicie os serviços.

6. Acesse o site pelo IP do servidor de teste ou por um subdomínio temporário.

7. Verifique o que importa: páginas abrem, login funciona, formulários enviam, imagens aparecem, pedidos recentes estão no banco e os e-mails saem.

8. Anote o tempo total e compare com o RTO que você definiu.

9. Apague o servidor de teste.

Se algo falhar, ótimo: você descobriu o problema em um dia tranquilo, com tempo para corrigir o script.

Faça o teste pelo menos uma vez por trimestre e sempre depois de mudanças grandes, como troca de versão do PHP, migração de banco ou novo plugin de pagamento. Registre a data, a cópia usada e o resultado. Esse histórico ajuda em auditorias e na conversa com clientes.

O que o backup resolve e onde ele tem limites?

Uma rotina bem feita resolve muita coisa:

• erro humano: arquivo apagado, plugin que quebrou o layout, tabela excluída por engano;

• invasão e ransomware: o site volta a partir de uma cópia limpa;

• atualização malsucedida: o snapshot ou a última cópia desfazem o estrago;

• falha de hardware: a cópia externa sobrevive ao servidor.

Também existem limites que precisam estar claros:

• perda entre cópias: tudo o que aconteceu depois do último backup se perde;

• custo de armazenamento: retenção longa ocupa espaço e custa dinheiro;

• chave de criptografia: se a senha do repositório se perder, a cópia fica ilegível;

• tempo de restauração: sites grandes podem levar horas para voltar;

• cópia contaminada: se o invasor estava no servidor há semanas, as cópias recentes podem carregar o problema.

Por que a LGPD torna a cópia testada uma obrigação do negócio?

Se o site guarda dados de clientes, como nome, e-mail, endereço ou histórico de compras, o backup passa a ser também uma questão legal.

O artigo 46 da LGPD exige que os agentes de tratamento adotem medidas técnicas e administrativas para proteger dados pessoais contra destruição, perda e alteração. A Resolução CD/ANPD nº 15/2024 detalha o que acontece quando algo dá errado:

• um ransomware que deixa o banco de dados inacessível é um incidente de segurança, porque afeta a disponibilidade dos dados;

• quando o incidente pode causar risco ou dano relevante, o controlador deve comunicar a ANPD e os titulares em até 3 dias úteis;

• agentes de pequeno porte têm o prazo em dobro, 6 dias úteis;

• o registro do incidente deve ser mantido por pelo menos cinco anos.

Uma cópia recente e testada reduz o dano, encurta o tempo fora do ar e facilita explicar à autoridade quais medidas estavam em vigor. A localização dos dados também conta. Na Serverspace, os servidores brasileiros ficam no data center Equinix SP3, em São Paulo, que segue a ISO 27001 e tem certificação Tier III do Uptime Institute. Os dados permanecem no país e perto do público.

Como montar a rotina de backup em cinco situações comuns?

Blog em WordPress

Copie a pasta wp-content, o arquivo wp-config.php e o dump do banco diariamente. No simulado, confira se as imagens antigas aparecem e se o painel /wp-admin abre com o login normal.

Loja virtual com WooCommerce

O banco é a parte mais sensível, porque guarda pedidos e clientes. Faça dumps a cada poucas horas e envie para fora do servidor. No teste, procure os pedidos mais recentes e simule uma compra completa.

Automação com n8n

Os fluxos e as credenciais ficam no banco do n8n e na pasta de dados. Inclua também a chave de criptografia definida na instalação: sem ela, as credenciais restauradas não funcionam. Teste executando um fluxo simples no servidor temporário.

Agência com vários sites de clientes

Um único repositório Restic pode receber cópias de vários servidores ao mesmo tempo, e a deduplicação economiza espaço quando os sites usam os mesmos arquivos. Organize as cópias por cliente e mantenha um calendário de testes, com um site por semana.

Atualização de PHP ou do sistema operacional

Faça um backup completo e um snapshot antes de começar. Se possível, rode a atualização primeiro em um servidor de teste restaurado a partir da cópia. Assim você valida a restauração e a atualização de uma vez.

Quais erros fazem o backup falhar justamente quando você precisa dele?

• Guardar a cópia no mesmo VPS. Se o servidor cai ou é invadido, a cópia vai junto. Envie sempre uma versão para fora.

• Nunca testar a restauração. Arquivos corrompidos e pastas esquecidas só aparecem no simulado. Teste a cada trimestre.

• Copiar o banco sem dump. Gere o arquivo .sql antes de cada backup.

• Esquecer configurações. Sem .env, crontab e configs do servidor web, o site restaurado não sobe. Revise a lista do que entra na cópia.

• Perder a chave de criptografia. Guarde a senha do repositório em um gerenciador de senhas, longe do servidor.

• Retenção curta demais. Com só três dias de cópias, um ataque percebido na semana seguinte já contaminou tudo. Mantenha cópias semanais e mensais.

• Rotina sem alerta. Configure um aviso de falha para não descobrir o problema tarde demais.

• Tratar snapshot como backup. O snapshot ajuda no dia a dia, mas fica na mesma infraestrutura e pode sumir com uma reinstalação.

Conclusão: por onde começar hoje

Um backup de site em VPS confiável tem quatro partes: saber o que copiar, automatizar a rotina, guardar uma cópia fora do servidor e testar a restauração com frequência. A última parte é a que transforma um arquivo guardado em uma garantia de que o site volta ao ar.

Para começar ainda hoje:

1. ative o backup do provedor e defina a retenção;

2. crie o script com dump do banco e envio para um destino externo;

3. agende a rotina e configure o alerta de falha;

4. marque na agenda a data do primeiro simulado de restauração em um servidor temporário.