Most businesses can say, with some confidence, that their systems are backed up. Far fewer can say how long it would take to get operating again after a failure, how much recent work would be lost, or who would do the restoring. That gap is the heart of the backup vs recovery plan question: copies of your data are only useful if you can turn them back into a working business.
Backup vs recovery plan: what is the difference?
A backup is a copy of something at a point in time. Recovery is getting the business running again, with data you can trust, within a time the business can tolerate. The first does not guarantee the second.
A typical pattern looks like this: the database is backed up nightly, but the application’s configuration, the file uploads and the credentials for connected services are not. When the server fails, the data exists, but rebuilding everything around it takes days of detective work. Or the backups have been running for a year, but nobody has tried a restore, and the first attempt reveals that the files are incomplete.
Neither case is unusual. Both are avoidable.
What should a disaster recovery plan for a small business cover?
A disaster recovery plan does not need to be a thick binder. For a small or growing business, a useful plan answers a small number of concrete questions for each important system.
- What is backed up. Not just the database. Uploaded files and documents, application configuration, environment settings, scheduled jobs, and the setup of integrations with other systems all need to be recoverable. If a connection to your accounting or payment system would have to be reconfigured from memory, it is not really covered.
- How often. The backup frequency determines how much recent work could be lost.
- Where. Backups kept on the same server or in the same account as the system they protect can be lost in the same incident. Copies should live somewhere separate, with access controlled.
- How long a restore takes. Measured, not estimated.
- Who does it. A named person or team, with the access they need already in place and a written procedure to follow.
- How consistency is checked. After a restore, how you confirm that records, balances and links between systems still agree.
- How it is tested. How often a restore is rehearsed, and what counts as a pass.
Recovery time objective and recovery point, in plain language
Two terms come up in any serious conversation about recovery: the recovery time objective and the recovery point objective. They are simpler than they sound.
| Term | The question it answers | What drives it |
|---|---|---|
| Recovery time objective | How long can this system be down before it seriously hurts the business? | Restore procedure, preparation and who is available |
| Recovery point objective | How much recent work can we afford to lose or re-enter? | How often data is backed up or replicated |
For a scheduling system that crews rely on each morning, a few hours of downtime might be tolerable but a full day would not. For an order system, losing an afternoon of orders might mean calling customers to reconstruct them. These are business judgments first and technical settings second. The right targets depend on the operating context, and they should be agreed by the people who feel the impact, not assumed by whoever set up the backups.
Tighter targets usually cost more to achieve, so the aim is not the shortest possible numbers everywhere. It is targets that match what each system actually supports.
The BOSYX view: A backup that has never been restored is an assumption, not a safeguard. Recovery confidence comes from knowing what is covered, how long a restore takes and who does it, and from having proved it.
Why test restores matter more than backup reports
The only way to know a backup works is to restore from it. A test restore, done into a separate environment so it does not affect live operations, answers questions that no configuration screen can:
- Are the files complete and readable?
- Does the application actually start with the restored data and configuration?
- How long did it take, compared with the recovery time the business agreed?
- Were there manual steps nobody had written down?
After the restore, check consistency. Compare record counts and key totals with the source. Confirm that references between systems still line up, for example that invoices in the application still match what the accounting system holds. A restore that brings back the database but leaves it out of step with connected systems can cause duplicate or missing business actions once integrations resume.
How often to test depends on how critical the system is and how often it changes. A test after any significant change to the system or its hosting is a sensible minimum.
Documentation and ownership
Recovery usually happens under pressure, often when the person who set things up is unavailable. That makes two things essential.
First, a written recovery procedure: where backups are, how to access them, the steps to restore, the order in which connected services come back, and how to verify the result. It should be clear enough that a competent person unfamiliar with the system could follow it.
Second, clear ownership. Someone must be responsible for checking that backups are running, that test restores happen on schedule, and that the plan is updated when the system changes. Without an owner, backup jobs fail quietly and nobody notices until they are needed. This is part of treating recovery as an operating responsibility rather than a one-time setup task, an approach described on our trust page.
Common questions
How often should we test restoring from backup?
It depends on how critical the system is and how often it changes. At a minimum, test after any significant change to the system or its hosting, and on a regular schedule agreed with whoever owns the plan.
Is software in the cloud automatically backed up?
Not necessarily in the way you need. Hosting providers protect their own infrastructure, but whether you can restore your data and configuration to a specific point in time depends on the service and how it is set up. Check what is actually included rather than assuming.
Who should own the recovery plan?
A named person or team who checks that backups run, schedules test restores and updates the plan when the system changes. That can be an internal owner or a support partner, as long as the responsibility is explicit.
The principle
Start with the business questions: how long each system can be down and how much work you can afford to lose. Make sure everything needed to run the system is covered, not just the data. Then prove it with a real restore, check the result, write the procedure down and give it an owner.
If you want recovery that is tested rather than assumed for the applications that run your operations, explore Managed Technology.