Como automatizar com segurança as cópias de segurança do WordPress
Publicado em 7 de novembro de 2026
Uma cópia de segurança do WordPress só é útil se incluir os dados certos e puder ser restaurada antes que a empresa sinta os efeitos da interrupção. Para automatizar com segurança as cópias de segurança do WordPress, agende cópias dos ficheiros e exportações da base de dados, envie cópias para fora do servidor de produção e confirme que a restauração funciona de facto. Uma tarefa de cópia de segurança que indica sucesso, mas guarda um arquivo vazio, não oferece proteção. É apenas um problema muito educado à espera de sexta-feira à noite.
O que inclui uma cópia de segurança completa do WordPress
O WordPress não é uma coisa só. O conteúdo do site, a configuração, os plugins, os temas, os ficheiros multimédia enviados e os dados dos utilizadores estão distribuídos pelo sistema de ficheiros e pela base de dados. Uma recuperação completa precisa de ambos.
A base de dados contém artigos, páginas, encomendas do WooCommerce, contas de clientes, entradas de formulários, definições e outros conteúdos que mudam. O sistema de ficheiros contém os ficheiros principais do WordPress, plugins, temas, ficheiros enviados e ficheiros como `wp-config.php`. Se restaurar apenas os ficheiros, o site poderá carregar com conteúdo antigo ou em falta. Se restaurar apenas a base de dados, esta poderá apontar para ficheiros inexistentes.
Para muitos sites empresariais, o mínimo prático é uma cópia de segurança diária da base de dados e uma cópia diária do site completo. As lojas de comércio eletrónico, as plataformas de adesão, os sistemas de reservas e os ambientes de páginas de destino SaaS com muito tráfego poderão precisar de cópias mais frequentes da base de dados, porque podem surgir novas encomendas e dados de clientes a cada hora. A frequência deve refletir a quantidade de dados que pode realmente perder, não aquilo que parece conveniente.
Escolha a camada de automação certa
Há três formas comuns de automatizar as cópias de segurança do WordPress: um plugin de cópias de segurança do WordPress, o painel de controlo ou o serviço gerido do alojamento e tarefas ao nível do servidor. Nenhuma é universalmente a melhor. A escolha certa depende de quem gere o servidor, do tamanho do site e da rapidez com que precisa de recuperar.
Cópias de segurança através de plugins
Um plugin costuma ser a opção mais simples para um site pequeno. Pode criar arquivos, agendar tarefas e enviar cópias para armazenamento remoto sem acesso à shell. Isto dá aos proprietários do site visibilidade direta e é útil quando o plano de alojamento não inclui um serviço de cópias de segurança.
A contrapartida é a carga no servidor. Comprimir uma grande biblioteca multimédia enquanto o site recebe visitantes pode consumir CPU, memória, E/S do disco e processos de trabalho do PHP. Num ambiente partilhado com muito tráfego ou num VPS pequeno, as tarefas de cópia de segurança podem exceder o tempo limite ou tornar mais lentas as páginas de finalização da compra. Sempre que possível, configure a tarefa para as horas de menor tráfego e acompanhe as primeiras execuções, em vez de presumir que o agendamento está correto.
Cópias de segurança do alojamento ou geridas
As cópias de segurança ao nível do alojamento são executadas fora do WordPress, o que, em geral, é mais seguro durante uma falha de um plugin, um incidente de malware ou uma atualização do WordPress que correu mal. Um sistema de cópias de segurança gerido pode guardar bases de dados e ficheiros sem depender de a aplicação do site continuar a funcionar corretamente.
Esta abordagem reduz o número de componentes móveis no WordPress e, normalmente, facilita a restauração ao nível da infraestrutura. Para as empresas que não querem gerir os próprios plugins de cópias de segurança, agendamentos, credenciais de armazenamento e regras de alerta, as cópias de segurança geridas pelo alojamento são uma opção mais tranquila. Na kodu.cloud, este tipo de trabalho operacional pode ser tratado em conjunto com a monitorização do servidor e o suporte, em vez de ficar reduzido a um lembrete mensal de que ninguém gosta.
Cópias de segurança ao nível do servidor
Um VPS ou servidor dedicado oferece-lhe mais controlo. Pode usar tarefas agendadas para exportar bases de dados, arquivar ficheiros da aplicação, encriptar o resultado e transferi-lo para um destino de armazenamento independente. Os programadores e as agências costumam preferir esta opção porque os agendamentos, a retenção, as exclusões e os registos podem ser adaptados a cada site.
Mais controlo também significa mais responsabilidade. O script de cópia de segurança precisa de tratamento de erros, espaço em disco disponível, permissões, monitorização do armazenamento e documentação de restauração. É suficientemente comum que um comando agendado falhe silenciosamente durante três semanas para merecer atenção.
Crie um agendamento de cópias de segurança adequado às necessidades de recuperação
Comece com duas perguntas: quantos dados recentes a empresa pode perder e durante quanto tempo o site pode ficar indisponível? Estes são o objetivo de ponto de recuperação e o objetivo de tempo de recuperação. Não precisa de usar as siglas numa reunião, mas deve saber as respostas.
Um site institucional que muda duas vezes por mês poderá estar suficientemente protegido com cópias de segurança diárias e uma retenção de 14 a 30 dias. Um site de agência com muito conteúdo pode beneficiar de cópias de segurança completas diárias, além de uma cópia antes de grandes atualizações. Uma loja WooCommerce exige mais atenção: as cópias diárias dos ficheiros não são suficientes se as encomendas forem registadas ao longo de todo o dia.
Para uma loja ativa, considere cópias da base de dados de hora a hora ou a cada poucas horas, cópias diárias do sistema de ficheiros e uma cópia antes de atualizar o WooCommerce, os plugins de pagamento, os temas ou o núcleo do WordPress. Evite manter apenas uma geração de cópias de segurança. Se a corrupção, o spam ou o malware tiver entrado no site há vários dias, a cópia de ontem poderá conter o mesmo problema.
A retenção tem custos. Mais pontos de restauração exigem mais armazenamento, capacidade de transferência e manutenção. Uma política sensata costuma manter várias cópias diárias recentes, algumas cópias semanais e um pequeno número de cópias mensais. Os números exatos dependem do site e dos requisitos de conformidade, mas o princípio mantém-se: conserve histórico suficiente para recuperar de um problema detetado tardiamente.
Mantenha pelo menos uma cópia fora do servidor de produção
Não trate uma cópia de segurança guardada junto ao site como um plano de recuperação de desastres. Se o disco do servidor falhar, uma conta for eliminada, um ransomware atingir o armazenamento montado ou um comando de limpeza executado por engano for usado com demasiada confiança, os dados de produção e a cópia de segurança poderão desaparecer juntos.
Use armazenamento separado para as cópias de segurança, com credenciais independentes e, de preferência, num domínio de falha diferente. Pode ser armazenamento de objetos, um servidor de cópias de segurança ou outro fornecedor. Encripte os arquivos antes da transferência se contiverem registos de clientes, dados de contas ou ficheiros privados enviados. Guarde as chaves de encriptação e as credenciais de armazenamento separadamente da raiz da Web e do repositório.
O conhecido princípio 3-2-1 continua a ser útil: mantenha três cópias dos dados importantes, em dois tipos de armazenamento, com uma cópia fora do local. Não precisa de transformar isto numa cerimónia. É simplesmente uma forma de evitar que um incidente grave resulte numa perda total.
Exclua o que não precisa de ser incluído nas cópias de segurança
Caches grandes, ficheiros temporários, registos de depuração, artefactos de implementação e caches de imagens geradas podem tornar as cópias de segurança lentas e dispendiosas sem melhorar a recuperação. Normalmente, é sensato excluir estes ficheiros, desde que possam ser recriados em segurança.
Tenha cuidado com os ficheiros enviados. O diretório `wp-content/uploads` costuma conter imagens de produtos, documentos, submissões de utilizadores e ficheiros da biblioteca multimédia. Normalmente, deve permanecer incluído na cópia de segurança. Também é preciso rever os diretórios de aplicações personalizados, o armazenamento não padrão de plugins e os ficheiros fora da raiz do WordPress. Um programador poderá ter colocado recursos essenciais num local inesperado. Infelizmente, o servidor não adivinha.
Antes de finalizar as exclusões, compare o conteúdo do arquivo com o que a aplicação precisa após uma restauração limpa. Uma cópia de segurança mais pequena só é boa se ainda permitir restaurar a empresa.
Torne visíveis as falhas das cópias de segurança
Sem relatórios, a automatização é apenas parcial. Configure alertas para tarefas falhadas, transferências incompletas, armazenamento insuficiente, arquivos invulgarmente pequenos e cópias de segurança cuja antiguidade exceda a política definida. O e-mail é aceitável num ambiente pequeno, mas um canal de alertas monitorizado é melhor para equipas responsáveis por vários sites de clientes.
Verifique os registos após a configuração e depois de alterações significativas ao PHP, ao WordPress, às versões da base de dados, às credenciais de armazenamento ou às permissões do sistema de ficheiros. Uma cópia de segurança bem-sucedida deve ter uma data e hora claras, um intervalo de tamanho esperado, confirmação do destino e um resultado de retenção.
Monitorize também o espaço em disco disponível no servidor de origem. Algumas ferramentas criam o arquivo completo localmente antes de o carregar. Um servidor com o disco quase cheio pode falhar durante a cópia de segurança e causar problemas de desempenho ao mesmo tempo. Não é a situação de disco mais agradável, mas pode ser evitada.
Teste as restaurações antes de uma emergência
Um teste de restauração é o momento em que as afirmações sobre cópias de segurança se tornam factos operacionais. Pelo menos uma vez por trimestre, restaure uma cópia recente num ambiente de preparação ou numa localização temporária separada. Confirme que o WordPress inicia, que a base de dados estabelece ligação, que os ficheiros multimédia são carregados, que os utilizadores conseguem iniciar sessão e que as principais funções empresariais funcionam.
Numa loja online, teste as páginas de produtos, o comportamento do carrinho, as definições relacionadas com a finalização da compra, os registos de encomendas, a configuração do e-mail transacional e as dependências dos plugins de pagamento. Não coloque uma cópia restaurada num local de onde possa enviar e-mails reais a clientes ou aceitar pagamentos em tempo real. Desative primeiro o envio de e-mails e as ações de pagamento no ambiente de teste.
Documente os passos de restauração enquanto os executa. Registe onde a cópia de segurança está armazenada, que base de dados deve ser importada, onde os valores de configuração são alterados e como são tratados o DNS ou os URLs da aplicação. Durante uma interrupção real, um procedimento de execução breve e atualizado poupa mais tempo do que a memória de qualquer pessoa.
Proteja o próprio processo de cópia de segurança
Use credenciais de armazenamento dedicadas, com apenas as permissões necessárias para ler e gravar dados das cópias de segurança. Ative a autenticação multifator na conta de armazenamento e no painel de controlo do alojamento. Mantenha o WordPress, os plugins, os pacotes do servidor e as ferramentas de cópia de segurança atualizados, porque um site comprometido também pode tentar aceder às credenciais de cópia de segurança disponíveis.
Se as cópias de segurança estiverem encriptadas, teste a desencriptação durante os exercícios de restauração. Um arquivo encriptado sem a chave correta é perfeitamente seguro e perfeitamente inútil. Guarde as instruções de recuperação num local protegido que continue disponível caso o servidor de produção não esteja.
As cópias de segurança automatizadas devem reduzir a sua carga de trabalho, não ocultar riscos por trás de um indicador verde de estado. Defina o agendamento, mantenha cópias fora do local, monitorize as tarefas e ensaie a restauração enquanto o serviço está novamente tranquilo. Assim, poderá fazer alterações ao WordPress com muito mais segurança.
Andres Saar, Engenheiro de Suporte ao Cliente