Backup de site: como fazer e testar a restauração

O que copiar e como, com comandos de tar, mysqldump e cron, retenção das cópias antigas e um roteiro de restauração para provar que o backup funciona.

Por Redação Eleven Host · @robson.direitodigital · Atualizado em 18 de outubro de 2026 · 8 min de leitura

Backup de site é uma cópia dos arquivos, do banco de dados e das configurações que você consegue restaurar. Aqui estão o que copiar, os comandos com tar e mysqldump, a automação com cron, a retenção e o teste de restauração que prova que a cópia presta.

Guardar a cópia fora do servidor, a regra 3-2-1 e as ferramentas de envio têm guia próprio: backup off-site. Este texto cuida do que vem antes: o que entra na cópia, como gerá-la e como saber se ela funciona.

O que entra no backup de um site

Quem copia só a pasta do site descobre na hora da restauração que faltava metade. Faça a lista do que o seu site precisa para voltar a funcionar:

• Arquivos: código, temas, imagens e arquivos enviados pelos usuários.
• Banco de dados: posts, produtos, pedidos, cadastros. Sem ele, a cópia dos arquivos de um site dinâmico é uma casca vazia.
• Configurações do servidor: o arquivo de configuração do site no Nginx ou no Apache e ajustes de PHP que o site exige.
• Certificados e tarefas agendadas: os certificados HTTPS (ou o registro de como foram emitidos) e a saída de crontab -l.
• E-mails: só se as caixas moram no mesmo servidor. Se o e-mail está em outro lugar, o backup dele é lá.

Segredos exigem cuidado: o wp-config.php e arquivos de configuração trazem senha de banco. Trate a cópia como dado sensível: pasta com acesso restrito e permissão 600 nos arquivos.

Arquivos com tar

O tar empacota e compacta a pasta do site em um arquivo com a data no nome. Crie antes a pasta de destino (aqui /srv/backup, com dono o seu usuário) e rode:

tar -czf /srv/backup/site-$(date +%F).tar.gz -C /var/www meusite

O -C /var/www faz o tar entrar na pasta antes de empacotar, então o arquivo guarda meusite/... em vez do caminho completo. O $(date +%F) vira a data no formato 2026-10-18, e arquivos ordenados por nome ficam em ordem cronológica. Confira o conteúdo sem extrair nada:

tar -tzf /srv/backup/site-2026-10-18.tar.gz | head

Banco de dados com mysqldump

Para uma cópia manual, o -p sem valor faz o programa perguntar a senha, que não fica no histórico do terminal:

mysqldump --single-transaction -u usuario -p nome_do_banco | gzip > /srv/backup/banco-$(date +%F).sql.gz

A opção --single-transaction tira uma foto consistente das tabelas InnoDB sem travar o site durante a cópia.

No cron ninguém digita a senha. Em vez de escrevê-la no comando, crie um arquivo de credenciais só seu, por exemplo /home/usuario/.backup.cnf, com permissão restrita (chmod 600 /home/usuario/.backup.cnf):

[client]

user=usuario_do_banco

password=defina-a-senha-aqui

O mysqldump lê esse arquivo com --defaults-extra-file=/home/usuario/.backup.cnf, e essa opção precisa ser a primeira da linha.

WordPress: wp-content e banco

Em um WordPress, o que importa é a pasta wp-content (temas, plugins, uploads), o banco e o wp-config.php. Com o WP-CLI, dentro da pasta do site:

wp db export /srv/backup/wp-banco-$(date +%F).sql

tar -czf /srv/backup/wp-content-$(date +%F).tar.gz wp-content

Guarde também uma cópia do wp-config.php, com o cuidado de segredo já descrito. Quem prefere plugin de backup pode usá-lo, mas confira os mesmos pontos: o que ele inclui (arquivos e banco), onde grava a cópia e se você consegue restaurar sem ele instalado.

Automação com cron e retenção

Junte os comandos em um script e deixe o cron rodar. O script abaixo, salvo como /home/usuario/backup-site.sh, faz a cópia e depois apaga as antigas. Cada linha vai separada para você copiar com calma:

#!/bin/bash

set -euo pipefail

umask 077

DEST=/srv/backup

DATA=$(date +%F)

tar -czf "$DEST/site-$DATA.tar.gz" -C /var/www meusite

mysqldump --defaults-extra-file=/home/usuario/.backup.cnf --single-transaction nome_do_banco | gzip > "$DEST/banco-$DATA.sql.gz"

find "$DEST" -name 'site-*.tar.gz' -mtime +14 -delete

find "$DEST" -name 'banco-*.sql.gz' -mtime +14 -delete

O set -euo pipefail interrompe o script se a cópia falhar, então as cópias antigas só são apagadas depois que a nova foi gerada. O umask 077 deixa as cópias novas legíveis só pelo dono, porque o banco guarda dados que não podem ficar abertos a outros usuários do servidor. Dê permissão de execução com chmod 700 /home/usuario/backup-site.sh. Os 14 dias são só um exemplo: quantas cópias guardar é decisão sua.

