Your Backups Are Running. But Can Your Business Actually Recover?

Most businesses have some kind of backup system in place. Files are copied to cloud storage, databases are backed up overnight, and servers are configured to save recovery points at regular intervals. Once everything is running automatically, it is easy to assume that the organization is protected.

But there is an important question that often gets overlooked: what happens when you actually need those backups?

Imagine arriving at work one morning and discovering that your business server is inaccessible. Employees cannot open shared files, the accounting software is unavailable, and the customer database is no longer responding. The IT team begins investigating and discovers that a ransomware attack has affected several systems.

Someone asks the obvious question: “Can we restore everything from the backup?”

The team checks the backup console. The latest backup completed successfully. That sounds reassuring, until they discover that restoring the main database will take longer than expected, some application configurations are missing, and nobody has recently tested whether the recovery process works from beginning to end.

The business has backups. What it does not have is confidence that it can recover quickly.

This is a problem worth taking seriously. Backups are an essential part of cybersecurity, but simply creating copies of data does not guarantee that a business can recover from a cyberattack, accidental deletion, hardware failure or major service disruption.

A Successful Backup Does Not Guarantee a Successful Recovery

Backup software usually tells administrators whether a scheduled job completed successfully. That information is useful, but it only describes part of the picture. A backup job might complete without an obvious error while still failing to capture everything the business needs. A database may be copied successfully, but the application configuration required to use it may be missing. Files may be available, but the permissions needed to access them may not have been preserved correctly. A virtual machine backup may exist, but restoring it to the available infrastructure could take longer than anticipated. These are the kinds of problems that become apparent only when someone attempts a real recovery.

Consider a business that backs up its accounting database every night. If the server fails at 4 p.m., restoring the previous night's backup could mean losing much of that day's work. The business may also need to recover transaction logs, application settings and supporting files before the system can function normally.

The backup itself may be perfectly valid. The challenge is restoring a usable service with an acceptable amount of data loss. This is why organizations need to evaluate their recovery process, not just their backup status. Guidance from the U.S. Cybersecurity and Infrastructure Security Agency recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. The emphasis on testing is important because recovery cannot be assumed simply because a backup exists. (CISA: StopRansomware Guide).

What Happens When Ransomware Targets the Backups Too?

Ransomware is often associated with files becoming encrypted and a ransom demand appearing on the screen. However, modern attacks can involve more than disrupting the primary systems.

Attackers may attempt to gain administrative privileges, move through the network, and locate backup infrastructure. If they can access backup repositories using compromised credentials, they may try to delete, encrypt, or otherwise interfere with recovery data.

This changes the situation considerably.

A business might have a backup server, several copies of important files, and an automated cloud backup service. Yet if these resources are accessible through compromised accounts or connected to the same environment as the affected systems, an attacker may be able to interfere with them as well. Cloud backups are not automatically immune to this problem. If access permissions are poorly configured, an attacker who compromises an account with sufficient privileges may be able to delete backup data or alter recovery settings. In some configurations, unwanted changes to local files can also synchronise to cloud storage and affect previously stored copies.

The solution is not to avoid cloud backups. Cloud storage can be an important part of a resilient backup strategy. The key is to ensure that backup copies have appropriate access controls and protection against unauthorised deletion or modification. For critical systems, businesses should consider maintaining isolated or offline copies, using immutable storage where appropriate, and protecting backup administration with separate credentials and strong authentication. The objective is simple: if the primary environment is compromised, the recovery copies should remain available and trustworthy.

The Problem With Relying on One Backup Location

Storing backups in one location may appear convenient, especially when the backup process is automated. However, relying on a single repository can introduce a significant point of failure.

Imagine a company that stores its production data and all backup copies within the same cloud account. The arrangement may work well during normal operations. But if the account is compromised, an attacker could potentially gain access to both the original data and its backups, depending on the permissions and safeguards in place.

A similar problem can occur when backup storage is physically located alongside the primary infrastructure. A serious hardware incident, environmental problem or other site-wide disruption could affect both. This is why backup resilience should include consideration of where copies are stored, how they are accessed and whether a single incident could affect multiple copies at once.

The appropriate arrangement depends on the organisation's size, budget, regulatory obligations and technical environment. Some businesses may benefit from a separate cloud account with tightly restricted access. Others may need offline storage or a separate recovery location. What matters is avoiding a design in which every recovery option depends on the same vulnerable system, account or location.

How Long Can Your Business Afford to Be Offline?

One of the most useful questions to ask when planning recovery is how long the business can operate without a particular system. For some organisations, a short interruption to a non-critical application may be manageable. For others, losing access to customer records, payment systems, operational databases or business email can quickly affect daily work. This is where two recovery concepts become useful: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The Recovery Time Objective describes how quickly a system should be restored after disruption. The Recovery Point Objective describes how much data loss, measured in time, the business can tolerate.

For example, an organization might decide that its customer management system should be restored within four hours and that it can tolerate no more than one hour of lost data. These are illustrative targets, not universal standards. The right values depend on how the organization uses the system and what disruption would mean for its operations.

Once these targets are defined, the business can assess whether its backup frequency, storage arrangements and recovery procedures are suitable.

A backup taken once every 24 hours may be sufficient for some low-priority information, but it may be completely unsuitable for a system processing transactions throughout the day. Without clear recovery objectives, organizations can spend money on backups without knowing whether those backups meet their actual business needs.

