If having a backup puts your mind at ease, answer this: when did you last try restoring it? Businesses that cannot give a date do not have a backup — they have an assumption that they have one.
Short answer: what is the difference between backup and disaster recovery?
Backup means taking a copy of your data; disaster recovery means planning how quickly the business becomes operational again. Backup is a question about files; disaster recovery is a question about time. You may have a backup, but if restoring it takes three days, for continuity purposes you effectively have none. The two are not alternatives: disaster recovery is the broader plan that contains backup within it.
RTO and RPO: the two numbers that decide everything
- RTO (Recovery Time Objective): How long can you tolerate being down after a failure — an hour, a day, three days?
- RPO (Recovery Point Objective): How much data loss can you accept — the last hour, the last day?
Every backup investment made without answering these rests on guesswork. A backup taken once a day means an RPO of 24 hours — in the worst case you lose a day of orders, invoices and customer records. Is that acceptable? The answer differs by business, and it is management, not the technical team, that must decide.
Backup and disaster recovery compared
| Criterion | Backup | Disaster recovery |
|---|---|---|
| Question it answers | Is there a copy of the data? | How soon does the business resume? |
| Scope | Files, database | Systems, configuration, network, process, people |
| Measured by | Backup frequency and retention | RTO and RPO |
| Tested by | Restore attempt | Scenario drill |
| Where it falls short | When restoration takes too long | If backups are corrupt (it depends on them) |
| Typical cost | Low to medium | Medium to high (driven by target RTO) |
The summary: backup is a precondition for disaster recovery, not a substitute for it. There is no disaster recovery plan without backups; but a business that only has backups has no disaster recovery plan either.
Does the 3-2-1 rule still hold?
The classic rule says: keep 3 copies of your data, on 2 different media, with 1 copy kept physically elsewhere.
It remains a sound foundation, but the ransomware era demands an addition: at least one copy must be immutable or unreachable. The reason is simple — a backup drive permanently attached to the server is not a backup during an attack but a second target. Attackers delete every backup they can reach before encrypting.
In practice: one of your backups must sit somewhere your main system's credentials cannot reach.
The restore drill: how do you know your backup works?
The most common problem with backup systems is that they appear to work without ever failing. A panel reporting "backup successful" does not prove that backup can be restored. It may be corrupt, missing a table, or lack a component required for restoration.
- Prepare a separate environment. Restore somewhere isolated, without touching production.
- Measure the time. How long it takes from start to a working system is your real RTO — not your estimate.
- Verify integrity. Check not only that files exist but that the database opens, recent records are present and the application runs.
- Note what is missing. Configuration files, SSL certificates, cron definitions and mail settings are the usual omissions.
- Repeat at least twice a year, and always after a major system change.
What does each type of business need?
Businesses tolerant of downtime (brochure sites, low transaction volume): a regular, separated and tested backup is usually sufficient. The real risk here is not the absence of a backup but the absence of testing.
Businesses processing continuously (online stores, bookings, customer portals): RPO must be measured in hours. A single daily backup here means unacceptable data loss. Restoration time must also be planned.
Businesses where downtime has direct legal or financial consequences: a written disaster recovery plan and regular drills are required, not just backups. Here the plan is an operational procedure rather than a technical document: who does what and when, who is informed, what customers are told.
Netişlem expert view: the three gaps we see most
Recovery work almost always reveals the same three gaps.
First, the backup sits in the same place as the server. Any server-level problem — hardware, attack, accidental deletion — affects the backup too. A backup is worth exactly as much as its independence from the main system.
Second, incomplete scope. The database is backed up but uploaded files are not; or the application is backed up but the server configuration is not. At restore time these gaps cost hours.
Third, the time was never measured. Most businesses saying "we have backups" do not know how long restoration takes. In a crisis that uncertainty does more damage than the technical fault, because no timeframe can be given to customers or staff.
Our recommendation always follows the same order: separate the backup, complete its scope, then restore it once and measure. With those three done, you hold a real guarantee.
Frequently asked questions
My hosting provider takes backups — isn't that enough?
A provider backup is an important layer but should not stand alone. Its scope, retention period and restoration procedure should be stated in your contract. Keeping at least one copy under your own control may also be your only route out of a provider-side problem.
Does syncing to cloud storage count as backup?
No. Synchronisation replicates changes — if a file is deleted or encrypted, the cloud copy is updated to match. Backup is the ability to go back in time. Synchronisation without version history is not a substitute.
How often should I take backups?
It depends on the data loss you can accept (your RPO). One backup a day means up to a day of loss in the worst case. Systems taking orders or transactions need shorter intervals. The right question is not "how often" but "how much loss can I absorb".
How long should backups be retained?
Keeping only the latest backup is risky: corruption or an intrusion may go unnoticed for days, and your single backup may contain the damaged state. The common approach is tiered retention — recent daily, weekly and monthly copies kept together. Legal retention duties, where they apply, also shape this.
Is writing a disaster recovery plan expensive?
The plan itself is a document and costs little; what drives cost is your target recovery time. A few-hour RTO and a few-day RTO require very different infrastructure. So the correct order is to set the target first and discuss cost second.
Conclusion
Backup answers "is my data still there?" Disaster recovery answers "how soon does my business resume?" A company that has never asked the second question is not prepared, even if the answer to the first is yes.
If you would like us to review your current setup and run a restore drill with you, get in touch. You can also review our corporate backup, secure hosting and SLA commitment.