Backup and retention are often used as if they meant the same thing. They are two different things, and confusing them explains a good share of the restores that fail. A backup is the act of copying your data. Retention is the rule that decides how long each copy is kept before it is erased.
A backup answers “do I have a copy?”
A backup is a copy of your data, taken at a given moment and stored separately. If the original is lost, corrupted or encrypted by an attack, the copy lets you go back. Without a backup, a deletion or an incident is permanent.
Retention answers “how far back can I go?”
Having a backup says nothing about how far back you can return. Retention sets that depth: fifteen days, a year, seven years. The classic trap: a problem goes unnoticed for weeks, and when the time comes to restore, the only copy available already contains the error. Too short a retention makes the backup useless precisely when it matters.
Deciding your retention is managing a risk
The right length is not a technical matter, it is a matter of risk and, sometimes, of obligation. Depending on your sector and your jurisdiction, certain data must be kept for a specific number of years.
The point is not to be alarmed, but to decide with full knowledge: what you must keep, what you have an interest in keeping, and what you can let go. We help you set those rules rather than inherit them.
The reasonable standard: two copies, and tested restores
For most organisations, the right instinct comes down to two points: two copies in two places (one local, one in the cloud), and restores checked from time to time. A backup that is never tested is an assumption, not a guarantee.
That is the aim of our approach to backup: copies that are yours, a retention decided with you, and the certainty that the restore works when the day comes.
