Data Backup

Business Data Recovery: What to Do After Data Loss

8 min read
Business data moving between protected storage systems as part of backup and recovery planning

When business data is lost or unavailable, stop unnecessary changes, isolate systems involved in a suspected attack, preserve evidence, identify the affected data, and choose the safest recovery source before restoring anything. Acting quickly matters, but acting blindly can overwrite recoverable files, spread malware, or destroy evidence needed to understand the incident.

Data recovery is not one product. Recovering a deleted cloud folder is different from recovering a failed hard drive, corrupted server, encrypted network, or unavailable business application. The right response depends on what failed, why it failed, and whether the surrounding environment can be trusted.

This guide is for an active loss or outage. For prevention and recovery readiness, read our business cloud backup guide. For choosing where employees store and share working files, use the secure cloud storage guide.

Key takeaways

  • Do not reinstall, reformat, or keep writing data to a failed device before it is evaluated.
  • During a suspected cyberattack, isolate affected systems and preserve evidence before beginning a broad restoration.
  • Backup, data recovery, and disaster recovery are related but different capabilities.
  • A completed backup job does not prove that the data is usable, clean, complete, or fast enough to restore.
  • Recovery priority should follow business impact, dependencies, recovery time, and data-loss tolerance.

What should you do first after business data loss?

1. Stop unnecessary activity

If a file or drive was accidentally deleted, continued use may overwrite data that could otherwise be recovered. Do not install recovery software on the affected drive, reformat it, or copy new files onto it.

If a server or storage system is failing, avoid repeated restarts and improvised repair attempts. Record what happened, including error messages, unusual sounds, recent changes, and the time the problem began.

2. Isolate suspected compromised systems

If ransomware, malware, or unauthorized access may be involved, disconnect affected devices from the network and stop them from communicating with other systems. Avoid powering systems down automatically unless your incident-response team directs it, because volatile evidence may be lost.

CISA's StopRansomware Guide advises organizations to identify impacted systems, isolate them, preserve volatile evidence, and use clean systems for recovery. The exact sequence depends on the incident, which is why technical response should be coordinated rather than improvised.

3. Contact the response team

Notify the people responsible for IT, cybersecurity, leadership, insurance, legal guidance, and compliance as appropriate. Use known-good contact information. Do not rely only on an email system that may itself be compromised.

Establish one decision-making channel. Conflicting instructions from different vendors can slow containment and create additional damage.

4. Define the scope

Determine which users, devices, servers, cloud applications, folders, databases, and business processes are affected. Identify whether the problem is isolated or continuing to spread.

Ask what changed immediately before the incident: an update, a hardware alert, a new administrator, an unusual login, a deleted account, a phishing message, a vendor action, or a power event.

5. Protect recovery sources

Do not connect backups to a compromised environment until the response team understands the risk. Review backup access, administrator credentials, retention, immutability, and whether attackers may have reached the backup system.

Make copies of critical evidence and recovery media where appropriate. A rushed restore can contaminate the cleanest copy or bring the original problem back into production.

Backup, data recovery, and disaster recovery are different

Backup

A backup is a protected copy of data or a system. It may cover files, email, cloud platforms, databases, servers, workstations, configurations, or complete virtual machines.

Data recovery

Data recovery is the process of retrieving data that was deleted, corrupted, encrypted, damaged, or made inaccessible. The source may be a backup, cloud version history, application export, replica, intact storage media, forensic recovery, or reconstructed business records.

Disaster recovery

Disaster recovery restores the systems and dependencies needed to resume operations. That may include identity, networking, security, servers, applications, communication, and data in a planned sequence.

A company can have backups without a complete recovery plan. It can also restore files successfully while the business remains unable to operate because authentication, networking, or a critical application is still unavailable.

Which recovery path fits the failure?

Accidental deletion or cloud file changes

Start with the platform's recycle bin, version history, retention policy, and administrative recovery features. If those are insufficient, check whether the cloud data is covered by a separate backup platform.

Confirm whether permissions and sharing settings also need restoration. Recovering a folder without its access model can expose sensitive files or leave employees unable to work.

Failed laptop, desktop, or hard drive

If hardware failure is suspected, stop using the device. Recovery may involve restoring the user's data and configuration to a replacement computer, reading an intact drive through controlled methods, or sending damaged media to a specialist laboratory.

Mechanical damage, water, fire, and physically failing storage require different expertise from normal IT support. A provider should say clearly when specialist recovery is needed instead of experimenting on the only copy.

Server or virtual machine failure

Server recovery may use image-based backups, replicas, snapshots, file-level restores, database backups, or a rebuilt operating system. The team must understand dependencies such as identity, DNS, networking, certificates, storage, and application licensing.

Restoring the most visible server first is not always the fastest route back to operation. Recovery should follow the order required by the environment.

Ransomware or destructive malware

Ransomware recovery begins with containment and investigation, not an immediate mass restore. The response team needs to understand how access was gained, which accounts and systems were affected, whether data was taken, and which recovery points predate the compromise.

