Uma atualização de módulo que quebra o checkout no meio de uma promoção, um ataque que corrompe o banco de dados, ou simplesmente alguém rodando um comando errado direto no banco em produção — qualquer um desses cenários pode deixar uma loja Magento fora do ar por horas. A diferença entre “voltar a vender em 20 minutos” e “perder um dia inteiro de faturamento” quase sempre é ter (ou não ter) um backup recente e testado.
Trabalhei em situações onde a loja ficou fora do ar depois de uma atualização malsucedida, e o tempo de recuperação dependeu inteiramente de quão recente e completo era o último backup. Vou mostrar aqui como montar isso direito, sem depender só do painel administrativo do Magento (que, sozinho, não é suficiente pra loja em produção).
O que compõe um backup completo do Magento
Um backup de loja Magento precisa cobrir três partes, e esquecer uma delas é o erro mais comum que existe:
- Banco de dados — produtos, pedidos, clientes, configurações. É a parte mais crítica e a que muda com mais frequência.
- Sistema de arquivos — código customizado, temas, módulos e arquivos de configuração (app/etc/env.php é essencial e muita gente esquece dele).
- Mídia — imagens de produto e arquivos de download. Costuma ser a parte mais pesada em espaço, mas sem ela o catálogo fica com produto sem foto.
Passo a passo para configurar o backup
- Backup do banco de dados via mysqldump. O método mais confiável em produção é rodar via linha de comando:
mysqldump -u [usuario] -p [nome_do_banco] | gzip > backup_$(date +%Y%m%d).sql.gz. Isso evita travar a loja durante o processo, diferente do backup pelo painel administrativo (Sistema > Ferramentas > Backups), que coloca a loja em modo manutenção enquanto roda — inviável em loja com tráfego constante. - Backup dos arquivos de código e configuração. Compacte a pasta do projeto excluindo cache e logs pra não pesar à toa:
tar --exclude='var/cache' --exclude='var/log' --exclude='pub/media' -czf codigo_backup.tar.gz /caminho/da/loja. - Backup da pasta de mídia separado. Como costuma ser grande, vale ter uma rotina própria pra ela, com frequência menor que o banco (banco muda toda hora, mídia muda bem menos).
- Envie tudo pra um local fora do servidor de produção. Backup que fica no mesmo servidor da loja não protege contra falha de disco, invasão ou o servidor inteiro cair. Storage externo tipo S3 ou um servidor de backup dedicado resolve isso.
- Automatize com cron. Banco de dados: pelo menos uma vez por dia, de preferência em horário de menor movimento (madrugada). Mídia e código: pode ser semanal, já que mudam menos.
Testando a restauração
Um backup nunca testado é uma aposta. Pelo menos uma vez por trimestre, restaure o backup mais recente num ambiente de staging (nunca em produção) e confira se a loja sobe normalmente, se os produtos aparecem com imagem e se um pedido de teste consegue ser finalizado. O comando magento setup:rollback ajuda a reverter uma instalação usando os backups gerados pelo próprio Magento, mas pra restaurações vindas de mysqldump o processo é reimportar o dump direto no banco de destino.
Problemas comuns
1. Backup rodando durante horário de pico e travando a loja. Se o mysqldump for feito sem cuidado numa loja grande, pode segurar tabelas por tempo suficiente pra afetar checkout em andamento. A solução é agendar em horário de menor tráfego e, em lojas muito grandes, considerar Percona XtraBackup, que faz backup binário sem travar as tabelas.
2. Disco cheio porque ninguém limpa backups antigos. É comum o job de backup rodar certinho por meses até o disco de destino encher silenciosamente, e o backup passar a falhar sem ninguém perceber. Configure rotação automática (manter por exemplo os últimos 30 dias) e um alerta de espaço em disco.
3. Restauração incompleta porque a pasta de mídia não foi incluída. A loja volta ao ar, os pedidos e produtos estão lá, mas as imagens somem. Isso acontece quando o backup de mídia foi esquecido ou ficou desatualizado em relação ao banco — por isso vale sincronizar a frequência dos dois o máximo possível.
Perguntas frequentes
Com que frequência devo fazer backup do banco de dados do Magento?
Pelo menos uma vez por dia para lojas em produção ativa. Lojas com alto volume de pedidos podem se beneficiar de backups incrementais mais frequentes, a cada poucas horas.
O backup pelo painel administrativo do Magento é suficiente?
Para ambiente de desenvolvimento ou loja com pouquíssimo tráfego, pode servir. Para produção, não — ele coloca a loja em manutenção durante o processo, o que é inviável com clientes navegando ou comprando.
Onde devo guardar os arquivos de backup?
Fora do servidor de produção, sempre. Um serviço de armazenamento em nuvem (como Amazon S3) ou um servidor de backup dedicado, com acesso restrito, é o padrão recomendado.
Se sua empresa também opera lojas em outras plataformas, os processos de backup do PrestaShop e backup do Tray Commerce seguem uma lógica bem parecida com a apresentada aqui.
Segurança dos arquivos de backup
Um detalhe que passa batido com frequência: o próprio arquivo de backup vira um alvo, porque ele contém tudo — inclusive dados de clientes e credenciais de configuração armazenadas no env.php. Guardar backup sem criptografia num bucket público, ou com permissão de leitura liberada demais, é basicamente entregar o banco de dados inteiro da loja pra quem encontrar o link. Vale criptografar o arquivo antes de subir (um simples gpg já resolve) e restringir o acesso ao storage de backup só para quem realmente precisa, com autenticação própria — nunca reaproveitando a mesma credencial usada no servidor de produção.
