Nobody will ask whether you run backups. They will ask when you last restored one, how long it took, and who was watching the clock. A backup strategy is the written answer to that: what gets copied, how often, to where, how long it is kept, and how it comes back.
What belongs in scope, beyond user data
Restoring a business is not the same as restoring files. Scope has to cover system and network configurations, directory services and identities, keys and certificates, source code and deployment artefacts, log data for the later investigation, and the recovery runbook itself. The starting point is the asset inventory: whatever is missing there is, as a rule, not being backed up either, and the gap surfaces only when it matters.
3-2-1 is a convention, not a requirement
The best-known rule of thumb is three copies of the data, on two different media or systems, one of them at another location. It is a widely used convention of practice. It is not a requirement of ISO/IEC 27001, of the BSI's IT-Grundschutz, or of any legal provision, and it does not replace deriving the design from your own protection needs. As a starting point and as an audit question it remains useful.
That distinction matters in a due-diligence questionnaire. "We follow 3-2-1" satisfies no standard on its own. "Our retention depth and copy topology follow from the business impact analysis, and here is the reasoning" does.
3-2-1 and its variants
Two extensions and one older scheme come up almost as often as 3-2-1 itself, and get mistaken for requirements just as often:
| Scheme | What it adds | Status |
|---|---|---|
| 3-2-1 | three copies, two media, one off-site | Convention |
| 3-2-1-1 | plus one immutable or air-gapped copy | Convention |
| 3-2-1-1-0 | plus zero errors on verification: a restore that has actually been checked | Convention |
| Grandfather-Father-Son | a retention scheme, not a copy scheme: daily, weekly and monthly generations held side by side, on staggered retention | Convention, from tape backup |
The most interesting digit is the trailing zero. It shifts the standard from the existence of a copy to whether it has been verified, precisely the point where backup strategies fail in practice. Grandfather-Father-Son answers a different question from 3-2-1: not where the copy sits, but which point in time can still be restored. Both questions need an answer, and the second decides whether a clean state is even reachable after a compromise that went undetected for a while.
None of these schemes is a requirement. They are audit questions whose answer has to come from your own protection needs.
Backup types and what they mean for recovery
Which backup type you choose is not really a storage decision; it is a decision about how long recovery takes, and that duration is what everything hangs on when it matters.
| Type | What is copied | Consequence for recovery |
|---|---|---|
| Full backup | the entire dataset, every time | fastest to restore, because only one version is applied; the most expensive in storage and time |
| Differential backup | every change since the last full backup | restore from two versions: the full backup plus the latest differential |
| Incremental backup | only the changes since the last backup of any kind | the leanest to create, the most demanding to restore: the whole chain has to be complete and in order |
| Image or snapshot | the state of a system or volume at a point in time | fast rollback, but a snapshot on the same storage system is not a backup |
The last row is the most common misconception, and the third is the most common operational failure: a broken incremental chain does not show up when the backup runs; it shows up at restore time. Anyone backing up incrementally has to monitor the completeness of the chain, not just whether the last job succeeded.
Ransomware changed the requirement
Attackers go for the backups first, because a working restore destroys their business model. Several requirements follow from that: separate permissions and separate accounts for the backup environment; no sign-in with the same administrative accounts used in production; at least one copy that cannot be altered or deleted once written; and at least one copy without a permanent network connection. Retention depth counts just as much. It has to reach back past the point of compromise, and that point usually sits further back than the moment of detection.
Recovery is the test
| Question | Why it decides the outcome |
|---|---|
| Has the restore been tested? | An untested backup is an assumption, not evidence |
| How long does it actually take? | Damage is decided by duration, not by the existence of a copy |
| In what order is the restore performed? | Without an order for network, directory service, database and application, recovery stalls |
| Who may trigger it, including at night? | In a real event there is no time left to settle who decides |
| Is the runbook available independently? | Otherwise it lives inside the system that has just failed |
Target values for recovery time and tolerable data loss follow from the business impact analysis. There are no general reference values; they come out of the specific business process.
Cloud services and shared responsibility
Replication is not backup. Providers protect their platform against hardware and site failures, not necessarily against accidental or malicious deletion by an authorised account, and not against a faulty bulk change. Recycle-bin and retention periods are contractual, often short, and can be changed at any time. Whether the data you hold inside a service needs a backup of your own therefore belongs explicitly in the split of responsibilities: in writing, per service, with a named owner.
Data protection, retention and keys
Backups contain personal data and sit between deletion duties and recoverability. One common approach is to delete in the leading system, document the rule that individual records are not restored from backups, and let them expire with the backup cycle. That approach belongs in the deletion concept rather than being left open. Backups should be encrypted and the keys held separately; a key that exists only inside the failed system makes the backup worthless.
Where it usually goes wrong
- The backup job is monitored, the restore is never rehearsed.
- The backup system sits in the same sign-on domain as production.
- Retention depth does not reach back past the start of an intrusion.
- Nobody owns the data held inside a cloud service.
- The recovery runbook exists only digitally, inside the affected system.
Where the yardstick for your targets comes from
The hardest question in a backup strategy is not the technology but the justification: why a daily backup suffices for this system while that one needs hourly. Without a link to the business process the answer stays a convention. In Rizzqo the yardstick comes from above: a system inherits the protection needs of the primary assets it carries, particularly the availability and integrity requirement, including across several steps of a chain.
The backup environment itself belongs in the inventory too. A backup service or a second site is a supporting asset in its own right, with a category and an owner. That makes it visible when production and backup hang on the same provider or the same location, which a purely technical view routinely misses. The corresponding requirements from ISO/IEC 27002 appear on both objects and are answered there with evidence, for instance the result of a restore test.