Início›Guias›Documentos e GED

Documentos e GED · Entender

Versionamento, replicação e backup de documentos

Sim, uma gestão eletrônica de documentos (GED) que já guarda as versões dos seus arquivos precisa de backup. O versionamento corrige um erro de edição, a replicação resiste à falha de um site, o backup traz de volta um estado anterior após uma exclusão, um comprometimento ou um ransomware. Cada um cobre uma falha que os outros dois deixam passar.

Atualizado em outubro de 20266 minFontes oficiais citadas

Três mecanismos, três falhas

As três palavras designam cópias. Mas não as mesmas cópias, nem no mesmo lugar, nem pelo mesmo tempo. A pergunta certa não é “temos uma cópia?”, e sim “qual cópia continua intacta depois de determinada falha?”.

Versionamento: o histórico de um arquivo, mantido no serviço. Replicação: uma segunda cópia do serviço, atualizada continuamente. Backup: uma cópia separada, datada, mantida por um período escolhido.

O versionamento: o histórico de um arquivo, dentro do serviço

Cada salvamento cria uma versão. Um parágrafo excluído por engano, uma tabela sobrescrita, uma fórmula errada: o usuário abre o histórico e volta para a versão de terça-feira. É rápido, sem intermediário, e é a resposta mais útil no dia a dia.

Seus limites decorrem de onde ele fica. O histórico vive no mesmo serviço que o arquivo:

  • quando o arquivo é excluído, suas versões o acompanham, primeiro para a lixeira e depois para fora do serviço quando a lixeira é esvaziada;
  • a conta que tem o direito de apagar uma pasta em geral também pode apagar o que ela contém, inclusive o histórico;
  • o número de versões e 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.

A lixeira pertence à mesma família. É um prazo antes da exclusão definitiva, não uma cópia.

A replicação: uma segunda cópia, em operação

A replicação mantém uma cópia do serviço em outro servidor ou em outro site. Se um datacenter cai, o outro assume. Ela responde à disponibilidade. A ANSSI a indica para necessidades de perda de dados muito baixa: quando a perda admissível é inferior a 24 horas, recomenda priorizar a replicação, síncrona ou assíncrona.

Seu defeito é a fidelidade. Uma cópia que acompanha a produção acompanha também seus erros. Uma exclusão é replicada. Um arquivo criptografado por um ransomware é replicado. Em replicação síncrona, isso leva alguns segundos. A sincronização de uma estação de trabalho é uma replicação em pequena escala: tem o mesmo defeito.

O backup: uma cópia separada, datada, mantida

O backup existe para voltar atrás. Ele só tem valor se continuar intacto quando a produção já não está. Isso pressupõe várias propriedades:

  • a separação: outro sistema, outras contas. A ANSSI exige que a infraestrutura de backup seja independente dos diretórios de produção e administrada por contas nominais e dedicadas;
  • a retenção: uma profundidade de histórico definida. A ANSSI cita como exemplo quinze dias de backups diários, um ano de mensais e cinco anos de anuais, como ilustração, não como regra;
  • a proteção contra alteração: a ANSSI exige um controle de acesso que garanta que os backups não serão modificados nem adulterados. Um backup imutável (WORM) atende a essa necessidade. A ANSSI considera, no entanto, uma cópia off-line mais robusta do que uma solução WORM on-line, e propõe combinar as duas;
  • a regra 3-2-1: três cópias dos dados, das quais dois backups em mídias diferentes, e uma off-line;
  • os testes: um backup que nunca foi restaurado é 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. O tempo máximo de interrupção admissível (DMIA, ou RTO) diz quanto tempo se aceita esperar. Um backup a cada hora limita a perda a cerca de uma hora. Ele não diz nada sobre o tempo de retorno à operação.

Quem responde a qual falha

FalhaVersionamentoReplicaçãoBackup
Erro de edição em um arquivoSim, em autoatendimentoNão, o erro é copiadoSim, por uma restauração
Arquivo excluído ontemSim, pela lixeiraNãoSim
Arquivo excluído há três mesesNão, lixeira esvaziadaNãoSomente se a retenção alcançar essa data
Falha de um datacenterNãoSimSim, mais lentamente
Pasta apagada por uma conta de administração comprometidaNãoNãoSim, se os backups estiverem fora do alcance dessa conta
Ransomware que criptografa os arquivos de uma estação sincronizadaÀs vezes, se o histórico estiver intactoNãoSim, a partir de um ponto anterior

A demonstração: por que fazer backup de uma GED que versiona

Vejamos a falha mais temida. Um atacante obtém a senha de um administrador. Ele exclui a pasta “Contratos” e esvazia a lixeira.

  1. O versionamento não serve para nada: as versões estavam guardadas com os arquivos excluídos.
  2. A replicação também não: a exclusão foi copiada para o segundo site em poucos segundos.
  3. O backup da véspera, ou da hora anterior, contém a pasta. Se ele for imutável e administrado por outras contas, o atacante não conseguiu tocá-lo.

