A backup that cannot be restored when a server fails, a staff member deletes a folder, or ransomware strikes is not protecting the business. Cloud backup selection should therefore begin with one practical question: how quickly can your organisation return to normal when something goes wrong?
For many small and mid-sized organisations, cloud backup is presented as a simple storage decision. In reality, it is a resilience decision. The right service protects business continuity, supports cyber recovery and gives leaders confidence that a local incident will not become a prolonged operational disruption.
Cloud backup selection starts with recovery
Storage capacity matters, but it is rarely the deciding factor. Most organisations can buy more storage. The difficult part is agreeing what must be recovered, in what order, and how long the organisation can reasonably operate without it.
Consider a manufacturing business that loses access to a production planning system, or a school that cannot reach its management information system before the start of term. The impact is not measured in gigabytes. It is measured in lost working time, missed deadlines, disrupted services and pressure on staff.
This is why backup and disaster recovery should be considered together, even though they are not the same thing. Backup creates recoverable copies of data and systems. Disaster recovery is the wider plan for restoring services, people and processes after a serious incident. A cloud backup service may form a central part of that plan, but it does not replace it.
Two measures are particularly useful when comparing options. The recovery point objective, or RPO, defines how much data you can afford to lose. An RPO of four hours means that, in the worst case, up to four hours of changes may need to be recreated. The recovery time objective, or RTO, defines how long recovery can take before the effect becomes unacceptable.
A finance system may need a short RPO and RTO. Archived project records may not. Treating every system as equally critical makes backup unnecessarily expensive. Treating everything as low priority leaves the organisation exposed. The right balance comes from understanding operational priorities.
Identify what actually needs backing up
The first step is to build an accurate picture of where business information lives. This is more involved than listing servers. Data is often spread between on-site infrastructure, cloud platforms, staff laptops, mobile devices and specialist line-of-business applications.
Microsoft 365 is a common example. Email, Teams conversations, SharePoint sites and OneDrive files may be essential to daily work, yet they are sometimes assumed to be fully protected by the platform alone. Retention features and platform resilience have value, but they are not necessarily designed to meet every organisation’s recovery, retention or compliance requirements. Accidental deletion, malicious activity and misconfigured permissions still need to be addressed.
Look beyond obvious files and folders. Configuration data, virtual machines, databases, application settings, shared mailboxes and identity information can all be vital to a workable recovery. Rebuilding a server is one thing. Rebuilding the knowledge of how an application was configured is quite another.
Map dependencies before choosing a product
A backup may restore perfectly but still fail to restore a usable service if its dependencies are missing. An application might rely on a database, a particular network setting, user access controls or files held elsewhere. Record these relationships while assessing your environment.
This work also exposes systems that are no longer needed. Removing redundant data and retired applications before migrating to a new backup arrangement can reduce cost and simplify management. It is a useful discipline, especially for organisations that have grown through acquisitions, changes in software suppliers or years of ad hoc technology decisions.
Assess security as part of the backup design
Ransomware has changed the standard for backup. A copy of data is of limited value if an attacker can encrypt, delete or alter the copy as well as the live environment. Your cloud backup selection should include clear safeguards against this risk.
Immutable backup storage is one of the most valuable controls. It prevents backup data from being changed or deleted for a defined period, including by an account that may have been compromised. This creates a recovery point that attackers cannot easily destroy.
Access controls deserve the same attention. Backup administration should use multi-factor authentication, named accounts and carefully limited permissions. Avoid shared administrator credentials, particularly where the same account has broad access to production systems and the backup platform. Separating those duties makes it harder for a single compromised account to cause widespread damage.
Encryption should protect data in transit and at rest. Ask how encryption keys are managed, where backup data is held and what audit information is available. For public sector bodies, schools, charities and organisations handling sensitive personal data, these answers form part of wider data protection accountability. UK GDPR obligations do not specify one backup product, but they do require appropriate security and the ability to recover availability and access to personal data after an incident.
Decide on retention, location and recovery options
Retention is the period for which backups are kept. A short retention period may be enough for fast-moving operational data, while financial records, safeguarding information or contractual project material may need to be retained for longer. Retention policies should reflect legal, regulatory and business requirements, not the default setting offered by a supplier.
It is also worth distinguishing between backup retention and document retention. Keeping every version of every item indefinitely can create unnecessary cost and governance problems. A sensible policy sets different rules for different information types, with an agreed process for legal holds or exceptional records.
Data location may matter to customers, regulators and internal governance teams. A UK-based data location can make oversight simpler for some organisations, although the key issue is understanding the provider’s arrangements, contractual commitments and any cross-border processing. Do not rely on a vague statement that data is stored “in the cloud”. Ask where, how and under whose responsibility.
Recovery options are equally important. Restoring a single file, mailbox or SharePoint library is different from restoring a server, a virtual machine or an entire site. Check whether the service supports granular recovery as well as full recovery, and whether systems can be recovered to an alternative location if the original infrastructure is unavailable.
Factor in bandwidth, support and real-world cost
Cloud backup relies on connectivity. Initial backups can be substantial, particularly for virtual servers, design files or historical archives. Limited upload bandwidth may extend the first backup window and slow large-scale recovery. Some providers offer options such as local caching, staged seeding or recovery media to address this, but these should be assessed against the organisation’s actual connection and recovery objectives.
Cost comparisons should also go beyond the monthly price per user or per terabyte. Check whether fees apply for data retrieval, long-term retention, additional copies, priority support or faster recovery. A low headline cost can look less attractive if a serious incident produces unexpected restoration charges.
Support matters most when time is short. Establish who monitors failed backups, who receives alerts and who is responsible for starting recovery. A self-managed service can suit an organisation with experienced internal IT staff and clear procedures. A managed approach may be better where the internal team is small, stretched or responsible for wider operational duties.
Test the recovery, not just the backup
A successful backup report confirms that data was copied. It does not prove that the organisation can recover a working service within the required timeframe. Regular testing is where assumptions are replaced with evidence.
Tests should reflect realistic scenarios. Restore a deleted file, recover a mailbox, bring back a critical virtual server and, where appropriate, rehearse recovery from a cyber incident. Record how long each task takes, what information was missing and whether staff know their role. Test results should feed into improvements in both the technical setup and the wider incident plan.
For critical systems, agree the test schedule with system owners rather than leaving it solely to IT. They are best placed to confirm whether the recovered application, data and reports are genuinely usable for the business.
Questions to ask before making a decision
Before committing to a provider or platform, decision-makers should be able to get clear answers to these questions:
- What data, systems and cloud services are included, and what is excluded?
- What RPO and RTO can the service achieve for each critical workload?
- How are backups protected from ransomware, accidental deletion and unauthorised access?
- How long is data retained, where is it stored and what are the retrieval costs?
- Who monitors backup health, carries out restores and proves that recovery works?
Clear answers are more valuable than a long feature list. If a supplier cannot explain recovery in plain English, it will be harder to rely on them during an incident.
The best backup arrangement is not necessarily the one with the most storage or the most advanced-looking dashboard. It is the one that reflects the systems your people depend on, the disruption your organisation can tolerate and the support available when recovery is needed. Making those decisions before an incident is how technology continues to just work when circumstances do not.
