The Biggest Backup Mistake Businesses Keep Making

The question I get asked all the time

When people ask me about backups, the first question is usually: “Anthony, what backup software do you recommend?” I understand why. A product name feels like a straightforward place to start.

But I think there is a more useful question to ask first: what would it take to get this business working again after losing its data or systems?

Over the years, I’ve worked with Acronis, Synology, Windows Server Backup, Redstor, IDrive, FBackup, GFI Backup and other tools. I’ve also worked with OneDrive and NAS devices as part of the wider storage environment. These are different types of technology, with different jobs, strengths and limitations.

In my experience, backup failures usually come back to the strategy: what was protected, where the copies lived, who monitored them and whether anyone had tried to restore them. A well-known product cannot fill those gaps by itself.

So before comparing licence prices, list the things your business needs to operate. That could include accounting data, customer records, shared documents, email, a server application and the configuration that ties everything together. Then work out how you would recover each one.

One backup is never enough

One of the biggest mistakes I still see is relying on one backup location. It might be an external drive, a NAS in the office or a cloud service. Each can be useful. The concern is placing all your confidence in that one destination.

A drive can fail. A backup device can be stolen with the server it protects. An office incident can affect everything in the same room. A compromised administrator account may give an attacker access to both live data and reachable backups.

Keeping several folders on the same disk does not separate those risks. Neither does keeping the only backup on another partition of the server. Ask what could make both your working data and your recovery copy unavailable at the same time.

The aim is not to buy every type of storage available. It is to create enough independent recovery options that one failure does not take them all away.

A business backup strategy built around 3-2-1

The 3-2-1 rule is a useful starting framework. It means keeping three copies in total, including the working copy, using two different storage media and placing one copy off-site. It does not mean three backups in addition to your original data.

For example, a business might keep working data on its server, maintain a backup on a separate local appliance and send a further backup to an off-site service. That layout still needs a careful review: separate boxes can share credentials, network access or other dependencies.

Veeam’s explanation of 3-2-1 also describes the 3-2-1-1-0 extension. The additional “1” calls for a copy that is offline, air-gapped or immutable. The “0” refers to recovery verification without errors. Treat this as a planning framework, rather than a guarantee that any particular layout is safe.

Make at least one copy harder to change

An offline copy is disconnected when it is not being used. An air gap separates a copy from the environment that might be compromised. An immutable copy is configured to resist alteration or deletion for its retention period. These approaches have different operating requirements.

Check exactly what your platform protects and what an administrator can still change. An immutable label is useful only when the configuration, retention and access controls support the intended protection. A disconnected drive also needs a reliable rotation process; a forgotten drive with months-old data will disappoint you during recovery.

Encryption protects the confidentiality of a backup. It does not, by itself, stop someone deleting the backup. Keep the recovery keys securely available to authorised people so that losing the main environment does not also lock you out of the recovery copy.

OneDrive is useful, but it is not the whole recovery plan

I like OneDrive and recommend it regularly. It helps people collaborate, work from different places and keep files available across devices. Version history and recovery tools can be very useful too.

But I think of it primarily as a live working environment. When you edit a synced file, the change travels. When you delete it, the deletion can travel. Changes made by malware can also affect synced content.

That does not mean OneDrive has no protection. Microsoft documents file and OneDrive recovery options, including version recovery and, for eligible Microsoft 365 subscribers, rolling back OneDrive within the previous 30 days. Recycle-bin retention and recovery availability depend on the account and configuration.

The question is whether the available recovery options meet your business’s requirements. How far back can you restore? Can you recover if the normal account is unavailable? Does the protection include all the data you think it does? Can somebody complete the restore promptly?

Protect the rest of Microsoft 365 too

Do not assume a OneDrive plan also covers mailboxes, SharePoint sites and all the information people access through Teams. Identify where each type of data is stored, then confirm coverage and restore support for those workloads.

Microsoft and other providers offer dedicated backup services. Compare the actual scope, retention, recovery behaviour and access model of the service you are buying. The name of the cloud platform alone does not describe your backup plan.

This fits the wider lesson in my article on five Microsoft 365 mistakes I see over and over: useful services still need deliberate configuration and ongoing management.

Local and cloud backups solve different problems

If I were designing a backup strategy today, I would usually want a local recovery option, an off-site copy and, where appropriate, another copy protected from the primary environment. The mix would depend on the client’s systems, budget and recovery requirements.

Local recovery can save time

A nearby backup can help when you need to restore a large amount of data without downloading it over an internet connection. Some platforms also support recovering a server or running a temporary workload from the backup infrastructure.

Those capabilities need to be checked and tested. A local backup appliance is not automatically a replacement server, and having files available does not mean the accounting application will start.

Off-site recovery protects against a wider incident

An off-site copy provides an option when the office and its equipment are unavailable. A cloud backup can fulfil that role, provided the data reached the service successfully and you can access a suitable restore point.

Plan for download speed, recovery equipment, service access and any restore charges. Initial uploads and large restores can take time. In a South African business, the plan also needs to account for the power and connectivity available at the place where recovery would happen.

Illustrative layers, not a prescribed topology. Your platform may send backups to destinations in a different order.

RAID and snapshots have a role

RAID can help a storage system keep operating through certain disk failures. It does not provide an older copy of a deleted file or protect the whole device from theft. Snapshots can make some restores convenient, but snapshots on the same storage system share its failure risks. Use these features as part of the design, with separate backups where needed.

Decide how much work and time you can afford to lose

