Small Business Backup Reality Check: 8 Questions Worth Asking Before You Need a Restore

Backups are one of those things people feel better about just by mentioning them.

The harder question is whether they would actually help under pressure.

Here are eight questions worth asking.

1. What exactly is being backed up?

What exactly is being backed up?
Files only? Whole systems? Cloud data? Shared drives? Email?

Start with the work the business cannot reasonably do without. That usually includes line-of-business applications, accounting data, customer files, shared documents, email, and the configuration that makes servers, firewalls, and cloud services work together.

Backing up a file share does not automatically protect a hosted email tenant, a SaaS application, or a virtual server. Many cloud platforms protect their own infrastructure, but that is different from keeping a separate, recoverable copy of your business data.

Inventory the systems, data owners, locations, and dependencies before choosing a backup product. A server image may restore the operating system quickly, but it will not help much if a critical cloud application, encryption key, license file, or vendor account is left out.

It also helps to separate the question of what is technically backed up from what is actually recoverable. A good backup scope names the systems covered, the data excluded, and the order in which the business would need things back.

NIST’s small-business guidance recommends identifying the data and assets that are important to the organization, backing them up regularly, and checking their integrity before restoration.

2. Where do the backups go?

Where do the backups go?
Local, cloud, or both?

Each location solves a different problem. A local copy can make a large restore faster when the office has power and the hardware is still usable, while an off-site copy can protect against theft, fire, flood, hardware loss, or a serious ransomware event.

Cloud backup is not automatically isolated just because it is in the cloud. If the same compromised administrator account can delete production data and backups, recovery may still be at risk.

For that reason, many plans use more than one copy and at least one copy that is off-site or otherwise protected from routine production access. The familiar 3-2-1 approach is a useful starting point: three copies of important data, on two types of media, with one copy stored off-site.

The right design depends on the size of the data, the available internet connection, recovery speed, and the systems being protected. The important part is documenting where each copy lives and how it can be reached during an outage.

CISA advises organizations to maintain offline or otherwise protected backups of critical data and to test them regularly, particularly because ransomware can target accessible backup repositories.

3. How long are they retained?

How long are they retained?
Retention matters more than people think.

Retention is the length of time older backup versions remain available. A backup can be running every night and still be unhelpful if it keeps only a few recent copies and a problem has been present for longer than that.

An employee might overwrite a folder, an accounting error may not be noticed until month-end, or ransomware may sit quietly before it encrypts files. In those cases, recovery may require a clean version from days, weeks, or months earlier.

There is no universal retention period. It should reflect the business’s legal, operational, and financial needs, along with the time it normally takes to notice a problem.

Retention also has practical limits. Longer histories cost more and can make storage management more complex. A sensible plan records the retention target for each important workload instead of applying one generic number to everything.

Review the plan when accounting cycles, regulatory requirements, applications, or storage costs change. The goal is not to keep every version forever. It is to have an appropriate clean recovery point when the business needs one.

4. Who can access them?

Who can access them?
That should be controlled and documented.

Backup access is powerful access. Anyone who can delete backup sets, change retention, disable jobs, or reset the backup administrator account can affect the business’s ability to recover.

Use named accounts where possible and give people only the permissions they need. Avoid shared administrator credentials that make it difficult to tell who changed a setting or to remove access when a staff member or vendor relationship changes.

Keep a current record of the backup provider, tenant, storage location, account owner, recovery contacts, and the process for emergency access. Store that record somewhere available even if the primary network or password manager is unavailable.

Multi-factor authentication, alerts for major configuration changes, and separation between everyday administration and backup administration can reduce avoidable risk.

A managed provider should be able to explain who has access and how the organization can regain control if the relationship ends. During a review, ask for more than a dashboard screenshot. Confirm the actual permissions, ownership, and recovery path before an incident makes those questions urgent.

5. When was the last restore test?

When was the last restore test?
A backup that has never been tested is still partly an assumption.

A successful backup job only proves that data was copied somewhere. It does not prove that the data is complete, readable, clean, or usable by the people who need it.

