Three mechanisms, three failures
All three words refer to copies. They do not refer to the same copies, in the same place, or for the same length of time. The right question is not “do we have a copy?” but “which copy remains intact after a given failure?”
Versioning: the history of a file, kept within the service. Replication: a second copy of the service, kept up to date continuously. Backup: a separate, dated copy, kept for a chosen period.
Versioning: a file’s history, within the service
Each save creates a version. A paragraph deleted by mistake, a table overwritten, a wrong formula: the user opens the history and goes back to Tuesday’s version. It is fast, needs no intermediary, and is the most useful answer day to day.
Its limits come from where it lives. The history lives in the same service as the file:
- when the file is deleted, its versions go with it, first to the trash, then out of the service when the trash is emptied;
- an account allowed to delete a folder can generally also delete what it contains, history included;
- the number of versions and how long they are kept are limited by the service’s settings;
- if the entire service is destroyed or compromised, the history disappears with it.
The trash belongs to the same family. It is a reprieve before deletion, not a copy.
Replication: a second copy, in service
Replication keeps a copy of the service on another server or at another site. If one data center goes down, the other takes over. It addresses availability. ANSSI points it toward needs with very low data loss: when the acceptable loss is under 24 hours, it recommends favoring replication, synchronous or asynchronous.
Its flaw is its faithfulness. A copy that follows production also follows its mistakes. A deletion is replicated. A file encrypted by ransomware is replicated. With synchronous replication, this takes a few seconds. Syncing a workstation is small-scale replication: it has the same flaw.
Backup: a separate, dated, retained copy
Backup exists to go back in time. It is only worth something if it remains intact when production no longer is. That requires several properties:
- separation: another system, other accounts. ANSSI requires the backup infrastructure to be independent of production directories and administered by dedicated, named accounts;
- retention: a decided depth of history. ANSSI gives the example of fifteen days of daily backups, one year of monthly backups and five years of yearly backups, as an illustration, not a rule;
- protection against modification: ANSSI requires access control guaranteeing that backups will be neither modified nor altered. An immutable (WORM) backup meets this need. ANSSI nonetheless considers an offline copy more robust than an online WORM solution, and suggests combining the two;
- the 3-2-1 rule: three copies of the data, two of them backups on different media, and one offline;
- testing: a backup that has never been restored is a hypothesis. ANSSI requires regular tests.
Two measures complete the picture. The maximum tolerable data loss (RPO; PDMA in French) states how much work you accept to lose. The maximum tolerable downtime (RTO; DMIA in French) states how long you accept to wait. An hourly backup limits the loss to about one hour. It says nothing about the time needed to restore service.
Which mechanism addresses which failure
| Failure | Versioning | Replication | Backup |
|---|
| Editing mistake in a file | Yes, self-service | No, the mistake is copied | Yes, through a restore |
| File deleted yesterday | Yes, through the trash | No | Yes |
| File deleted three months ago | No, trash emptied | No | Only if retention goes back that far |
| Data center failure | No | Yes | Yes, more slowly |
| Folder deleted by a compromised admin account | No | No | Yes, if backups are beyond that account’s reach |
| Ransomware encrypting files on a synced workstation | Sometimes, if the history is intact | No | Yes, from an earlier point |
The demonstration: why back up a DMS that keeps versions
Take the most feared failure. An attacker obtains an administrator’s password. They delete the “Contracts” folder and empty the trash.
- Versioning is no help: the versions were stored with the deleted files.
- Neither is replication: the deletion was copied to the second site within seconds.
- The previous day’s backup, or the previous hour’s, contains the folder. If it is immutable and administered by other accounts, the attacker could not touch it.
Versioning and replication do their job well. It is simply not this job. The ransomware case, with the recovery order, is covered in protecting a DMS against ransomware, and restoring it.
Five questions to ask your provider
- How often are documents backed up, and how long are backups kept?
- Can an administration account of the service delete or modify a backup?
- Where are the copies, in how many locations, and is there an offline copy?
- When was a restore last tested?
- Who requests a restore, with what information, and how long does it take?
Written answers to these five questions are worth more than an availability percentage.
Common mistakes
- “Every workstation has a synced copy.” These copies follow the server, deletions included.
- “The trash keeps everything for thirty days.” It keeps what is not emptied. An attacker empties it.
- “We are replicated across two sites.” That is availability, not a way back.
- “The backup is running.” It still needs to have been restored at least once, and its retention must cover the time it takes to discover an incident.
Frequently asked questions
How do I recover an old version of a file?
Through the file’s history, without going through a restore. The steps are described in recovering a version of a document.
Does backup replace versioning?
No. Versioning is immediate and in the user’s hands. Restoring a backup is a heavier operation, often carried out by an administrator or by the provider.
Is a backup an archive?
No. A backup lasts days or weeks. Archiving meets a retention period set by law or by a policy. See retaining and archiving documents.
What about email?
The reasoning is the same, with its own mechanisms. See email backup, deletion and continuity.
Where Klytic fits
Versioning. Klytic Docs keeps the version history of every file and has a trash. Users recover a previous version themselves.
Backup. Documents are backed up every hour, as are email and the CRM. Backups are encrypted, kept for 30 days, replicated across several sites and immutable: once written, a backup can no longer be modified or deleted, even by an attacker. They are monitored and restores are tested every month. The targets are service restoration in under 4 hours (RTO) and no more than 2 hours of data lost (RPO).
Restore. It is requested from Klytic support, stating what is affected and the approximate date. It is included in the event of a service malfunction, deliberate deletion by an employee or an account deleted too early when someone leaves (up to 3 requests per month), or an attack suffered despite properly protected workstations. After an accidental deletion, a handling error, or if workstations were insufficiently protected, it is subject to a paid support ticket. Version history and the trash, at no cost, remain the first resort.
Backup is operated with WeDoBack, a specialist in secure backup, as stated on the security and backup page. WeDoBack handles the backup; version history is a Klytic Docs feature.
The limits: thirty days of retention do not cover a deletion discovered after that, and do not constitute archiving. Klytic is not a SecNumCloud-qualified offering.
This page describes general mechanisms. The periods and targets of your own service should be checked in your contract.
Sources
Consulted in October 2026.
- ANSSI, “Sauvegarde des systèmes d’information” (Information system backup), guide ANSSI-BP-100, v1.1: 3-2-1 rule with one offline copy, offline considered more robust than online WORM, retention periods to be defined, RPO and RTO (PDMA and DMIA), replication for a loss under 24 h, dedicated administration accounts, regular tests. messervices.cyber.gouv.fr
- ANSSI, “Les Essentiels, Sauvegarde des systèmes d’information” (The Essentials, Information system backup), v1.1: regular offline backups, access control so they are neither modified nor altered, infrastructure independent of production directories. messervices.cyber.gouv.fr
- Klytic, Security and backup: encrypted backup, 30 days, immutable, replicated across several locations, restores tested every month, RTO under 4 h, RPO under 2 h, backup operated with WeDoBack. klytic.com
- Klytic, frequently asked questions: hourly backup, encrypted, kept for 30 days; RTO and RPO targets. klytic.com
