Backup and recovery

Business backup: what to protect and how to know it can be restored

A backup is useful only when it contains the right data and can be restored when the business needs it.

Buying storage or enabling a backup setting is not the whole job. The business must decide what needs protection, how much data it can afford to lose and how quickly important work must resume.

Start with the work the business cannot do without

List the information and systems needed for normal operations. This may include:

  • Finance and accounting data
  • Customer and supplier records
  • Documents stored on computers or servers
  • Email, OneDrive, SharePoint and Teams data
  • Line-of-business application data and databases
  • Website files and configuration
  • Device and server configuration
  • Information held by third-party services

Do not assume that every important file is stored in the main company folder. Staff may keep working files on desktops, laptops, personal cloud accounts or inside specialist applications.

Decide how much loss and delay the business can accept

How much recent work could be lost?

If backups run once each day, the business may lose changes made after the last successful backup. Systems that change frequently may need more frequent protection. Less active archives may need less.

How quickly must the data be available again?

Restoring one document is different from rebuilding a server or recovering a large cloud environment. Recovery time depends on the data size, connection, affected system and recovery method.

Do not promise a recovery time until it has been tested against the real environment.

Backup is not the same as sync

File synchronisation keeps files available across devices and locations. It can also copy an unwanted change. A deleted, corrupted or encrypted file may be synchronised before the problem is noticed.

A backup should provide controlled recovery points managed separately from normal working copies.

Backup is not the same as service availability

A cloud service may keep its platform available and still require the customer to make decisions about retention, recovery and backup.

Microsoft 365 has several recovery and retention features and a separate Microsoft 365 Backup service. The protection available depends on the services, licences, policies and backup products that have actually been configured.

The useful question is whether the organisation can recover the required mailbox, file, site or OneDrive account within its own recovery needs.

Keep recovery copies separate

Backups should not all depend on the same account, device or storage path as the working data. Separation can include:

  • A separate backup service or storage account
  • Restricted administrative access
  • Multi-factor authentication
  • Backup copies that normal users cannot change
  • Offline or isolated copies for critical data
  • Retention that preserves earlier recovery points

The design should consider what would happen if an administrator account, device, server or cloud tenant were compromised.

Direct-to-cloud backup can remove local hardware

Direct-to-cloud backup sends protected data to remote backup storage without requiring a local backup appliance. It can simplify hardware management and keep recovery copies away from the main site.

It also raises practical questions: how long the first backup and a large restore will take, what happens during a connection outage, where data is stored, how access is controlled, what retention applies, and how data is exported or deleted when the service ends.

Direct-to-cloud is one approach. It is not automatically the right answer for every workload.

Monitor every backup job

An automated job can fail because a device is offline, credentials have expired, storage is full or the data source has changed. Someone must be responsible for:

  • Reviewing failed or missed jobs
  • Confirming new devices and data sources are included
  • Investigating unexpected changes in backup size
  • Checking storage and retention
  • Keeping recovery instructions current
  • Escalating repeated failures

No alert is useful if nobody owns the response.

Test the restore

A successful backup report proves that a job completed. It does not prove that the business can recover everything it needs. Restore testing should confirm:

  • The required data is present
  • The selected recovery point is usable
  • Access permissions are understood
  • The restored data opens correctly
  • The recovery steps are documented
  • The time and resources required are realistic

Tests should cover the recovery scenarios that matter to the business. Restoring one small file is not enough evidence for every system.

Backups and ransomware

Backups can support recovery after ransomware, but they do not prevent the attack. Attackers may try to delete or encrypt accessible backup copies.

Recovery also requires clean systems, secured accounts and an incident process that avoids restoring the original compromise.

A practical backup checklist

Ask whether the business has listed its important systems, protected each data source, defined acceptable loss and delay, separated recovery copies, protected administrators, assigned monitoring responsibility and restored representative data successfully.

If several answers are uncertain, the backup arrangement needs a proper review. See Kwik Support’s backup and data-protection service.

A sensible next step

Talk to Kwik Support

Tell us about the current setup, the problem you are trying to solve and the outcome your business needs.