Você gerencia oito, dez, vinte sites de clientes. Um deles é atualizado, algo dá errado e o site sai do ar. Você abre o painel do plugin de backup, procura a última cópia e descobre que ela está no próprio servidor — que acabou de ser comprometido. É nesse momento que a escolha do backup em nuvem WordPress deixa de ser detalhe técnico e vira risco contratual.
Este guia compara os três plugins mais usados por agências — UpdraftPlus, BackupBuddy e Jetpack — em três critérios que decidem na prática: armazenamento externo, restauração em massa e custo por site. No fim, um fluxo de teste que você roda antes de indicar qualquer um deles ao cliente.
O que separa um backup em nuvem WordPress de um backup comum
Backup local é cópia no mesmo servidor. Se o servidor cai, a cópia cai junto. Backup em nuvem WordPress significa que o arquivo sai da máquina e vai para um destino externo: Google Drive, Dropbox, Amazon S3, Backblaze B2, Storj ou o armazenamento do próprio fornecedor.
Por isso, o primeiro filtro ao avaliar um plugin backup nuvem não é a interface. É a lista de destinos externos que ele suporta de fábrica. Um plugin que só envia para o armazenamento do próprio fabricante amarra você ao preço e à política dele. Um que fala com S3, B2 e Drive permite trocar de destino sem trocar de plugin.
O segundo filtro é o que entra na cópia. Arquivos, banco de dados, uploads, plugins, temas — tudo isso precisa estar no pacote. Se faltar qualquer peça, a restauração vira quebra-cabeça. Vale revisar o que precisa estar na cópia para ela servir antes de confiar em qualquer plugin.
Comparativo: UpdraftPlus, BackupBuddy e Jetpack
Os três resolvem o problema básico. A diferença aparece quando você multiplica por dez sites e precisa restaurar um deles às pressas.
| Critério | UpdraftPlus | BackupBuddy | Jetpack |
|---|---|---|---|
| Destinos externos | Drive, Dropbox, S3, B2, OneDrive, Storj e outros | Drive, Dropbox, S3, Stash (próprio) | Servidores da Automattic |
| Restauração | Por componente, no painel | Completa, com migração embutida | Restauração completa, feita pelo suporte em planos pagos |
| Restauração em massa | Via WP-CLI, site a site | Via script próprio, limitado | Não oferece fluxo em massa |
| Custo por site | Versão gratuita funcional; plano pago por pacote de sites | Licença anual por número de sites | Atrelado ao plano Jetpack, por site |
| Curva de aprendizado | Baixa | Média | Muito baixa |
UpdraftPlus costuma ser a escolha padrão de agência porque a versão gratuita já envia para destinos externos e a paga cobre vários sites num pacote só. BackupBuddy compensa quando o trabalho inclui migração frequente, porque restaura e move o site no mesmo fluxo. Jetpack faz sentido para quem já paga o plano e quer uma solução sem configuração.
Armazenamento externo: onde o custo real aparece
O plugin é barato perto do armazenamento. Um site com muitos uploads gera pacotes de vários gigabytes. Se você guarda 30 dias de cópias diárias em dez sites, a conta do S3 ou do B2 cresce rápido.
Por isso, defina retenção antes de escolher o destino. Sete cópias diárias, quatro semanais e três mensais costuma bastar para a maioria dos clientes. Além disso, ative a remoção automática de pacotes antigos no próprio plugin — sem isso, o bucket vira depósito.
Restauração em massa: o teste que separa os plugins
Restaurar um site é fácil. Restaurar cinco depois de uma falha de hospedagem é outra história. Nenhum dos três plugins oferece um botão “restaurar todos”. O caminho realista é WP-CLI, com o comando do próprio plugin, rodando site a site.
Na prática, você automatiza o download do pacote mais recente e a restauração em sequência. Isso exige acesso SSH ao servidor de cada site. Se você só tem o painel da hospedagem, o caminho é abrir cada painel e restaurar manualmente — o que funciona, mas consome horas.
Portanto, antes de fechar com um plugin, pergunte: ele expõe comando de linha? A documentação oficial do WordPress sobre WP-CLI é o ponto de partida para entender o que dá para automatizar.
Fluxo de teste antes de indicar ao cliente
Nunca aprove um plugin backup wordpress nuvem só pela lista de recursos. Rode este teste em um site de homologação:
- Instale o plugin e conecte o destino externo.
- Rode um backup completo e confirme que o arquivo apareceu no destino, não só no servidor.
- Apague um arquivo de upload aleatório e um plugin secundário.
- Restaure só esses dois itens pelo painel e verifique se voltaram.
- Restaure o site inteiro em um ambiente separado e confira se o front-end abre sem erro.
- Meça o tempo total da operação. Se passar de 30 minutos para um site pequeno, o plugin não serve para sua escala.
- Repita o passo 2 usando WP-CLI, se tiver SSH.
Esse teste revela o que a página de vendas esconde: tempo de restauração, tamanho real do pacote e se o destino externo recebe tudo. Se algo falhar, confira os logs de erro do WordPress antes de culpar o plugin.
Quando o plugin de backup não é a resposta
Plugin de backup não substitui backup de servidor. Se a hospedagem oferece snapshot diário, use os dois: o snapshot cobre falha de infraestrutura, o plugin cobre erro humano — alguém apagou uma página, um plugin quebrou o layout.
Além disso, plugin não resolve site já comprometido. Se o WordPress foi invadido, restaurar uma cópia antiga pode trazer o backdoor de volta. Nesse caso, o caminho é confirmar e agir sobre a invasão antes de restaurar qualquer coisa.
Por fim, se o cliente tem dados regulados — saúde, financeiro —, verifique onde o fornecedor hospeda os arquivos. Backup em nuvem fora do país pode esbarrar em exigência de contrato.
Erros comuns ao montar backup em nuvem WordPress para vários sites
- Deixar a cópia só no servidor e chamar isso de backup em nuvem.
- Não testar restauração nenhuma vez.
- Configurar retenção infinita e estourar o custo do armazenamento.
- Usar a mesma conta de destino para todos os clientes, sem separar pastas.
- Esquecer de incluir o banco de dados no agendamento.
- Confiar em backup automático sem monitorar se ele rodou.
O último item é o mais traiçoeiro. Backup que falha em silêncio é pior que backup nenhum, porque cria confiança falsa. Monitore a data do último pacote de cada site. Se um deles está com cópia de duas semanas atrás, algo parou.
Prevenção: transforme backup em rotina, não em emergência
Defina uma rotina fixa. Uma vez por semana, confira a data do último backup de cada site. Uma vez por mês, restaure um site aleatório em ambiente de teste. Uma vez por trimestre, revise custo de armazenamento e retenção.
Esse cuidado se encaixa na rotina de manutenção WordPress que você já deveria ter para cada cliente. Backup não é tarefa separada; é parte do mesmo ciclo de atualização e verificação.
Quando o número de sites passa de cinco, acompanhar isso site a site deixa de ser viável. É aí que um painel como o 100% WP ajuda: ele centraliza backup, atualizações e monitoramento de vários sites num lugar só, e você vê de relance qual site está sem cópia recente.
Quando chamar alguém
Se o site já caiu e você não tem backup íntegro, pare de tentar restaurar por conta própria. Cada tentativa sobrescreve arquivos e reduz a chance de recuperação. Nesse cenário, o caminho é acionar um serviço especializado de backup e recuperação.
O mesmo vale quando o cliente exige SLA de restauração em horas. Nesse caso, a escolha do plugin é só uma parte: você precisa de processo documentado, ambiente de teste e alguém de plantão. Plugin nenhum entrega isso sozinho.
