Backup and Disaster Recovery: Building a Plan You Can Actually Test

Most businesses have backups. Far fewer have a recovery plan, and the difference only becomes obvious on the worst possible day. A backup is a copy of data. A recovery plan is a documented answer to the question of how the business resumes operating, in what order, and how long it takes.

The gap between the two is where companies lose weeks. Here is how to close it.

Start with two numbers

Every recovery conversation should begin with two figures, defined per system rather than for the company as a whole.

Recovery point objective is how much data you can afford to lose, measured in time. If your accounting system is backed up nightly at 11 p.m. and fails at 4 p.m., you have lost a full business day of entries. If that is unacceptable, your RPO is shorter than your backup interval and the schedule needs to change.

Recovery time objective is how long the system can be down before the consequences become serious. An hour for a point-of-sale system. Perhaps a day for an internal file share. Perhaps a week for an archive nobody touches.

Setting these per system is what keeps the budget sane. Protecting everything to the strictest standard is expensive and usually unnecessary. Sort your systems into tiers, assign each tier an RPO and RTO, and let those numbers drive the design instead of guessing at a backup product.

The 3-2-1 rule still holds

The long-standing guidance remains sound: three copies of your data, on two different types of media, with one copy offsite.

The offsite copy is the part that gets skipped, and it is the part that matters most. A backup appliance sitting in the same room as the server it protects is not protection against fire, flood, theft, or a burst pipe in the ceiling. It also provides limited protection against ransomware, which increasingly targets backup repositories before touching production data.

Modern practice adds a fourth consideration: at least one copy should be immutable or otherwise isolated, so that credentials stolen from your network cannot be used to delete it. Offsite backup managed by a provider, with retention policies you cannot casually override, covers this in a way that a NAS in a closet does not.

Back up more than the file server

Ask most businesses what they back up and you will hear about the file server and maybe the accounting database. Then the outage comes and the list of things nobody copied gets long.

Work through this inventory:

• Servers and virtual machines, including the operating system and configuration rather than only the data volumes.
• Workstations and laptops, particularly for staff who keep working files locally regardless of policy.
• SaaS platforms. Microsoft 365 and Google Workspace protect their own infrastructure, not your data from your own users. A deleted mailbox, a mass file deletion, or a compromised account can exceed the provider's retention window. Third-party SaaS backup exists for a reason.
• Network device configurations. Switch, router, and firewall configs represent hours of work and are trivial to capture and easy to forget.
• Line-of-business applications with their own databases, license keys, and integration settings.
• Surveillance footage, where retention may be governed by policy or regulation.
• Documentation itself, including passwords, vendor contacts, and the recovery plan. A plan stored only on the server you are trying to restore is not a plan.

Untested backups are assumptions

The failure mode is consistent. Backup jobs report success for months. An outage comes, the restore begins, and the data is incomplete, the images will not boot, or the restore takes three days when the business assumed three hours.

Testing has to be scheduled, not intended.

Monthly: restore a handful of individual files from different systems and confirm they open correctly.

Quarterly: perform a full restore of at least one critical system into an isolated environment. Time it. Compare the actual duration to your RTO, because the two are almost never the same on the first attempt.

Annually: run a tabletop exercise. Gather the people who would be involved and walk through a realistic scenario end to end. Who declares an incident. Who calls the insurer and the provider. How staff are notified when email is unavailable. Where the plan is stored when the network is down. Which system comes back first.

Write down what failed during the test. The value of testing is the list of gaps it produces, and a test that surfaces no problems usually means the test was not realistic.

Recovery is a sequence, not an event

Restoring systems in the wrong order wastes hours. Dependencies matter, and they are rarely documented until someone is forced to work them out under pressure.

Domain services and authentication generally come first, because most other systems depend on them. Networking and connectivity come next, since without a working circuit the cloud-hosted pieces stay unreachable. Then the tier-one applications the business cannot operate without, then everything else.

Write the sequence down and include the practical details: which vendor to call, which account numbers apply, which credentials are needed, and who has authority to approve decisions. During an incident, nobody is thinking clearly, and a plan that assumes clear thinking will not be followed.

Connectivity belongs in the plan

Disaster recovery planning tends to focus on data and skip the network, which is a strange omission for a business running cloud applications and hosted voice. If the circuit is down, restored data is not reachable and phones do not ring, regardless of how good the backups are.

Include in the plan a redundant path for internet access, ideally over diverse media so that a single cut cable cannot take out both. SD-WAN can make that failover automatic, steering traffic to the surviving connection and moving sessions off a degraded circuit before staff notice. For voice, disaster routing that redirects inbound calls to mobile numbers or another site keeps customers reaching a person during the worst of it.

Also plan for the scenario where the building is unavailable. Staff working remotely need access, authentication, and phones, which is considerably easier when the phone system is already hosted and the applications are already reachable from outside the office.

Where managed services fit

The reason backup plans decay is rarely ignorance. It is that verifying jobs, patching systems, testing restores, and updating documentation are recurring work that competes with everything else, and the consequence of skipping a week is invisible until it is severe.

A managed arrangement puts that recurring work on someone whose job it is. That typically includes monitored offsite backup with verified job completion, 24x7 monitoring and alerting on the systems and circuits, patch management on a defined schedule, endpoint detection and response, and a documented escalation path when something breaks at 2 a.m. For businesses handling health information or card payments, it also means the controls and documentation those frameworks require rather than a good-faith effort.

The measure of the arrangement is simple. Ask when the last restore test was performed, ask to see the result, and ask how long the restore took.

Next step

If you are not confident your business could recover from losing a server tomorrow, the useful first move is small: pick your two most critical systems, write down their RPO and RTO, and test a restore against them.

Silver Star Telecom provides offsite backup, 24x7x365 monitoring and incident response, managed routers and firewalls, and SD-WAN failover for businesses across Oregon and Washington, with HIPAA and PCI compliance certifications behind the practice. To review your current backup and recovery posture, call (360) 524-7498 or email sales@silverstartelecom.com.