Backup types
Backup types differ in how much data each run copies. The choice trades storage space against restore speed. Continuous data protection goes further and journals every change, which shrinks the recovery point toward zero.
| Type | What each run copies | What a restore needs | Trade-off |
|---|---|---|---|
| Full | The whole data set | One backup | Slowest run, most storage |
| Incremental | Changes since the last backup of any kind | The last full plus every incremental since, in order | Fast, compact runs; the longest restore chain |
| Differential | Changes since the last full backup | The last full plus the latest differential | Runs grow larger through the cycle |
| Synthetic full | Nothing new from the source: it is assembled from the last full and later incrementals | One backup | Light load of incremental runs, simple restore of a full |
Where backups are stored
Location decides how fast a restore runs and whether the backup survives what destroyed the original.
A local copy on a second disk, NAS or backup appliance restores fastest, but it shares the fire, theft, flood or site-wide ransomware that hit the original. An offsite copy, historically tape in a vault, survives a disaster at the main site, but access is slower.
A cloud copy is offsite by default and easy to scale, but restore time depends on bandwidth and volume. An offline or air-gapped copy has no network path once written, so malware on the network cannot reach it, and ransomware recovery plans rely on it. Backup copies are data at rest and need the same protection as the original. When retention ends, retired media goes through media sanitization.
The 3-2-1 rule
The 3-2-1 rule is the standard baseline for backup design: keep at least three copies of the data (the original plus two backups), on at least two different types of storage media, with at least one copy offsite.
A common extension, 3-2-1-1-0, adds one offline or immutable copy and zero errors in recovery tests.
Saving rules and replication
In the Anexet console, a saving rule sets where data is stored and whether it is also replicated to another server.
Backup vs. related concepts
"Backup" is often used loosely for related but different ideas. The difference matters when something has to be restored.
| Concept | What it does | Why it is not a backup |
|---|---|---|
| Archive | Keeps older data, usually moved off primary storage, for long-term retention or compliance | Serves retention, not restoring the current system |
| Snapshot | A point-in-time reference to data on the same storage, created almost instantly | Protects against accidental changes but usually fails with the storage it lives on |
| Replication | Continuously mirrors current data to a second site for fast failover | Mirrors corruption and malicious deletion too, so it is paired with backups |
| High availability | Keeps a service running when one component fails | Protects uptime, not data deleted or damaged before the failover |
Limits and common failures
Backups cover failures where the fix is to discard the damaged state and restore a known-good one: hardware failure, accidental deletion, software bugs, natural disasters, and ransomware. They are recovery controls, not preventive ones. A backup does not stop an intrusion, a deletion or an encryption event; it limits how much is lost after one.
In practice, backup strategies fail through process gaps more often than through technology:
- A backup that has never been test-restored is unverified. Such copies often turn out corrupted, incomplete or unreadable exactly when they are needed.
- A backup reachable with the same network and credentials as production can be deleted or encrypted by the same ransomware. The offline and immutable parts of 3-2-1-1-0 close this gap.
- A backup that copies data no one needs and misses the system that matters protects the wrong thing, however reliably it runs.
How it looks in Anexet
Anexet is a DLP and monitoring product, not backup software. These frames show how it stores data, rotates databases, replicates them to another server and keeps data for security reports for a set period. A backup plan answers the same questions for an organization's own data.
1 / 4
RPO and RTO
Two measures set the backup schedule and the storage tier. Low values justify frequent backups on fast storage. Systems that tolerate a day of loss and a day of downtime can be backed up less often, to cheaper media, without a meaningful rise in risk.
RPO (recovery point objective) is the maximum data loss the organization can tolerate, measured in time. An RPO of one hour means backups run at least hourly.
RTO (recovery time objective) is how long a restore may take before the outage becomes the bigger problem. A short RTO calls for fast storage.
Further reading: Mechanisms for ensuring the security of information systems.
A backup limits the loss after an incident; it does not prevent one. A copy that has never been test-restored is unverified.