O versionamento e a replicação fazem bem o seu trabalho. Apenas não é esse trabalho. O caso do ransomware, com a ordem de retomada, é tratado em proteger uma GED contra ransomware e restaurá-la.

Cinco perguntas para fazer ao seu fornecedor

  1. Com que frequência os documentos passam por backup, e por quanto tempo os backups são mantidos?
  2. Uma conta de administração do serviço pode excluir ou modificar um backup?
  3. Onde ficam as cópias, em quantos lugares, e existe uma cópia off-line?
  4. Quando uma restauração foi testada pela última vez?
  5. Quem solicita uma restauração, com quais informações, e em quanto tempo ela é feita?

As respostas por escrito a essas cinco perguntas valem mais do que um percentual de disponibilidade.

Os erros mais comuns

  • “Cada estação tem uma cópia sincronizada.” Essas cópias acompanham o servidor, inclusive as exclusões.
  • “A lixeira guarda tudo por trinta dias.” Ela guarda o que não é esvaziado. Um atacante a esvazia.
  • “Estamos replicados em dois sites.” Isso é disponibilidade, não um retorno a um estado anterior.
  • “O backup está rodando.” Ainda é preciso que ele tenha sido restaurado pelo menos uma vez, e que sua retenção cubra o prazo de descoberta de um incidente.

Perguntas frequentes

Como recuperar uma versão antiga de um arquivo?

Pelo histórico do arquivo, sem passar por uma restauração. O procedimento está descrito em recuperar uma versão de um documento.

O backup substitui o versionamento?

Não. O versionamento é imediato e está nas mãos do usuário. A restauração de um backup é uma operação mais pesada, muitas vezes feita por um administrador ou pelo fornecedor.

Um backup é um arquivamento?

Não. Um backup dura dias ou semanas. Um arquivamento responde a um prazo de guarda fixado por um texto legal ou por uma política. Veja guardar e arquivar documentos.

E para o e-mail?

O raciocínio é o mesmo, com mecanismos próprios. Veja backup, exclusão e continuidade do e-mail.

Onde a Klytic se posiciona

Versionamento. O Klytic Docs mantém o histórico de versões de cada arquivo e tem uma lixeira. O próprio usuário recupera uma versão anterior.

Backup. Os documentos passam por backup a cada hora, assim como o e-mail e o CRM. Os backups são criptografados, mantidos por 30 dias, replicados em vários sites e imutáveis: um backup gravado não pode mais ser modificado nem excluído, nem mesmo por um atacante. Eles são monitorados e as restaurações são testadas todo mês. As metas são um retorno à operação em menos de 4 horas (RTO) e uma perda máxima de dados inferior a 2 horas (RPO).

Restauração. Ela é solicitada ao suporte Klytic, indicando o que foi afetado e a data aproximada. Está incluída em caso de mau funcionamento do serviço, de exclusão intencional por um colaborador ou de conta excluída cedo demais na saída de um colaborador (no limite de 3 solicitações por mês), ou de ataque sofrido apesar de estações corretamente protegidas. Após uma exclusão acidental, um erro de manuseio, ou se as estações estavam insuficientemente protegidas, ela é objeto de um chamado de suporte pago. O histórico de versões e a lixeira, sem custo, continuam sendo o primeiro recurso.

O backup é operado com a WeDoBack, especialista em backup seguro, como indica a página segurança e backup. A WeDoBack cuida do backup; o histórico de versões é uma função do Klytic Docs.

Os limites: trinta dias de retenção não cobrem uma exclusão descoberta depois desse prazo e não constituem um arquivamento. A Klytic não é uma oferta qualificada SecNumCloud.

Esta página descreve mecanismos gerais. Os prazos e as metas do seu próprio serviço devem ser verificados no seu contrato.

Fontes

Consultadas em outubro de 2026.

  • ANSSI, “Sauvegarde des systèmes d’information” (Backup dos sistemas de informação), guia ANSSI-BP-100, v1.1: regra 3-2-1 com uma cópia off-line, off-line considerado mais robusto que o WORM on-line, 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” (O essencial, backup dos sistemas de informação), v1.1: backups off-line regulares, controle de acesso para que não sejam modificados nem adulterados, infraestrutura independente dos diretórios de produção. messervices.cyber.gouv.fr
  • Klytic, Segurança e backup: backup criptografado, 30 dias, imutável, replicado em vários lugares, restaurações testadas todo mês, RTO inferior a 4 h, RPO inferior a 2 h, backup operado com a WeDoBack. klytic.com
  • Klytic, perguntas frequentes: backup a cada hora, criptografado, mantido por 30 dias; metas de RTO e RPO. klytic.com

Verificar o que as suas cópias cobrem

Descreva as falhas que você mais teme: dizemos qual das nossas cópias responde a cada uma.

Falar com um consultor →

Segurança e backup

Oferta de boas-vindas

30 dias de teste gratuito, migração acompanhada

Oferta de teste sem compromisso. Um consultor entra em contato para entender suas necessidades e preparar seu espaço Klytic.