Some companies have terabytes of backups and no certainty that they could recover their own operation. The file exists. Autonomy does not always come with it.

TL;DR

Today, during an infrastructure outage, a recent backup of our automation workflows did not restore the environment or fix the cause of the failure. It did something equally important: it let us understand how a service behaved and plan its migration to a simpler architecture. The copy restored our ability to decide. A recoverable backup is not merely retention; it preserves enough data, logic, configuration, dependencies, and context to restore, rebuild, migrate, or simplify an operation. If nobody has tested recovery, the backup is still an optimistic hypothesis taking up storage.

Today I had to answer a question many companies postpone until something fails:

If the place where this service runs disappears from the conversation, do we still know what it does?

Part of the infrastructure was unavailable. I will not turn that into a season of technical suspense. Downtime already consumes enough energy without a soundtrack.

The important detail is elsewhere.

We had a recent backup of the automation workflows—the files describing the steps, decisions, and integrations executed by the service. That copy did not fix the network. It did not bring the entire environment back. It did not press a magic “fix production” button, because unfortunately that button is still missing from the catalog.

But it let us inspect how the operation behaved.

We could identify what the service received, how it processed information, which parts it depended on, and what actually needed to survive. From there, we could plan a migration to a simpler architecture.

The backup did not return the infrastructure.

It returned context. And context returned choice.

Storing a copy is not the same as being able to recover

Backup often enters the conversation as an administrative verb:

— Did you back it up?

— Yes.

Done. Everyone’s conscience relaxes, the task gets a green checkmark, and a file begins a long career in storage that perhaps nobody will ever open again.

It takes up space, attends the audit, and is never disturbed by the vulgarity of an actual restoration.

But there are important differences between four capabilities:

1. Store: keep a separate copy of the current state.
2. Restore: return data or components to a compatible environment.
3. Rebuild: reassemble the complete service, including configuration, dependencies, and operational order.
4. Migrate: move the required capability to another environment, accepting the adaptations that come with the move.

Not every copy has to satisfy all four goals. A historical archive may exist only for retention. A database backup may be designed to restore into the same technology. An automation export may preserve the logic while still depending on plugins—add-on modules that extend the source tool—and external services before it can run again.

That specialization is not the problem.

The problem is calling everything a “backup” as if the word alone guaranteed a return.

What must survive does not always fit in one file

If we think only about data, we can recover every row in a table and still fail to recover the operation.

The service may also depend on:

• workflows and code: the logic that turns an input into a result;
• configuration: variables, policies, queues, schedules, routes, and limits;
• dependencies: versions of libraries, plugins, images, and supporting services;
• external state: files, objects, identifiers, and integrations kept outside the main database;
• governed secrets: credentials and keys held through their own secure custody, rather than dumped as plain text into the same package;
• operational context: the order of recovery, the responsible people, the assumptions, and an explanation of what each component does.

This is also why version control and backup are not synonyms. A repository’s history helps recover code and versioned configuration. It does not automatically preserve databases, external files, credentials, service state, or everything somebody configured manually in a dashboard.

Synchronization is not necessarily backup either. If deletion, corruption, or unwanted encryption is immediately replicated to the other side, you may have two perfectly synchronized copies of the same disaster.

The test begins when the copy has to work

The United States National Institute of Standards and Technology (NIST) quick-start guide for small and medium-sized businesses recommends regular backups, testing them, and assessing data integrity before restoration. In the same guide, recovery includes assigned responsibilities, priorities, formal processes, and documentation of the components and services a business relies on.

That matters because restoration is not merely a read operation.

It needs to answer:

• Does the file open?
• Is the copy intact?
• Can the current version of the tool import it?
• Do its dependencies still exist?
• Are the required credentials available through a secure path?
• Does the person performing recovery know the order of operations?
• Does the service actually come back, or does it merely produce a very optimistic green screen?

The NIST contingency planning guide is old—the version consulted was updated in November 2010; the initial May record was withdrawn and superseded by that update—but it records an operational test that remains useful: recovering a system on an alternate platform from backup media. The source does not prove that every application is portable or that migration is always simple. It supports a more modest criterion: testing under conditions close to reality reveals deficiencies that the mere existence of a copy cannot show.

The United States Cybersecurity and Infrastructure Security Agency (CISA) ransomware guide recommends offline copies—disconnected from or inaccessible to the production environment—encryption for critical data, and regular availability and integrity tests. Ransomware is an attack that uses malicious software to block access to data or systems, commonly to demand payment. The guide’s context is defense and recovery from those attacks. The broader principle used here is limited: if the same problem can reach production and every copy at once, redundancy may have become decoration.

The right frequency starts with two less comfortable questions

“We back up every day” sounds like a policy.

Sometimes it is merely a frequency selected because twenty-four hours fits neatly into a sentence.

Two questions should come first:

1. How much work or data can the operation afford to lose?
2. How long can it afford to remain unavailable?

In continuity planning, these are usually called the recovery point objective and recovery time objective. The names are technical; the decision belongs to the business.

A weekly schedule may be enough for an archive that changes rarely. It can be disastrous for orders arriving every minute. A backup every five minutes may sound excellent and still fail alongside production if it lives in the same environment, under the same credentials, and is exposed to the same deletion.

More copies do not fix a recovery architecture nobody understands.

Backup is also migration capacity

I prefer open-source code, private infrastructure, and operational sovereignty when those choices increase control, auditability, and freedom. That does not mean rejecting managed services, cloud platforms, or external providers.

