Seven Backup Gaps Contractors Usually Find Too Late

Backups often fail in ways nobody notices until a crisis. Review these seven common gaps in contractor environments and fix them while there is still time.

3 min readBy Ironfield Cyber Team

Almost every contractor and energy services company has some kind of backup. Many have never needed to rely on it in a real emergency. When they do, they discover the backup covers less than they thought, takes longer to restore than they assumed or was deleted along with everything else. Here are seven gaps worth checking this week.

1. Important data that was never included

Backups follow a list, and lists get out of date. New servers, cloud applications, laptops used as the only copy and shared drives created for a single project are often left out.

Fix: Build an inventory of systems and data, including cloud services, and compare it to what the backup actually covers. Repeat after every major change.

2. Backups that sit on the same network as the data

If a backup drive or server is reachable with the same credentials as production systems, ransomware can reach it too. Attackers often look for backups specifically and delete or encrypt them before announcing themselves.

Fix: Keep at least one copy that cannot be changed or deleted from the production environment, such as an offline copy or one with immutability protections. Use separate credentials, with multi-factor authentication, for backup administration.

3. Success messages nobody reads

A backup job that reports success every night may be backing up an empty folder, a locked file or a failing disk. Alerts that go to an unmonitored mailbox help nobody.

Fix: Assign a named person or provider to review backup reports and investigate failures within a day. Spot-check that recent files actually appear in backups.

4. Untested restores

The most common gap is the simplest. Nobody has proven the backup can be restored. Corrupted media, missing encryption keys, forgotten passwords and incompatible software all appear only at restore time.

Fix: Schedule restore tests at least quarterly. Restore a file, a database and, periodically, a full system into a separate environment. Record the time it takes.

5. Recovery time nobody planned for

Even a perfect backup can take a long time to restore, particularly large databases and file servers over limited bandwidth. Operations may be stalled during that time.

Fix: Decide how long each system can be down, and compare that to measured restore times. For critical systems, consider local copies that restore faster alongside off-site copies. Prioritize the order in which systems come back.

6. Cloud data assumed to be safe

Many companies assume that because software is in the cloud, the vendor handles backup. Vendors generally protect their platform, but your data can be deleted or altered by users, by malicious actors with stolen credentials or by an integration gone wrong. Retention of deleted items is often limited.

Fix: Read the terms for each cloud application you depend on, and add independent backups for email, file storage and critical business data where the vendor's protection does not meet your needs.

7. Missing keys, passwords and documentation

During recovery, people need encryption keys, administrator credentials, licensing details, network diagrams and vendor contacts. If these live only on systems that are down, recovery stalls.

Fix: Keep an offline, access-controlled recovery binder, physical or encrypted, with the essentials. Include the order of restoration and contacts for every vendor.

Bonus checks

  • Is the backup retention long enough to go back before an infection began? Attackers sometimes sit in networks for a while, so very short retention can leave only compromised copies.
  • Do field laptops and tablets have any backup, or does everything depend on cloud sync?
  • Who is authorized to approve a restore, and who can reach them at night?

A simple action plan

  1. List systems and data, then confirm coverage.
  2. Confirm one copy is protected from deletion.
  3. Name an owner for backup monitoring.
  4. Run a restore test and record the time.
  5. Compare restore time to business tolerance.
  6. Back up critical cloud data independently.
  7. Assemble the recovery binder.

You can complete the first four in a few days, and they close most of the exposure.

Where we fit

Ironfield Cyber helps contractors and energy companies design backup and recovery that works under pressure, then proves it with restore tests. If you would like to find out which of these gaps apply to you, we can run a short backup review and give you a prioritized list.