The FTC's ransomware guidance for businesses recommends disconnecting infected devices without powering them down, using experienced technical responders, investigating how access occurred, reporting the attack to appropriate authorities, and implementing a continuity plan.

Recovered systems should be clean, patched, protected, and placed into a controlled environment. Restoring vulnerable systems exactly as they were can recreate the conditions that allowed the incident.

Unavailable software-as-a-service application

If a cloud vendor has an outage or loses data, the business may have limited control over the platform itself. Recovery planning should identify exports, alternate communication, local copies of critical records, vendor escalation contacts, and any independent backup available for the application.

Ask cloud vendors what they back up, what customers can restore, how long deleted data is retained, and what happens if an administrator or attacker deletes information.

How do you decide what to restore first?

Recovery should follow business impact and technical dependencies. Build a list of:

  • Processes that affect safety, patient or customer service, revenue, payroll, and legal obligations.
  • Systems required for identity, networking, communication, and secure administration.
  • Applications and data each department needs to perform minimum operations.
  • Manual workarounds that can keep part of the business operating.
  • Vendors and credentials needed during recovery.

Two measurements help make priorities explicit:

  • Recovery Time Objective (RTO): how long the business can tolerate a system being unavailable.
  • Recovery Point Objective (RPO): how much recent data the business can tolerate losing.

A payroll system may tolerate several hours of downtime but very little missing data. A public website may need to return quickly even if it can use slightly older content. The recovery plan should reflect those differences.

Why a successful backup can still fail during recovery

Backup reports may show completed jobs while leaving serious gaps:

  • The critical application or cloud tenant was never included.
  • Retention is too short to reach a clean recovery point.
  • The backup uses credentials compromised in the same incident.
  • Data is present, but the application configuration or encryption key is missing.
  • The restore takes longer than the business can tolerate.
  • No one has tested a full recovery sequence.
  • The backup contains malware or corrupted data.

CISA recommends maintaining offline, encrypted backups and regularly testing their availability and integrity. A representative restore test should verify the data, document the time required, and identify missing dependencies.

A real ransomware recovery when the backups were affected

A single-location healthcare facility with more than 120 users called us after ransomware reached every server, more than 10 in total, and affected the backup environment. There was no clean one-button restore.

We contained systems, searched for usable backup data, validated recovery options, prioritized critical operations, handled technical communications during negotiations, and supported the HIPAA and New York State response. The recovery work continued into a redesigned co-managed IT and security operation.

Read the full healthcare ransomware recovery case study. The central lesson is that recovery depends on more than owning backup software. It depends on protected recovery sources, knowledgeable people, documented priorities, clear authority, and the ability to coordinate technical and business decisions under pressure.

How to evaluate a business data recovery provider

Ask the provider:

  • What information do you need before touching the affected system?
  • How will you avoid overwriting data or damaging the only copy?
  • Can you distinguish hardware recovery, backup restoration, cloud recovery, and cyber incident response?
  • When do you involve a forensic or physical-media specialist?
  • How will evidence and chain of custody be handled if a security incident is suspected?
  • How do you validate that restored data and systems are safe?
  • How will you prioritize business systems and communicate progress?
  • What cannot be guaranteed?

Be cautious with guarantees. No responsible provider can promise recovery before evaluating the media, backups, encryption, corruption, and incident scope.

What determines data recovery cost?

Cost depends on the type of failure, urgency, data volume, storage media, encryption, corruption, specialist laboratory work, number of systems, security investigation, after-hours response, and whether reliable backups exist.

A straightforward file restore from a verified cloud backup is very different from reconstructing an encrypted multi-server environment. Ask for the immediate diagnostic scope, decision points, and billing model before authorizing broad work.

How to improve recovery readiness before an incident

  • Inventory critical data, systems, cloud applications, and dependencies.
  • Set RTO and RPO expectations with business leadership.
  • Use separated, protected backups with appropriate retention.
  • Test file, cloud, server, and application recovery.
  • Protect backup administrators with MFA and limited privileges.
  • Document vendor contacts, credentials, and recovery procedures securely.
  • Write an incident response and communication plan.
  • Run tabletop exercises and record what needs improvement.

Our business data backup and recovery service connects coverage, access, retention, restore testing, and business continuity into one plan.

Recover safely, then reduce the chance of a repeat

The immediate goal is to restore the business without destroying evidence or bringing the original problem back. The longer-term goal is to understand why the loss occurred and improve access, backups, monitoring, documentation, and response.

If your New York or New Jersey business is dealing with data loss or needs to test whether its current backups are genuinely recoverable, contact Spot On Tech. For an active cyber incident, include a safe callback number and avoid sending sensitive details through a system you believe may be compromised.

Need help applying this?

Talk through your current technology setup.

We can help you connect the article topic to your actual systems, vendors, risk, and day-to-day support needs.

Contact Us