Testing a Backup Is Different From Testing a Recovery

Many administrators regularly check backup reports and confirm that scheduled jobs have completed. That is good practice, but it should not be the final step. A backup test may confirm that a file exists and can be read. A recovery test goes further by checking whether the data can be restored and used as intended.

For example, an organization could restore a sample database to an isolated environment and verify that the database opens correctly, the records are accessible, and the associated application can connect to it. A server recovery exercise could check whether the operating system, required services, configurations and network connectivity can be brought back into operation. These exercises often reveal problems that ordinary backup reports do not show.

A backup repository might be approaching its storage limit. An encryption key may be unavailable to the recovery team. An administrator account required for restoration may no longer be active. A software licence may prevent an application from being rebuilt on replacement infrastructure.

None of these problems necessarily means the backup data itself is corrupted. However, any of them could delay recovery when time matters most. NIST's contingency planning guidance treats recovery as a coordinated process involving technical measures, procedures, and operational planning. Its approach reinforces the importance of preparing for disruption rather than assuming that stored data alone is enough. (NIST: Information System Contingency Planning)

Backing Up Files Is Not the Same as Backing Up a Business

Another common mistake is concentrating only on the data while overlooking the systems required to use it. A business application may depend on a database, a web server, application files, configuration settings, user permissions, network rules, certificates, and external integrations. Restoring the database alone may not bring the service back online.

For example, a company might have a complete copy of its customer database but no documented process for rebuilding the application server that connects to it. The data is safe, yet the application remains unavailable until the missing components are reconstructed. This is particularly important for organizations that rely on custom applications, older systems or software maintained by external developers.

Businesses should identify the components that make each critical service work and decide how those components will be recovered. That may involve backing up configuration files, maintaining system images, documenting dependencies, and ensuring that installation packages or deployment instructions are available. The purpose is not necessarily to create a complete copy of every system every day. It is to understand what is required to restore the service and make sure those requirements are covered by the recovery plan.

Cloud Applications Still Need a Recovery Strategy

Moving services to the cloud can simplify some aspects of infrastructure management, but it does not remove the need to plan for data loss and recovery. Cloud providers generally offer reliability features and may provide backup or versioning capabilities, depending on the service. However, these capabilities differ between platforms and are not always enabled by default. Their scope, retention periods and recovery options also vary.

A business using cloud email, file sharing, CRM software or hosted databases should understand what protection is included in its subscription and what additional arrangements it needs to manage itself.

For example, synchronization helps keep files consistent across devices, but synchronization alone is not necessarily a complete backup strategy. If a file is accidentally deleted or maliciously altered and that change is synchronized, the business needs a reliable way to retrieve an unaffected version. The same consideration applies to cloud account compromise. Organizations should understand whether they can recover deleted information, restore previous versions, and regain access if an administrator account or cloud environment is compromised. Cloud services can provide excellent recovery capabilities, but businesses need to configure and test those capabilities according to their own requirements.

Who Is Responsible When Recovery Is Needed?

Backup and recovery are sometimes treated as purely technical responsibilities. The IT team configures the jobs, checks the logs, and manages the storage. But a successful recovery also depends on decisions that extend beyond IT.

Management needs to determine which business services are most important. Department heads need to explain how much disruption they can tolerate. Finance teams may need to prioritise payment and accounting systems. Customer-facing teams may need alternative procedures while applications are unavailable. The IT team cannot establish every recovery priority without understanding these operational needs.

A practical recovery plan should therefore identify critical systems, define recovery priorities, assign responsibilities and document the steps needed to restore services. It should also explain how employees will communicate and continue essential work during an outage. This does not need to become an unnecessarily complicated document. A clear, tested plan that people understand is more valuable than a lengthy document nobody has practised using.

What Businesses Should Review Now

The first step is to identify the systems and information that are essential to daily operations. Businesses should understand where these resources are stored, how frequently they are backed up, and how long restoration would realistically take. Next, they should review how backup copies are protected. This includes checking who can access or delete them, whether backup administration is separated from ordinary user accounts, and whether important recovery copies are protected against unauthorized modification.

Recovery testing should then be scheduled according to the importance of the systems involved. Start with a small restoration exercise if necessary, but make sure the process goes beyond confirming that files exist. Verify that the restored data is usable and that the necessary applications and services can function.

Finally, review the recovery plan with the people who would be involved during an actual incident. Confirm that the required credentials, encryption keys, software licences, documentation and contact details will be available when needed. These steps do not guarantee that every incident will be resolved quickly. They do, however, help businesses identify weaknesses before those weaknesses become obstacles during a real recovery.

The Real Value of a Backup Is What It Allows You to Recover

Backups are often viewed as a routine IT task. Once the scheduled jobs are configured and the reports show success, the process can fade into the background. But the value of a backup is not measured only by how much data has been copied or how many successful jobs appear in a dashboard.

Its real value is measured by whether the organization can retrieve the information it needs, restore the systems it depends on, and resume operations within an acceptable timeframe.

A business may never experience a major ransomware incident or a serious infrastructure failure. Even so, accidental deletion, software problems, hardware faults and human error can make recovery necessary at any time. Preparing for that possibility is not about expecting the worst every day. It is about making sure that an unexpected disruption does not become a much larger business crisis.

Your backup system may report that everything is working perfectly. The only way to know whether your business is truly prepared is to test what happens when you need to recover.