A Backup You Have Never Restored Is Only a Promise

Professionals | Business | Organizations
Written By Ashley Karr

Organizations do not know whether a backup works until someone retrieves the information, opens it and confirms that it is complete.

Many organizations can confidently say that backups are running.

Far fewer can say when they last restored information from those backups.

A dashboard may display a green checkmark. An automated email may report that the backup completed successfully. Files may appear inside the expected storage location.

Those signals are useful, but they do not prove that the organization can recover its information after accidental deletion, hardware failure, ransomware, account loss, or another disruption.

A backup is tested through restoration.

If You Read Only One Thing

A backup is not proven by the message saying it completed. It is proven when authorized people can restore usable information within the time the organization needs it.

Your Action Steps

  1. Identify the organization’s most critical information.

  2. Name the primary person responsible for backups.

  3. Name an authorized backup person.

  4. Select a small, representative group of files.

  5. Restore those files to a separate testing location.

  6. Open and inspect the restored information.

  7. Confirm that permissions, versions, and dates are correct.

  8. Document the test and any failures.

  9. Correct the problems.

  10. Schedule the next restoration test.

Why a Backup Can Fail Quietly

A backup process may appear successful while the resulting information is:

  • Incomplete

  • Corrupted

  • Outdated

  • Encrypted without an available key

  • Stored under an inaccessible account

  • Missing important folders

  • Connected to the same compromised environment

  • Owned by a former employee

  • Dependent on software the organization no longer uses

  • Available too slowly for operational needs

The organization may not discover the problem until recovery becomes urgent.

Synchronization Is Not Necessarily an Independent Backup

Synchronization services are excellent for making current information available across devices and collaborators.

However, synchronization can also carry changes across the connected system.

If a file is:

  • Deleted

  • Overwritten

  • Corrupted

  • Encrypted by malware

  • Changed accidentally

that change may synchronize.

Version history, recycle bins, and provider restoration features may help, but they can have time limits and service-specific restrictions. For example, Microsoft says permanently deleted OneDrive files cannot be recovered after they leave the Recycle Bin. Microsoft’s OneDrive restoration guidance.

An independent backup should provide a separate recovery path.

Decide What Must Be Recoverable

Not every file carries equal importance.

Begin by identifying information the organization needs to:

  • Serve customers or constituents

  • Receive and make payments

  • Meet legal or contractual obligations

  • Continue essential operations

  • Contact staff, clients, and vendors

  • Restore systems

  • Prove ownership or authorization

  • Maintain institutional knowledge

  • Protect the people it serves

The Federal Trade Commission recommends that businesses maintain inventories of hardware, software, data, and services. FTC cybersecurity guidance for small businesses.

A backup plan built without an inventory can protect large quantities of low-value material while overlooking one critical database or account.

Assign Responsibility

Every backup process should have:

  • A primary owner

  • An authorized backup owner

  • Clear instructions

  • A review schedule

  • A restoration process

  • A recovery path if the primary account owner is unavailable

Avoid allowing one employee, contractor, founder, or technology provider to be the only person who understands the system.

Document:

  • Which systems are backed up

  • How often backups occur

  • Where copies are maintained

  • Who receives failure notifications

  • Where encryption keys are secured

  • How restoration is initiated

  • Who must authorize a full recovery

Conduct a Small Restoration Test

A restoration test does not have to begin with a dramatic simulation.

Select representative information, such as:

  • One ordinary working document

  • One folder containing several file types

  • One older version of a changed file

  • One critical record from an independent backup location

Restore the information into a separate testing location. Do not overwrite the working copy.

Then verify:

  • Does the file open?

  • Is the content complete?

  • Is it the expected version?

  • Are the dates and names intact?

  • Can the correct people access it?

  • Can unauthorized people access it?

  • Does specialized software still read it?

  • Is the restoration process documented clearly enough for another person?

A successful download that produces an unreadable file is not a successful restoration.

Test the Credentials and Keys

The data may be intact while the recovery process remains unusable.

Confirm that the organization can locate and use:

  • Backup-account credentials

  • Multifactor-authentication methods

  • Encryption keys

  • Recovery codes

  • Administrative access

  • Vendor contact information

  • Required software licenses

  • Device or storage instructions

Do not place all these elements in an unsecured document. The organization needs a protected access process that more than one authorized person understands.

Consider the 3-2-1 Guideline

CISA recommends the 3-2-1 backup guideline:

  • Three copies of important information

  • Two different types of storage

  • One copy maintained off-site

The appropriate implementation will depend on the organization’s systems, obligations, resources, and risks. The principle is to prevent one failure from destroying every copy.

CISA also recommends testing backups regularly. CISA’s business-backup guidance.

Define How Quickly Recovery Must Happen

An organization may be able to recover its information eventually and still experience a serious operational failure.

Ask:

  • How long could we operate without this information?

  • How much recent work could we afford to lose?

  • Which functions must return first?

  • Who decides when restoration begins?

  • How will staff and customers receive updates?

A one-day restoration may be acceptable for archived photographs and unacceptable for a system that controls daily payments or appointments.

Record the Test

Document:

  • Test date

  • Systems tested

  • Files restored

  • Backup source

  • Person conducting the test

  • Time required

  • Problems discovered

  • Corrective action

  • Date of the next test

A failed test is useful if it exposes a weakness before an emergency.

The goal is not to produce a perfect report. It is to convert assumed resilience into demonstrated resilience.

Resources Outside Haven Smith & Company

Haven Smith & Company Resources

Ashley Karr
Previous

Build a Family Digital Emergency File Before You Need It
Next

Your Executor Needs a Digital Map—Not a Password List