Backups WordPress: Como Testar Restauros e Porque a Maioria Falha

Existe uma diferença fundamental entre ter backups e ter backups que funcionam. A maioria dos sites WordPress tem alguma forma de backup configurada — mas quando acontece um desastre real, uma fracção significativa desses backups falha no restauro. Este artigo explica porquê e como evitar.

Os três tipos de falha de backup

Quando um restauro falha, a causa geralmente enquadra-se em uma de três categorias:

• Backup incompleto — os ficheiros foram copiados mas a base de dados foi esquecida, ou vice-versa. Um site WordPress precisa de ambos para funcionar.
• Backup corrompido — o arquivo zip ou tar foi interrompido a meio, o disco estava cheio, ou houve erro de transferência. O ficheiro existe mas está danificado.
• Backup desactualizado — o último backup bem-sucedido é de 3 semanas atrás porque o processo falhou silenciosamente entretanto.

O problema comum aos três: ninguém verificou. Um backup que nunca foi testado é uma ilusão de segurança.

Anatomia de um backup WordPress completo

Um backup WordPress completo e restaurável inclui obrigatoriamente:

• Todos os ficheiros da pasta wp-content/ (temas, plugins, uploads)
• O ficheiro wp-config.php com as credenciais de base de dados
• Um dump SQL completo da base de dados (todas as tabelas)
• Idealmente, os ficheiros de configuração do servidor (.htaccess, configuração Nginx)

Plugins como UpdraftPlus ou BackWPup fazem backups de tudo o que está acima. A questão é onde guardam e se alguém verifica regularmente.

Onde guardar backups: a regra 3-2-1

A regra 3-2-1 é o standard da indústria para backups fiáveis:

• 3 cópias dos dados
• 2 suportes diferentes (ex: disco local + cloud)
• 1 cópia offsite (fora do mesmo servidor/datacenter)

Para WordPress: backup local no servidor + cópia automática para Google Drive, Dropbox S3, ou Backblaze B2. Se o servidor falhar ou for comprometido, os backups no mesmo servidor estão inacessíveis.

Como testar um restauro correctamente

Testar um backup significa restaurá-lo numa cópia do site e verificar que funciona. O processo:

• Criar um ambiente de staging separado (subdomínio ou instalação local)
• Restaurar o backup mais recente nesse ambiente
• Verificar: o site carrega, o painel admin funciona, os formulários enviam, os menus estão correctos
• Verificar: imagens carregam, produtos do WooCommerce aparecem, posts recentes estão presentes
• Documentar data e resultado do teste

Frequência recomendada: teste de restauro mensal. Para e-commerce ou sites com actualizações diárias, quinzenal.

Frequência de backup por tipo de site

Nem todos os sites precisam do mesmo ritmo de backup:

• Site institucional estático — backup semanal suficiente, testar mensalmente
• Blog activo ou portfolio — backup diário, testar mensalmente
• Loja WooCommerce — backup diário (ou antes de cada actualização), teste quinzenal
• Site com formulários ou submissões — backup diário, testar mensalmente

O erro mais comum: backups no mesmo servidor

Muitos planos de hosting incluem "backups automáticos" que ficam guardados no mesmo servidor. Se o servidor for comprometido por malware, se o disco falhar, ou se a conta for suspensa por não-pagamento, esses backups ficam inacessíveis exactamente quando mais precisam deles. A cópia offsite é obrigatória, não opcional.

Automatizar a verificação de backups

A verificação manual é propensa a ser esquecida. Alternativas para automatizar:

• Scripts que verificam a existência e tamanho do ficheiro de backup e enviam alerta se faltar ou for demasiado pequeno
• Serviços como ManageWP ou MainWP que fazem gestão centralizada de backups de múltiplos sites
• Parceiros de manutenção que incluem drills de restauro mensais no contrato