Loja WooCommerce tem uma vantagem e uma armadilha ao mesmo tempo: como é um plugin rodando em cima do WordPress, muita gente trata o backup dela exatamente igual ao backup de um blog comum — e esquece que ali dentro tem pedido, dado de cliente, histórico de pagamento e configuração de frete que, se sumirem, param a loja de vender literalmente no minuto seguinte.
O Que Precisa Estar no Backup
1. Banco de Dados WordPress/WooCommerce
Pedidos, produtos, variações, cupons e configurações do WooCommerce ficam nas tabelas do banco MySQL do WordPress (algumas em tabelas próprias como wp_wc_orders nas versões mais recentes com HPOS ativado, outras em wp_postmeta nas versões mais antigas). Um dump completo do banco:
mysqldump -u usuario -p nome_do_banco > backup_loja_$(date +%Y%m%d).sql2. Pasta wp-content Inteira
Não basta o banco. A pasta wp-content/uploads guarda todas as imagens de produto, wp-content/plugins tem o próprio WooCommerce e extensões pagas (gateway de pagamento, cálculo de frete, integrações com marketplace), e wp-content/themes tem o tema customizado da loja. Perder plugins pagos sem a licença anotada em outro lugar significa ter que comprar de novo ou contatar o suporte do desenvolvedor para reemitir acesso — processo que pode levar dias.
Um Detalhe Que Só Quem Já Migrou Loja Sabe
Depois de restaurar banco e arquivos num ambiente novo (outro domínio, por exemplo, num teste ou staging), o WooCommerce guarda URLs absolutas espalhadas pelo banco — em imagens, em links internos, às vezes até em configurações de checkout. Se você só trocar o domínio no wp-config.php sem rodar um “search and replace” no banco (com uma ferramenta como o WP-CLI: wp search-replace 'lojaantiga.com.br' 'lojanova.com.br'), a loja carrega com imagem quebrada e link apontando pro site errado, mesmo com tudo tecnicamente restaurado.
Automatizando com Plugin vs. Automatizando por Fora
Plugins de backup dentro do próprio WordPress (UpdraftPlus, por exemplo) são mais simples de configurar e enviam automaticamente para Google Drive, Dropbox ou S3. A desvantagem é que, se o site for comprometido a ponto de o WordPress parar de responder, o plugin de backup também para de funcionar. Um backup via cron direto no servidor, fora do WordPress, continua rodando mesmo que o site esteja fora do ar — por isso vale ter as duas camadas, não escolher uma só.
Testando a Restauração Antes de Precisar de Verdade
Backup que nunca foi restaurado em ambiente de teste é uma aposta. Pelo menos uma vez por mês, monte um ambiente separado (um subdomínio de staging, ou até um ambiente local com XAMPP ou Local by Flywheel) e restaure o backup mais recente ali. Isso revela problemas antes que eles apareçam num momento de crise real — como um dump que estava sendo gerado incompleto por causa de um limite de memória do MySQL, ou uma pasta de uploads que parou de ser incluída no script depois de uma mudança de caminho no servidor que ninguém percebeu.
Checklist Rápido para Loja WooCommerce
- Banco de dados com backup diário, armazenado fora do servidor de produção.
- Pasta
wp-contentcompleta (uploads, plugins, themes) com backup pelo menos semanal. - Licenças de plugins pagos documentadas separadamente, não só dentro do backup do site.
- Backup enviado para um destino externo (nuvem ou outro servidor), nunca só localmente.
- Teste de restauração real, em ambiente separado, com frequência mensal.
Problemas Comuns
1. Backup gigante porque a pasta uploads está cheia de imagens não otimizadas — loja com anos de operação acumula imagem em resolução desnecessariamente alta. Otimizar imagens (com plugin de compressão) antes de rodar o próximo backup reduz tempo e espaço de armazenamento sem perder qualidade visível.
2. Pedidos “sumidos” depois de restaurar backup antigo — se o backup é de alguns dias atrás e a loja continuou vendendo até o problema acontecer, os pedidos feitos depois do backup não existem na cópia restaurada. Isso reforça por que backup diário (ou até de hora em hora, em loja de alto volume) é mais importante em e-commerce do que em site institucional comum.
3. Conflito de plugin depois de restaurar em servidor com versão de PHP diferente — WooCommerce e extensões têm requisitos mínimos de versão de PHP que mudam com o tempo. Ao restaurar num servidor novo, confira se a versão de PHP é compatível antes de assumir que “só restaurar” resolve tudo.
Perguntas Frequentes
Com que frequência devo fazer backup de uma loja WooCommerce ativa?
Banco de dados diariamente é o mínimo aceitável para qualquer loja com pedido recorrente; lojas de alto volume se beneficiam de backup incremental de banco a cada poucas horas. Arquivos (imagens, plugins) semanalmente costuma bastar, exceto antes de atualizações.
Uso outra plataforma de e-commerce — a lógica muda muito?
Os princípios são os mesmos, banco e arquivos juntos, testados regularmente — mas a estrutura de pastas muda. Já cobrimos isso especificamente para lojas PrestaShop e Tray Commerce, com particularidades de cada plataforma.
Vale aprofundar em backup de MySQL puro, além do WooCommerce?
Sim, principalmente para quem administra mais de um site com banco de dados por trás — os comandos de dump e restauração são os mesmos independente da aplicação. Temos um guia completo de backup MySQL com mais detalhe técnico.
Plugin de backup gratuito é suficiente para uma loja pequena?
Para lojas com poucos pedidos por dia, sim, desde que configurado para enviar a cópia para um destino externo (nunca só no mesmo servidor) e testado periodicamente. À medida que o volume de vendas cresce, vale migrar para uma solução mais robusta com backup incremental.