A restore test should match the risk. A simple test might recover representative files to a safe location, while a more important system may need a documented test of a full server, application, or virtual-machine recovery.

Record how long the test took, what steps were required, what failed, and what needs to change. That turns testing into an improvement cycle instead of a box-checking exercise.

Do not restore suspicious data directly into production during a cyber incident. Verify the integrity of the backup and follow the incident-response process so a compromised system is not brought back online without understanding what happened.

NIST’s Cybersecurity Framework 2.0 small-business quick-start guide specifically calls for regular backups and backup testing, including assessing the integrity of backed-up data and assets before using them for restoration.

6. How long would recovery actually take?

How long would recovery actually take?
Be honest.

Recovery time is not the same as the time it takes a backup job to finish. It includes recognizing the problem, deciding what to restore, obtaining access, rebuilding or replacing systems, moving the data, validating it, and returning people to work.

Internet bandwidth, the amount of data, the location of the backup, hardware availability, licensing, and application dependencies can all change the result. A multi-terabyte restore over a modest internet connection may take much longer than a dashboard suggests.

Set an honest recovery-time objective for each critical service. The point is to decide how long the business can tolerate an outage before choosing the level of redundancy, backup frequency, and recovery infrastructure needed.

Prioritize the systems that keep payroll, scheduling, communications, billing, or customer service moving. Not every system needs the same recovery target, but the order should be agreed on before an outage.

Write the expected timeline down and validate it during restore testing. Clear expectations make it easier to communicate with staff and customers when a real disruption occurs.

7. What would still be missing after recovery?

What would still be missing after recovery?
No plan restores literally everything instantly.

Some data may exist outside the backup scope, such as data entered after the last backup, locally stored files, personal device data, unexported application settings, or records held by a third-party platform. A recovery plan should identify those limits plainly.

Recovery-point objectives help frame the tradeoff. If a system is backed up once each night, the business may need to recreate work completed since that backup. More frequent protection can reduce that exposure, but it may cost more or require different technology.

Dependencies matter too. A restored server may still need DNS, identity services, internet access, certificates, payment integrations, printers, phones, or a vendor application before staff can use it normally.

Document realistic manual workarounds for the first few hours or days of an outage. A paper intake process, alternate phone routing, or a way to take payments later can reduce pressure while systems are being restored.

Be especially clear about cloud services and vendor-held data. Know what the provider can restore, what the business must retain separately, and who to call if the normal administration portal is unavailable.

8. Who owns the recovery process?

Who owns the recovery process?
Someone should be accountable for the sequence, not just the storage.

During an outage, a backup platform by itself does not coordinate decisions. Someone needs authority to determine what happened, contain the issue, start recovery, contact vendors, and communicate the status to leadership and staff.

That person does not need to perform every technical task, but the roles should be clear. Identify a primary owner, a backup owner, the managed service provider or vendor contacts, and the business decision-maker who can set recovery priorities.

Keep the recovery runbook practical: account locations, contact numbers, system order, credential-access instructions, approvals needed, and a record of the last test. Make sure it is accessible if the office network, email, or a primary computer is down.

Review ownership after staffing, vendor, or platform changes. A plan that names someone who has left the company or no longer has access is not a working plan.

CISA’s ransomware guidance also emphasizes documented and tested incident-response and communications plans. The goal is a calm, repeatable recovery process rather than trying to invent one in the middle of an outage.

If backup planning, vendor access, or continuity has become unclear, Texas 67 Systems can help through Managed IT Services for Small Businesses and Business Backup Internet and Failover.

Final thought

The goal is not to feel good about backup. The goal is to recover with less chaos.

If you want a backup review that focuses on what actually matters during recovery, Texas 67 can help.

Call 469-907-5567 or text 214-310-5445, or start at Contact Texas 67 Systems.

Sources

• CISA Ransomware Guide
• NIST Small Business Cybersecurity Corner
• NIST Cybersecurity Framework 2.0: Small Business Quick-Start Guide