A maioria dos comerciantes online pensa que está protegida por cópias de segurança. A maioria não está de verdade. Nas auditorias que fazemos, 6 lojas PrestaShop em 10 não têm uma cópia restaurável em menos de 4 horas, 3 em 10 têm cópias corrompidas ou incompletas, e cerca de 1 em 10 não tem qualquer cópia utilizável há mais de um mês, muitas vezes sem o saber.
O custo de um incidente sem cópia funcional situa-se entre 24 h e várias semanas de paragem, dados de clientes perdidos e, por vezes, a cessação de atividade. Este artigo descreve a estratégia de cópias de segurança que uma loja PrestaShop devia ter em 2026: a regra 3-2-1, a cifragem, a rotação e, sobretudo, o restauro testado.
Porque é que as cópias por omissão não chegam
«O meu alojamento faz cópias de segurança» é a frase que mais se ouve. É verdade em geral, e insuficiente na prática:
- As cópias do alojamento estão no mesmo centro de dados. Um incêndio grave (OVH Estrasburgo, 2021), um ataque de ransomware ou um comprometimento do painel de administração do alojamento, e as cópias ardem com os dados.
- A retenção é curta. 7 a 14 dias nas ofertas normais. Se descobrir uma desfiguração ou uma corrupção 3 semanas depois, a cópia infetada já substituiu a cópia sã.
- A cópia inclui mesmo tudo? Muitos alojamentos copiam a base mas não os ficheiros, ou o inverso. E os uploads (imagens de produto, faturas PDF, exportações) ficam por vezes esquecidos.
- O restauro nunca é testado. No dia do problema, descobre-se que o procedimento de restauro não funciona, ou demora 36 horas, ou exige acesso a um painel que já se perdeu.
- Sem cifragem. Uma cópia não cifrada alojada num terceiro é toda a base de clientes exposta em caso de fuga no prestador.
A regra 3-2-1: a referência da indústria há 30 anos
Formulada pelo fotógrafo Peter Krogh em 2005 para as cópias digitais, e adotada pelo CNCS em Portugal, pela CISA americana e pela quase totalidade dos quadros de segurança informática:
3 cópias dos dados, em 2 suportes diferentes, das quais 1 fora do local.
Em concreto, para uma loja PrestaShop:
- Cópia 1: a produção (o servidor de produção).
- Cópia 2: cópia local ou no mesmo alojamento (rápida de restaurar nos incidentes menores).
- Cópia 3: cópia fora do local, num fornecedor de armazenamento terceiro (S3, Backblaze B2, Wasabi, Dropbox).
A cópia fora do local é a última linha de defesa contra os sinistros graves (incêndio, ransomware, falência do alojamento).
O que é preciso copiar numa loja PrestaShop
1. A base de dados completa
Todas as tabelas, não só as tabelas de negócio. Um dump mysqldump com as opções --single-transaction --quick --routines --triggers, pela coerência e pela inclusão dos procedimentos armazenados e dos triggers.
2. Os ficheiros carregados
A pasta /img/ (imagens de produtos, categorias, fabricantes), /upload/ (ficheiros anexados aos produtos), /download/ (produtos virtuais e respetivos entregáveis), e todos os diretórios de módulos de terceiros que guardem ficheiros (faturas PDF, exportações contabilísticas, registos).
3. O código e os módulos
Mesmo com Git, copiar o código em produção permite captar as correções urgentes não versionadas e o estado exato dos módulos instalados. Inclui /modules/, /themes/, /override/ e a raiz do PrestaShop, excluindo /var/cache/.
4. A configuração do sistema
Ficheiros app/config/parameters.php, .htaccess, configurações do Nginx ou do Apache, certificados SSL, crontabs. Muitas vezes esquecidos, são críticos para refazer uma instalação do zero.
5. Os e-mails enviados e os registos recentes
Pelas obrigações legais (RGPD, contabilidade), conservar uma cópia dos registos recentes e dos e-mails transacionais. Não é sistemático, mas é útil.
A cifragem já não é opcional
Uma cópia não cifrada guardada num fornecedor terceiro é um risco RGPD grave: se o prestador for comprometido, toda a base de clientes sai em claro. Artigo 32.º do RGPD: obrigação de aplicar «medidas técnicas adequadas», o que inclui a cifragem em repouso das cópias com dados pessoais.
O padrão em 2026: AES-256 com uma chave guardada separadamente das cópias. Nunca guardar a chave de cifragem junto das cópias, senão a cifragem não serve para nada.
A rotação: quantas versões conservar
Quanto mais se conserva, melhor, mas custa. Estratégia GFS (Grandfather-Father-Son) comprovada:
- Cópias diárias conservadas 7 dias.
- Cópias semanais conservadas 4 semanas.
- Cópias mensais conservadas 12 meses.
- Cópias anuais conservadas 10 anos, o prazo de conservação contabilística e fiscal em Portugal.
Com esta estratégia, pode restaurar a qualquer dia dos últimos 7, a qualquer semana do último mês, a qualquer mês do último ano. Cobre 99 % dos cenários de recuperação.
O restauro testado: a única cópia que conta
Uma cópia não testada é uma superstição, não uma cópia de segurança. A regra absoluta:
Teste o restauro num ambiente de staging pelo menos uma vez por trimestre.
Esse teste deve verificar:
- A cópia está completa (todas as tabelas, todos os ficheiros)?
- O dump restaura-se sem erros?
- O site funciona depois do restauro (páginas de categoria, carrinho, checkout, back-office)?
- Quanto tempo demora o restauro completo (RTO: Recovery Time Objective)?
- Qual é a perda máxima de dados (RPO: Recovery Point Objective)?
Nas lojas que fazem este teste trimestral, o tempo de restauro cai de 6 a 8 horas para 1 a 2 horas em poucas iterações. E as falhas (tabela em falta, permissão errada, ficheiro corrompido) são detetadas antes do incidente, não durante.
O nosso módulo dfbackup: cópia de segurança pronta a usar
Implementar esta estratégia à mão exige manter um script de dump, um sistema de cifragem, uma rotação e um envio para armazenamento S3. O nosso módulo dfbackup para PrestaShop 8 e 9 empacota toda a stack:
- Cópia agendada de base de dados e ficheiros por cron, com intervalo configurável (diário, semanal).
- Cifragem AES-256 com chave separada, armazenável fora do servidor.
- Destinos múltiplos: S3 (e compatíveis: Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- Rotação GFS automatizada: conservação parametrizável por nível.
- Restauro num clique a partir do back-office, com staging opcional.
- Notificações por e-mail ou webhook em caso de falha ou de sucesso.
- Registos detalhados de cada cópia (volume, duração, hash de verificação).
- Compatível com multiloja, multilingue, e com retenção diferenciada por perímetro.
Por 129 €, instala uma estratégia de cópias de segurança conforme ao RGPD e industrializada, sem depender do alojamento.
Quanto custa não ter cópias de segurança
Numa loja que fatura 100 mil euros por mês, uma paragem de 48 h custa diretamente 6700 € de vendas não realizadas. Acrescente os custos indiretos: reconquista dos clientes perdidos, avaliações negativas no apoio ao cliente, impacto no SEO se a paragem se prolongar (a Google pode desindexar se o site ficar em 404 mais do que alguns dias), perda de confiança dos parceiros. Total realista: 15 a 30 mil euros por uma paragem de 48 h. Num mês de paragem, fala-se da viabilidade da empresa.
O custo de uma estratégia de cópias robusta: 130 € de módulo mais 5 a 20 € por mês de armazenamento S3. A relação custo/risco não admite discussão.
FAQ
As cópias incrementais chegam?
Sozinhas, não. Uma cópia incremental depende da cópia completa anterior. Se a cópia completa estiver corrompida, toda a cadeia incremental fica inutilizável. A regra: uma cópia completa semanal ou mensal, completada por incrementais diárias. Não o inverso.
Quanto tempo deve demorar um restauro?
O RTO aceitável depende da criticidade. Numa loja online ativa: menos de 4 horas para um restauro completo é o objetivo. Abaixo de 2 horas com um procedimento rodado e armazenamento próximo. Acima de 8 horas, há um problema de estratégia ou de ferramentas.
Copiar os ficheiros e a base juntos ou separados?
Juntos, idealmente numa janela temporal apertada (10 a 15 minutos). Uma base e ficheiros dessincronizados (por exemplo, base copiada de manhã, ficheiros à noite) criam incoerências no restauro: produtos na base sem imagem, faturas referenciadas que não existem em ficheiro.
O armazenamento na nuvem (S3) é conforme ao RGPD?
Sim, se o fornecedor estiver na União Europeia ou propuser as Cláusulas Contratuais-Tipo para as transferências para fora da UE. AWS, Scaleway, OVH Object Storage e Backblaze são conformes com a configuração adequada. A cifragem antes do envio garante que mesmo um fornecedor comprometido não dá acesso a nada utilizável.
Qual é a diferença face a uma replicação em tempo real?
A replicação (master-slave MySQL, por exemplo) protege contra uma avaria de hardware, não contra erros humanos ou corrupções lógicas. Se um script apagar 10 000 produtos por engano, a réplica aplica o apagamento de imediato. A cópia versionada guarda uma versão sã anterior. As duas são complementares, não substituíveis.
Para ir mais longe
A cópia de segurança é um elo de uma cadeia mais larga: segurança, monitorização, gestão de incidentes. Um site bem copiado mas mal monitorizado perde dados à mesma entre o incidente e a sua deteção. Veja também o nosso guia de instalação de módulos PrestaShop para perceber onde o dfbackup se encaixa na stack, e o módulo de limpeza da base de dados PrestaShop: aligeirar a base antes da cópia divide por 5 o tempo de cópia e o custo de armazenamento.
