Loja PrestaShop tem uma particularidade que pega muita gente desprevenida na hora do backup: os dados do catálogo, pedidos e clientes ficam no banco MySQL, mas as imagens de produto, arquivos de tema customizado e módulos instalados ficam soltos no sistema de arquivos. Backup que só exporta o banco de dados parece completo até o dia em que você precisa restaurar e descobre que todas as fotos dos produtos sumiram.
As Duas Partes Que Precisam Ser Salvas Juntas
1. Banco de Dados MySQL
É onde ficam pedidos, clientes, estoque, preços e configurações. Pelo painel do PrestaShop, vá em Parâmetros Avançados > Backup de BD e gere um dump — o PrestaShop já compacta automaticamente. Para lojas maiores, isso via painel pode travar por timeout do PHP, e nesse caso vale rodar direto via linha de comando no servidor:
mysqldump -u usuario -p nome_do_banco > backup_$(date +%Y%m%d).sql2. Arquivos: /img, /modules, /themes, .env ou parameters.php
Aqui é onde a maioria erra. As imagens dos produtos ficam em /img/p/ e /img/c/, os módulos comprados e customizados em /modules, temas personalizados em /themes, e as credenciais de conexão com o banco em app/config/parameters.php (PrestaShop 1.6/1.7) ou .env (PrestaShop 8+). Perder esse último arquivo não é o fim do mundo — dá para recriar — mas perder as imagens de produto sem backup significa refotografar ou baixar tudo de novo do fornecedor, o que em catálogo com milhares de SKUs é um pesadelo de dias.
Automatizando: Não Dependa de Lembrar de Fazer Manualmente
Um script simples de cron no servidor resolve os dois lados:
#!/bin/bash
DATA=$(date +%Y%m%d_%H%M)
mysqldump -u usuario -p'senha' banco_prestashop | gzip > /backups/db_$DATA.sql.gz
tar -czf /backups/arquivos_$DATA.tar.gz /var/www/loja/img /var/www/loja/modules /var/www/loja/themesAgende no crontab para rodar de madrugada, fora do horário de pico de vendas — um dump de banco grande pode deixar a loja lenta por alguns minutos enquanto roda, e ninguém quer isso acontecendo durante uma campanha de tráfego pago no meio da tarde.
Onde Guardar: Nunca Só no Mesmo Servidor
Backup salvo na mesma máquina que hospeda a loja não protege contra praticamente nada — se o servidor for comprometido, corromper ou simplesmente sofrer uma falha de disco, o backup vai junto. Envie a cópia para um storage externo (S3, Backblaze, ou até um servidor de backup separado via rsync) logo depois de gerar, dentro do mesmo script:
rsync -avz /backups/ usuario@servidor-backup:/destino/Problemas Comuns
1. Backup via painel trava em loja com catálogo grande — o limite de tempo de execução do PHP (max_execution_time) interrompe o processo antes de terminar. A solução real é migrar para backup via linha de comando/cron, que não sofre essa limitação, em vez de tentar aumentar o timeout indefinidamente no painel de hospedagem.
2. Restaurei o banco mas a loja não abre, dá erro de conexão — normalmente é porque o arquivo parameters.php ou .env restaurado aponta para um host, usuário ou nome de banco diferente do ambiente novo. Confira essas credenciais manualmente após restaurar em um servidor diferente do original.
3. Imagens de produto quebradas depois de mover para outro servidor — além dos arquivos físicos em /img, o PrestaShop grava caminhos e IDs de imagem no próprio banco. Restaurar só as imagens sem o dump do banco correspondente (ou vice-versa) quase sempre gera esse tipo de inconsistência — por isso backup de banco e de arquivos precisam ser feitos juntos, no mesmo momento, nunca em horários separados.
Criptografia e LGPD: Um Detalhe Que Muita Loja Ignora
O dump do banco de uma loja PrestaShop carrega dados pessoais de clientes — nome, CPF, endereço, telefone, histórico de compras. Isso enquadra o backup diretamente nas obrigações da LGPD sobre proteção de dados pessoais, o que na prática significa que aquele arquivo .sql.gz sentado num storage não pode ficar acessível publicamente nem sem controle de acesso. Duas práticas resolvem a maior parte do risco: criptografar o backup antes de subir para a nuvem (um simples gpg --encrypt no arquivo antes do rsync já ajuda bastante) e restringir o acesso ao bucket ou pasta de backup só para quem realmente precisa, com autenticação própria — não a mesma senha de FTP que todo mundo da equipe usa.
Frequência Recomendada
Banco de dados: diário, no mínimo, para lojas com movimento — pedido perdido é pedido que não vai ser refeito pelo cliente. Arquivos (imagens, módulos, temas): semanal costuma bastar, já que mudam com menos frequência, mas sempre antes de qualquer atualização de módulo ou tema, quando o risco de algo quebrar é maior.
Perguntas Frequentes
PrestaShop tem módulo de backup automático nativo confiável?
O backup nativo (Parâmetros Avançados) funciona bem para lojas pequenas, mas para catálogos grandes ou lojas com muito tráfego, um script via cron direto no servidor costuma ser mais estável e menos propenso a timeout.
Uso outra plataforma de e-commerce, a lógica muda muito?
Os princípios são os mesmos — banco de dados e arquivos precisam ser salvos juntos e testados — mas os caminhos de arquivo mudam. Vale ver como isso se aplica em lojas WooCommerce ou Tray Commerce, que têm estrutura de arquivos parecida mas não idêntica.
Vale a pena aprender mais sobre backup de MySQL especificamente?
Sim, principalmente se você administra mais de um sistema que depende de MySQL por trás — as técnicas de dump, compressão e restauração são as mesmas independente da aplicação por cima. Temos um guia completo de backup MySQL que aprofunda esses comandos.
Com que frequência devo testar a restauração?
Pelo menos uma vez por mês, restaurando num ambiente de teste separado (nunca direto na loja em produção). É a única forma de saber com certeza que o backup gerado realmente funciona quando for preciso de verdade.