Antes de confiar na limpeza, rode a busca sem apagar, trocando -delete por -print, e veja se a lista traz só o que você aceita perder. Depois, abra o agendador com crontab -e e acrescente (o primeiro arquivo recebe o que deu certo; o segundo, os erros):

# todo dia às 2h30: roda o backup e guarda o resultado no log

30 2 * * * /home/usuario/backup-site.sh >> /home/usuario/backup-site.log 2>> /home/usuario/backup-erro.log

Olhe os dois arquivos de log e o tamanho das cópias de vez em quando, porque cron que falha em silêncio passa despercebido.

Com que frequência: pela taxa de mudança

A pergunta que decide é: quanto trabalho você aceita perder? Se a resposta for "um dia de pedidos", o backup diário do banco basta. Se for "uma hora", o banco precisa de cópias mais próximas.

Loja virtual: o banco muda a cada pedido e merece cópia própria, em cron separado e em intervalo menor que o dos arquivos (por exemplo, a cada hora, na linha 0 * * * *). Os arquivos mudam quando você publica produto novo.

Site institucional: muda pouco. Um backup diário ou semanal resolve, mais uma cópia manual antes de qualquer atualização grande.

A frequência é decisão do dono do site, não do comando.

Quer um servidor seu para rodar o site e os backups? Ver planos de VPS

Como saber se o backup presta

Teste a cópia em três níveis, do mais barato ao mais confiável:

1. Abrir o arquivo: tar -tzf lista o pacote de arquivos e gzip -t /srv/backup/banco-2026-10-18.sql.gz acusa arquivo corrompido. O silêncio do gzip -t é o bom sinal.
2. Ver o fim do dump: zcat /srv/backup/banco-2026-10-18.sql.gz | tail -n 3 deve mostrar o comentário de conclusão do mysqldump, o que indica que a exportação não parou no meio.
3. Restaurar em um ambiente de teste: é o único teste que prova que o backup volta a funcionar.

Compare também o tamanho com o das cópias anteriores. Queda brusca é sinal de problema, ainda que o arquivo abra.

Restauração passo a passo

Faça num servidor de teste ou na sua máquina, com o mesmo software do site. Se o destino for um servidor novo, o roteiro de migração de site detalha a conferência e o teste antes de apontar o DNS.

1. Arquivos: tar -xzf /srv/backup/site-2026-10-18.tar.gz -C /var/www recria a pasta meusite.
2. Banco: crie um banco vazio com mysql -u usuario -p -e "CREATE DATABASE nome_do_banco CHARACTER SET utf8mb4;" e importe: gunzip -c /srv/backup/banco-2026-10-18.sql.gz | mysql -u usuario -p nome_do_banco.
3. Configuração: confira no arquivo de configuração do site o nome do banco, o usuário e a senha.
4. Permissões: o dono dos arquivos deve ser o usuário do servidor web (em Debian e Ubuntu, www-data), ou o site não consegue gravar.
5. Teste: abra a página inicial, uma página interna, faça login e envie um formulário.

Anote quanto tempo levou. Esse número é o tempo que o seu site ficaria fora do ar de verdade em um problema.

Três situações em que você vai precisar dele

Atualização que quebrou o site. Restaure a cópia da véspera dos arquivos e, se a atualização mexeu no banco, do banco também. Teste antes de reabrir.

Invasão. Escolha uma cópia de data anterior ao problema. Restaurar a cópia de ontem, se o invasor já estava dentro, traz o invasor junto. Troque senhas e chaves depois de restaurar.

Tabela apagada por engano. Importe o dump em um banco de teste, exporte só a tabela que faltava e recoloque no banco de produção, em vez de sobrescrever tudo e perder o que entrou depois da cópia.

Dúvida sobre os serviços da Eleven antes de montar o seu backup? Falar com a equipe

Em uma VPS, prepare-se para cuidar de atualização, backup e segurança, e confirme com a equipe o que a Eleven faz. Valores da loja em outubro de 2026, para confirmar antes de contratar: Bronze (1 vCPU, 4 GB de RAM, 30 GB NVMe) a R$ 17,00/mês.

Perguntas frequentes

Posso guardar o backup no mesmo servidor do site?

Serve para voltar de um erro de atualização, mas se o servidor falhar a cópia vai junto. Envie também para outro lugar, como explica o guia de backup off-site.

O backup precisa incluir o banco de dados?

Em sites dinâmicos, sim. Conteúdo, pedidos e usuários ficam no banco.

Como o cron faz o backup do banco sem a senha no comando?

Não precisa: use um arquivo de credenciais com permissão restrita e a opção --defaults-extra-file.

De quanto em quanto tempo testar a restauração?

Decida um intervalo e anote no calendário. Teste também depois de mudar o servidor, o banco ou o script.