Guia de política de retenção de cópias de segurança para sites
Publicado em 6 de novembro de 2026
Uma cópia de segurança que existe, mas não consegue restaurar a versão correta do seu site, não traz muito conforto às 2h da manhã. Um guia prático sobre políticas de retenção de cópias de segurança começa com uma pergunta simples: quanto tempo atrás poderá ter de voltar quando algo avaria, é eliminado ou fica comprometido?
Para o site de uma pequena empresa, a resposta pode ser algumas semanas. Para uma agência que gere lojas, bases de dados e correio eletrónico de clientes, podem ser vários meses ou mais. A política certa não consiste em guardar todas as cópias de segurança para sempre. Consiste em guardar cópias limpas e recuperáveis em quantidade suficiente para resolver problemas reais, sem transformar os custos de armazenamento e a gestão num problema adicional.
O que faz realmente uma política de retenção de cópias de segurança
Um calendário de cópias de segurança indica quando são criadas as cópias. Uma política de retenção indica durante quanto tempo cada cópia fica disponível antes de ser eliminada. Precisa de ambos.
Sem regras de retenção, o armazenamento enche-se silenciosamente até as cópias de segurança falharem ou as faturas aumentarem sem motivo útil. Com regras demasiado agressivas, a cópia de segurança de que precisa pode já ter desaparecido. Isto acontece com mais frequência do que se pensa: uma atualização de um plug-in corrompido pode passar despercebida durante vários dias, uma eliminação acidental pode só ser descoberta no fim do mês ou um problema na base de dados pode ter sido copiado para todas as cópias de segurança recentes.
Uma boa política distingue a recuperação a curto prazo da proteção a longo prazo. As cópias de segurança recentes resolvem incidentes comuns, como uma implementação falhada ou uma atualização defeituosa do WordPress. Os pontos de restauro mais antigos ajudam a lidar com problemas de evolução lenta, auditorias, relatórios sazonais ou uma violação que demorou a ser detetada.
Comece pelas necessidades de recuperação, não pelo espaço de armazenamento
É tentador escolher os períodos de retenção com base na quantidade de armazenamento disponível. Em vez disso, comece pelos riscos. O armazenamento é um custo a gerir, mas a perda de dados do site, encomendas não concretizadas e uma interrupção prolongada costumam custar mais.
Dois objetivos de recuperação facilitam a decisão. O seu objetivo de ponto de recuperação, ou RPO, é a quantidade máxima de dados que pode perder. Se uma loja online só puder perder uma hora de encomendas, precisa de cópias de segurança ou de proteção da base de dados com, pelo menos, essa frequência. Um site institucional atualizado uma vez por semana pode tolerar um intervalo muito maior.
O seu objetivo de tempo de recuperação, ou RTO, indica a rapidez com que o serviço tem de voltar a funcionar. Uma cópia de segurança só é útil se conseguir restaurá-la dentro desse prazo. As cópias de segurança diárias podem cumprir o seu RPO, mas restaurar um servidor de grandes dimensões a partir de armazenamento remoto ainda pode ultrapassar o seu RTO. A retenção e a velocidade de recuperação têm de ser planeadas em conjunto.
Na maioria dos sites, classifique os sistemas de acordo com o impacto. Um portefólio pessoal, um site de marketing empresarial, uma loja WooCommerce movimentada, uma conta de alojamento de um cliente e um servidor de correio não devem seguir automaticamente as mesmas regras. Quanto mais frequentemente os dados mudarem e quanto mais receitas ou confiança deles dependerem, mais frequentes e cuidadosamente retidas deverão ser as cópias de segurança.
Um guia prático sobre políticas de retenção de cópias de segurança
Um calendário em camadas funciona bem, pois proporciona pontos de restauro frequentes sem reter indefinidamente todas as cópias de segurança completas. Um ponto de partida razoável para um site empresarial típico é manter as cópias de segurança diárias durante 14 a 30 dias, as semanais durante 8 a 12 semanas e as mensais durante 6 a 12 meses.
Este é um ponto de partida, não uma regra absoluta. Um site com atualizações diárias de conteúdo pode precisar de 30 versões diárias. Uma empresa de comércio eletrónico pode precisar de cópias de segurança mais frequentes da base de dados, especialmente durante períodos de vendas. Um programador que esteja a trabalhar numa grande reformulação pode aumentar temporariamente o período de retenção até a versão lançada estar estável. Um site estático pequeno pode ficar bem protegido com cópias semanais e mensais.
Para sistemas com registos financeiros, contratuais ou regulamentados, pode ser necessário um período de retenção mais longo. No entanto, não confunda a retenção operacional de cópias de segurança com a retenção formal de registos. Uma cópia de segurança destina-se à recuperação. Nem sempre é o formato, método de acesso ou sistema de controlo adequado para arquivos legais. Se a sua empresa tiver requisitos de conformidade, defina-os separadamente, com a orientação jurídica ou operacional adequada.
Mantenha mais versões em torno de alterações
O risco não se distribui uniformemente ao longo do calendário. As atualizações importantes de plug-ins, as migrações, as alterações aos servidores, as novas integrações e as importações em massa são momentos em que um site tem maior probabilidade de apresentar comportamentos inesperados.
Crie uma cópia de segurança verificada antes da alteração. Mantenha-a durante mais tempo do que o habitual, até a nova versão estar a funcionar corretamente há um período razoável. Por exemplo, se migrar o site de um cliente, mantenha a cópia de segurança anterior à migração até o cliente confirmar que os formulários, a entrega de correio, os pagamentos e as páginas principais funcionam como esperado.
Este pequeno hábito evita um erro comum: eliminar a última cópia comprovadamente funcional pouco antes de descobrir que o problema começou várias semanas antes.
Aplique o princípio 3-2-1 sem complicar
A abordagem 3-2-1 continua a ser útil porque protege contra diferentes tipos de falhas. Mantenha pelo menos três cópias dos dados importantes, em dois tipos diferentes de armazenamento, e guarde uma cópia fora do local.
Para um site, isso pode significar os dados ativos no servidor, uma cópia de segurança local ou gerida pelo fornecedor e uma cópia encriptada num armazenamento de cópias de segurança separado. O essencial é a separação. As cópias de segurança guardadas apenas no mesmo servidor podem desaparecer juntamente com ele. As cópias de segurança na mesma conta podem ficar expostas se as mesmas credenciais forem comprometidas.
Guardar cópias fora do local não tem de ser complicado. Significa que a cópia está protegida contra a falha da qual está a tentar recuperar. Escolha um local de armazenamento e um modelo de acesso que a sua equipa consiga realmente manter.
Proteja as cópias de segurança contra eliminação e ransomware
Uma política de cópias de segurança deve indicar quem pode eliminar cópias de segurança, alterar as definições de retenção e aceder aos dados de restauro. Estas permissões são importantes porque um atacante que obtenha acesso de administrador pode tentar remover pontos de recuperação antes de encriptar ou eliminar os dados de produção.
Quando disponível, utilize cópias de segurança imutáveis ou protegidas contra escrita durante um período definido. Isto impede que as cópias de segurança sejam alteradas ou eliminadas demasiado cedo, mesmo por uma conta com acesso alargado. Isto é especialmente valioso para sites críticos, fornecedores de alojamento e agências responsáveis por vários ambientes de clientes.
A encriptação também é importante. As cópias de segurança contêm frequentemente bases de dados, ficheiros de configuração, dados de clientes e, por vezes, credenciais. Encripte os dados em trânsito e em repouso, limite o acesso às pessoas que dele precisam e guarde as chaves de recuperação em segurança. Uma cópia de segurança perfeitamente retida, mas que ninguém consegue desencriptar, continua a representar um plano de recuperação falhado.
Teste os restauros antes de precisar de um
As mensagens de sucesso das cópias de segurança não são testes de restauro. Uma tarefa pode ser concluída com êxito, embora o arquivo esteja incompleto, a cópia da base de dados esteja danificada ou o processo de restauro seja demasiado lento para as suas necessidades.
Teste um restauro com uma periodicidade adequada à importância do sistema. Uma vez por trimestre pode ser suficiente para um site simples. As lojas com muito tráfego e os ambientes de alojamento devem testar com mais frequência, sobretudo após alterações às ferramentas de cópia de segurança, às configurações do servidor ou aos destinos de armazenamento.
Sempre que possível, restaure num ambiente de teste seguro. Verifique mais do que o carregamento da página inicial. Confirme se a base de dados estabelece ligação, se o conteúdo recente está presente, se os utilizadores conseguem iniciar sessão, se os ficheiros multimédia aparecem, se as tarefas agendadas são executadas e se as integrações de pagamentos ou dos formulários de contacto funcionam normalmente. Registe quanto tempo demorou a recuperação e que passos causaram dificuldades. Esse registo torna-se o manual de procedimentos que agradecerá ter durante um incidente.
Redija a política de forma a que outra pessoa a possa seguir
Uma política de retenção deve caber numa ou duas páginas, em vez de se tornar um documento que todos evitam abrir. Indique o que é abrangido pelas cópias de segurança, com que frequência são executadas, durante quanto tempo cada tipo de cópia é mantido, onde são guardadas, quem é responsável pelo processo e como são testados os restauros.
Defina também as exceções. Por exemplo, uma conta de cliente com uma base de dados de grande volume pode utilizar cópias de segurança mais frequentes, enquanto os projetos arquivados podem passar a ter apenas retenção mensal. Documentar as exceções impede que as definições se transformem num conjunto de decisões avulsas e misteriosas.
Os utilizadores do FASTPANEL podem dar mais visibilidade a este trabalho ao gerir sites, bases de dados e operações do servidor num único painel de controlo claro, em vez de procurarem definições em várias ferramentas. A visibilidade não substitui uma política, mas torna-a muito mais fácil de pôr em prática.
A sua política de retenção deve parecer aborrecida quando tudo está calmo. É um elogio. Quando surge uma atualização problemática, uma migração falhada ou uma eliminação acidental, «aborrecida» significa que a cópia certa continua disponível, que se conhece o processo de restauro e que a equipa tem uma base sólida para começar.