# Cópias de segurança de uma loja PrestaShop em 2026: regra 3-2-1, cifragem AES-256 e restauro testado > 6 lojas PrestaShop em 10 não têm uma cópia de segurança restaurável em menos de 4 horas. A regra 3-2-1, a cifragem AES-256, a rotação GFS e, sobretudo, o restauro testado. A estratégia de cópias de segurança que se devia ter em 2026. - Página: - Idioma: pt - Publicado em: 2026-05-26 - Atualizado em: 2026-05-26 - Outros idiomas: [fr](https://www.datafirefly.com/2026/05/26/sauvegarder-boutique-prestashop-regle-3-2-1-chiffrement-restauration-2026/index.md), [en](https://www.datafirefly.com/en/2026/05/26/backing-up-prestashop-store-3-2-1-encryption-restoration-2026/index.md), [es](https://www.datafirefly.com/es/2026/05/26/respaldar-tienda-prestashop-regla-3-2-1-cifrado-restauracion-2026/index.md), [de](https://www.datafirefly.com/de/2026/05/26/prestashop-shop-sichern-3-2-1-regel-verschluesselung-wiederherstellung-2026/index.md), [it](https://www.datafirefly.com/it/2026/05/26/backup-negozio-prestashop-regola-3-2-1-cifratura-ripristino-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/05/26/kopie-zapasowe-sklepu-prestashop-regula-3-2-1-szyfrowanie-przywracanie-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/05/26/prestashop-shop-backuppen-3-2-1-regel-aes-256-versleuteling-geteste-restore-2026/index.md) - Índice: 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: 1. **Cópia 1**: a produção (o servidor de produção). 2. **Cópia 2**: cópia local ou no mesmo alojamento (rápida de restaurar nos incidentes menores). 3. **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](https://www.datafirefly.com/pt/produto/copia-seguranca-prestashop/) 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](https://www.datafirefly.com/pt/2026/05/01/instalar-modulo-prestashop-8-guia-completo/) para perceber onde o dfbackup se encaixa na stack, e o módulo de [limpeza da base de dados PrestaShop](https://www.datafirefly.com/pt/produto/limpeza-base-dados-prestashop/): aligeirar a base antes da cópia divide por 5 o tempo de cópia e o custo de armazenamento.