Três mecanismos, três avarias
As três palavras designam cópias. Não designam as mesmas cópias, nem no mesmo local, nem pelo mesmo tempo. A pergunta certa não é «temos uma cópia?», mas sim «que cópia fica intacta após esta avaria?».
Controlo de versões: o histórico de um ficheiro, conservado no serviço. Replicação: uma segunda cópia do serviço, mantida atualizada em contínuo. Cópia de segurança: uma cópia separada, datada, conservada durante um período escolhido.
O controlo de versões: o histórico de um ficheiro, no serviço
Cada gravação cria uma versão. Um parágrafo eliminado por engano, uma tabela substituída, uma fórmula errada: o utilizador abre o histórico e volta à versão de terça-feira. É rápido, sem intermediários, e é a resposta mais útil no dia a dia.
Os seus limites resultam da sua localização. O histórico vive no mesmo serviço que o ficheiro:
- quando o ficheiro é eliminado, as suas versões acompanham-no, primeiro para o lixo e depois para fora do serviço quando o lixo é esvaziado;
- a conta que tem o direito de apagar uma pasta pode, em geral, apagar também o que ela contém, incluindo o histórico;
- o número de versões e a sua duração são limitados pelas configurações do serviço;
- se o serviço inteiro for destruído ou comprometido, o histórico desaparece com ele.
O lixo pertence à mesma família. É um adiamento antes da eliminação, não uma cópia.
A replicação: uma segunda cópia, em serviço
A replicação mantém uma cópia do serviço noutro servidor ou noutro local. Se um centro de dados falhar, o outro assume. Responde à disponibilidade. A ANSSI orienta-a para as necessidades de perda de dados muito reduzida: quando a perda admissível é inferior a 24 horas, recomenda privilegiar a replicação, síncrona ou assíncrona.
O seu defeito é a sua fidelidade. Uma cópia que segue a produção segue também os seus erros. Uma eliminação é replicada. Um ficheiro encriptado por um ransomware é replicado. Em replicação síncrona, isso demora alguns segundos. A sincronização de um posto de trabalho é uma replicação em pequena escala: tem o mesmo defeito.
A cópia de segurança: uma cópia separada, datada, conservada
A cópia de segurança serve para voltar atrás. Só tem valor se permanecer intacta quando a produção já não o está. Isso pressupõe várias propriedades:
- a separação: outro sistema, outras contas. A ANSSI exige que a infraestrutura de cópias de segurança seja independente dos diretórios de produção e administrada por contas nominativas e dedicadas;
- a retenção: uma profundidade de histórico decidida. A ANSSI dá como exemplo quinze dias de cópias diárias, um ano de mensais e cinco anos de anuais, como ilustração, não como regra;
- a proteção contra a alteração: a ANSSI exige um controlo de acesso que garanta que as cópias de segurança não serão modificadas nem alteradas. Uma cópia de segurança imutável (WORM) responde a esta necessidade. A ANSSI considera, no entanto, uma cópia offline mais robusta do que uma solução WORM online, e propõe combinar as duas;
- a regra 3-2-1: três cópias dos dados, das quais duas cópias de segurança em suportes diferentes, e uma offline;
- os testes: uma cópia de segurança que nunca foi restaurada é uma hipótese. A ANSSI exige testes regulares.
Duas medidas completam o quadro. A perda máxima de dados admissível (PDMA, ou RPO) diz quanto trabalho se aceita perder. A duração máxima de interrupção admissível (DMIA, ou RTO) diz quanto tempo se aceita esperar. Uma cópia de segurança horária limita a perda a cerca de uma hora. Não diz nada sobre o tempo de reposição do serviço.
Quem responde a que avaria
| Avaria | Controlo de versões | Replicação | Cópia de segurança |
|---|
| Erro de edição num ficheiro | Sim, em autosserviço | Não, o erro é copiado | Sim, através de uma restauração |
| Ficheiro eliminado ontem | Sim, através do lixo | Não | Sim |
| Ficheiro eliminado há três meses | Não, lixo esvaziado | Não | Só se a retenção recuar até essa data |
| Avaria de um centro de dados | Não | Sim | Sim, mais lentamente |
| Pasta apagada por uma conta de administração comprometida | Não | Não | Sim, se as cópias de segurança escaparem a essa conta |
| Ransomware que encripta os ficheiros de um posto sincronizado | Por vezes, se o histórico estiver intacto | Não | Sim, a partir de um ponto anterior |
A demonstração: porque fazer cópia de segurança de um sistema de gestão documental que guarda versões
Tomemos a avaria mais temida. Um atacante obtém a palavra-passe de um administrador. Elimina a pasta «Contratos» e esvazia o lixo.
- O controlo de versões não serve de nada: as versões estavam guardadas com os ficheiros eliminados.
- A replicação também não: a eliminação foi copiada para o segundo local em poucos segundos.
- A cópia de segurança da véspera, ou da hora anterior, contém a pasta. Se for imutável e administrada por outras contas, o atacante não lhe pôde tocar.
O controlo de versões e a replicação fazem bem o seu trabalho. Simplesmente, não é este trabalho. O caso do ransomware, com a ordem de recuperação, é tratado em proteger a gestão documental contra um ransomware e restaurá-la.
Cinco perguntas a fazer ao seu prestador
- Com que frequência é feita a cópia de segurança dos documentos, e durante quanto tempo são guardadas as cópias?
- Uma conta de administração do serviço pode eliminar ou modificar uma cópia de segurança?
- Onde estão as cópias, em quantos locais, e existe uma cópia offline?
- Quando foi testada uma restauração pela última vez?
- Quem pede uma restauração, com que informações, e em quanto tempo é feita?
As respostas escritas a estas cinco perguntas valem mais do que uma percentagem de disponibilidade.
Os erros frequentes
- «Cada posto tem uma cópia sincronizada.» Estas cópias seguem o servidor, incluindo as eliminações.
- «O lixo guarda tudo durante trinta dias.» Guarda o que não for esvaziado. Um atacante esvazia-o.
- «Estamos replicados em dois locais.» Isso é disponibilidade, não um regresso a um estado anterior.
- «A cópia de segurança está a correr.» Ainda é preciso que tenha sido restaurada pelo menos uma vez e que a sua retenção cubra o prazo de descoberta de um incidente.
Perguntas frequentes
Como recuperar uma versão antiga de um ficheiro?
Através do histórico do ficheiro, sem passar por uma restauração. O gesto está descrito em recuperar uma versão de um documento.
A cópia de segurança substitui o controlo de versões?
Não. O controlo de versões é imediato e está nas mãos do utilizador. A restauração de uma cópia de segurança é uma operação mais pesada, muitas vezes feita por um administrador ou pelo prestador.
Uma cópia de segurança é um arquivo?
Não. Uma cópia de segurança dura dias ou semanas. Um arquivo responde a um prazo de conservação fixado por um texto ou por uma política. Veja conservar e arquivar os documentos.
E para o correio eletrónico?
O raciocínio é o mesmo, com os seus próprios mecanismos. Veja cópia de segurança, eliminação e continuidade do correio eletrónico.
Onde se situa a Klytic
Controlo de versões. O Klytic Docs conserva o histórico de versões de cada ficheiro e dispõe de um lixo. O próprio utilizador recupera uma versão anterior.
Cópia de segurança. É feita uma cópia de segurança dos documentos a cada hora, tal como do correio eletrónico e do CRM. As cópias de segurança são encriptadas, conservadas durante 30 dias, replicadas em vários locais e imutáveis: uma cópia escrita já não pode ser modificada nem eliminada, nem mesmo por um atacante. São supervisionadas e as restaurações são testadas todos os meses. Os objetivos visados são uma reposição do serviço em menos de 4 horas (RTO) e menos de 2 horas de dados perdidos no máximo (RPO).
Restauração. Pede-se ao suporte da Klytic, indicando o que está em causa e a data aproximada. Está incluída em caso de mau funcionamento do serviço, de eliminação voluntária por um trabalhador ou de conta eliminada demasiado cedo aquando de uma saída (no limite de 3 pedidos por mês), ou de ataque sofrido apesar de postos corretamente protegidos. Após uma eliminação acidental, um erro de manipulação, ou se os postos estavam insuficientemente protegidos, é objeto de um ticket de assistência pago. O histórico de versões e o lixo, sem custos, continuam a ser o primeiro recurso.
A cópia de segurança é operada com a WeDoBack, especialista em cópias de segurança protegidas, como indica a página segurança e cópias de segurança. A WeDoBack assegura a cópia de segurança; o histórico de versões é uma função do Klytic Docs.
Os limites: trinta dias de retenção não cobrem uma eliminação descoberta para além desse prazo e não constituem um arquivo. A Klytic não é uma oferta qualificada SecNumCloud.
Esta página descreve mecanismos gerais. Os prazos e objetivos do seu próprio serviço verificam-se no seu contrato.
Fontes
Consultadas em outubro de 2026.
- ANSSI, «Sauvegarde des systèmes d’information» (Cópia de segurança dos sistemas de informação), guia ANSSI-BP-100, v1.1: regra 3-2-1 com uma cópia offline, offline considerado mais robusto do que o WORM online, prazos de retenção a definir, PDMA e DMIA, replicação para uma perda inferior a 24 h, contas de administração dedicadas, testes regulares. messervices.cyber.gouv.fr
- ANSSI, «Les Essentiels, Sauvegarde des systèmes d’information» (Os Essenciais, Cópia de segurança dos sistemas de informação), v1.1: cópias de segurança offline regulares, controlo de acesso para que não sejam modificadas nem alteradas, infraestrutura independente dos diretórios de produção. messervices.cyber.gouv.fr
- Klytic, Segurança e cópias de segurança: cópia de segurança encriptada, 30 dias, imutável, replicada em vários locais, restaurações testadas todos os meses, RTO inferior a 4 h, RPO inferior a 2 h, cópia de segurança operada com a WeDoBack. klytic.com
- Klytic, perguntas frequentes: cópia de segurança a cada hora, encriptada, conservada durante 30 dias; objetivos RTO e RPO. klytic.com