Backup planning becomes much clearer when you ask two business questions: how much recent work could we recreate, and how long could we operate without this system?

Microsoft explains these recovery objectives in its business continuity guidance. They are targets you design and test against, not promises created by switching on a backup job.

Illustrative example: an office that backs up successfully at 20:00 each evening could lose the next working day’s changes if its server fails at 16:00. The previous evening’s copy may be usable, but it will not include that day’s invoices and edits.

If recreating that work is unacceptable, the backup schedule needs to change. If the business needs its accounting system working within a few hours, a slow full-server download may not meet the requirement either.

Give critical systems their own targets. An archive and a live order-processing database may need very different protection. Agree the priorities with the people who use those systems, then measure whether the recovery process can meet them.

Back up what the business actually needs

A backup job can report success while leaving something important outside its scope. Start with an inventory rather than assuming that “the server is backed up” covers the whole business.

• Business applications: databases, application files and the supported recovery method.
• Shared and local files: server folders, NAS shares and important data left on workstations.
• Cloud workloads: the mailboxes, sites and accounts your business relies on.
• Configuration: settings, recovery instructions and other information needed to rebuild the environment.
• Dependencies: licences, installation media, encryption keys and authorised access.

Databases often need application-aware protection or an appropriate database backup process. Copying files that are open and changing is not automatically enough to produce a consistent application restore.

Also distinguish frequency from retention. A backup every hour tells you how often recovery points are created. Keeping those points for only a short period tells you how long you have to discover a mistake. A problem noticed weeks later may require an older version.

Balance that retention against the business’s records requirements, storage costs and responsibilities for the information it holds. Document the decisions so that future changes do not quietly reduce protection.

A successful backup job is only the start

A green status is encouraging. It confirms something about the backup process. It does not prove that an employee can open a restored document, that a database is consistent or that the business can restart its main application.

From my experience: I’ve had to tell people their data could not be recovered. Those conversations never get easier. I’ve also seen a failed server, accidental deletion or hardware problem become much more manageable because reliable backups existed. The relief when the data comes back is something you remember.

That is why I would rather see evidence from a restore test than rely entirely on a dashboard.

Test the recovery you would actually need

1. Restore a representative file to a separate location. Open it and confirm that the contents and version are right.
2. Recover a relevant application or workload in an isolated test environment. Check that it starts and that the people who use it can validate the data.
3. Measure the whole process. Include getting access, finding the restore point, arranging equipment and verifying the result.
4. Test access without the usual environment. Confirm that authorised staff can obtain recovery instructions and credentials if the main server or normal account is unavailable.
5. Record the outcome and fix the gaps. Keep the date, scope, recovery point, elapsed time and follow-up actions.

Use safe test locations so that an exercise does not overwrite current production data. A single-file test is a useful start, but it does not prove full-server recovery. Include the larger scenarios your business depends on, and repeat tests after significant system changes.

Choose a testing schedule based on the workload’s importance and rate of change. Automated verification can help, but practical checks by the people responsible for the system remain valuable.

Protect the backups and give someone responsibility

Backups are part of the security environment. If an attacker can use the same compromised credentials to erase live data and every recovery copy, having multiple destinations may provide less protection than you expect.

Use appropriate access restrictions, separate administrative roles where the platform supports them and multifactor authentication for backup management. Review whether a normal workstation or production account can modify the protected copies.

CISA’s ransomware guidance recommends keeping critical backups offline and encrypted, with regular recovery testing. This is useful because accessible recovery copies can also be targeted during an attack.

After an incident, restore into a clean environment and investigate the cause before reconnecting recovered systems. A backup is a recovery tool; it does not remove the underlying compromise.

Alerts need an owner

Decide who checks job status, storage capacity, missed runs and the age of the latest usable recovery point. Set alerts and make sure they reach someone who will investigate them. No notification is not the same as a successful backup.

Have a second authorised person who understands the process. Keep the instructions and necessary access details securely documented, with a way to obtain them when the main environment is down. The plan should survive the usual IT contact being unavailable.

Your practical backup health check

You do not need to replace everything today. Start by asking your IT team or provider for clear answers to these questions.

1. Which business systems and cloud workloads are protected, and which are excluded?
2. Where are the working data and backup copies stored?
3. Which copy remains usable if the premises or main administrator account is lost?
4. What protects at least one copy from alteration or deletion?
5. When was the latest successful backup, and how far back can we restore?
6. How much recent work could we lose, and how long would recovery take?
7. When was the last restore test, what did it cover and what did it prove?
8. Who investigates failures and who can recover the systems if that person is away?

If an answer is uncertain, turn it into an action with an owner and a date. Focus first on unprotected critical data, missing separate recovery copies and the absence of a proven restore process.

Choose software after defining the requirements

Once those requirements are clear, a product comparison becomes much more useful. Check workload support, retention, protected storage, monitoring, recovery options, access controls and support. Then compare the full cost, including storage, maintenance and recovery.

The most suitable product will depend on the environment. A small office and a business running several application servers do not necessarily need the same platform. Both need a plan that somebody can operate and demonstrate.

Final thoughts

If I were setting up a new business today, I would build the backup strategy around multiple layers: a dedicated platform, cloud storage for productivity, local recovery where useful, off-site protection and regular testing.

The technology can change with the budget and requirements. The principle stays the same: do not rely on one recovery copy, and do not assume a backup works because nobody has needed it yet.

The software you choose matters. The strategy behind it matters even more. Before your next product comparison, ask for the evidence that your business can recover.