Managed services can reduce labor, improve availability, and let a small team use capabilities that would be expensive to operate alone.

The problem begins when convenience becomes an invisible dependency.

If a system can only be understood inside its current dashboard, exports a file nobody has tested, and depends on settings that live only in the memory of the person who built it, the company may pay for the service without owning a real way out.

In today’s case, the workflow backup let us separate two things that had appeared glued together: the capability that needed to survive and the environment in which it happened to be running.

That separation opened three paths:

• restore the previous design;
• rebuild it in another environment;
• use the recovered understanding to simplify the architecture.

The third path is often forgotten.

Recovery does not have to mean eternally rebuilding every old decision. Sometimes the backup preserves the knowledge required to avoid rebuilding the same complexity.

A checklist for automation, data, and configuration backups

There is no universal policy. Volume, criticality, cost, regulation, privacy, and tolerance for downtime change the design. But a few questions quickly expose where there is only a feeling of safety.

1. Inventory what keeps the capability alive

List data, workflows, code, configuration, files, dependencies, external services, and operational knowledge. Start with what would interrupt the operation, not what is easiest to copy.

2. Define the purpose of each copy

Is it for retention, fast restoration, complete reconstruction, auditing, or migration? One strategy may serve several purposes, but that has to be demonstrated.

3. Preserve format, version, and dependencies

An export without the tool version, the plugins in use, and the expected integrations may become a technical souvenir: proof that an operation once existed, but not much help in making it run.

4. Separate secrets from the common package

Document which credentials are required and where they are held. Do not solve recovery by creating one file that hands data, configuration, and every key to whoever manages to copy it.

5. Keep at least one copy beyond the reach of the same failure

“Outside” depends on the risk: another account, region, infrastructure, isolated medium, or mechanism with independent credentials and lifecycle. The goal is to stop a single action, failure, or compromise from destroying both production and the way back.

6. Test restoration in an isolated environment

Open the file. Import it. Recreate dependencies. Check integrity. Run a controlled workflow. Record what failed and correct the procedure while there is still time to think.

7. Test the exit too

When a capability is critical, try rebuilding part of it in a clean or alternate environment. Not to change providers every Tuesday, but to discover what the company actually controls.

8. Record the date, result, and responsible person

“Backup tested” should say who tested it, when, at what scope, and with what result. A test from five years ago proves that something worked five years ago.

9. Automate without abolishing verification

Scheduled copies reduce forgetfulness. Monitoring failures, integrity, age, and available capacity stops automation from producing silence at scale. Periodically, a person still needs to confirm that the complete path makes sense.

10. Dispose of backups through governed rules

Infinite retention increases cost, exposure, and confusion. Define how long each class of copy must exist, what prevents its deletion, and how disposal will be verified.

The exit question should exist at the beginning

When an architecture is designed, almost all attention goes to the entrance:

• How do we deploy it?
• How do we import the data?
• How do we integrate it?
• How do we put it into production?

I want to add one more question:

How do we leave with what matters?

Not because every system must be ready to move tomorrow. Not because providers are enemies. Not because infrastructure you operate yourself is automatically sovereign or secure.

But because a governable operation needs to know its path back.

This is one of the questions I bring to i-9.ai: not only how to make a system work, but how to make it understandable, recoverable, and adaptable when its context changes.

If your company has backups but does not know what it could truly rebuild from them, get in touch. We can start with the operation that cannot disappear and the latest test that should prove the way back.

Before that, it is worth answering honestly:

• When was the last complete restoration that ended with the service actually working?
• Does recovery depend on one person still remembering everything?
• Does the copy preserve only data, or also the ability to understand and rebuild the system?
• If the current environment becomes unavailable, is there a known exit?
• Would the backup let you repeat the architecture—and also decide not to repeat it?

The best backup is not the one that promises to return a system to exactly where it was.

It is the one that gives me the freedom to decide whether I still want to go back there.

Continue reading

• I was born in 1986 and survived at least nine ends of the world: where the idea of backup as both practice and preservation of options began.
• Your company does not need to discover where to put AI: a map for turning bottlenecks into governed systems without starting from a tool.
• A hypothesis does not become a fact because AI repeated it: why context and decisions also need to survive outside one person’s memory or one conversation.

Learn more

• Business continuity planning: an encyclopedic overview of preparation for maintaining or recovering critical activities after a disruption. It helps with the vocabulary but does not replace a standard or a plan adapted to the business.
• Version control with Git: an introduction to recording and recovering file versions; version control is part of the strategy, not a backup for every other state in the operation.

References and limits of use

This article starts from a real operational situation, described abstractly so it does not expose infrastructure, providers, credentials, data, or people. The backup made it possible to inspect workflows and plan a migration; there was no comparative experiment and no proof that the future architecture will be better before it is validated.

• NIST, Cybersecurity Framework 2.0: Small Business Quick-Start Guide (SP 1300, 2024): recommends regular, tested backups, integrity assessment before restoration, assigned responsibilities, and formal recovery processes. It is voluntary risk-management guidance and does not define a universal architecture.
• NIST, Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1, 2010 update): describes recovery tests, including recovery on an alternate platform. The initial May record was withdrawn and superseded by the November update linked here. It remains an older publication originally aimed at United States federal systems; I use only its historical operational principle of testing procedures and components under representative conditions, not as current architectural guidance.
• CISA, #StopRansomware Guide (accessed August 30, 2026): recommends offline, encrypted backups of critical data and regular availability and integrity tests. The guide addresses ransomware; it does not prove that isolation, encryption, or backup eliminates other continuity risks.