Recovery for a Dream

How is your infrastructure actually built?

With modern pipelines and infrastructure as code?

Or… not really?

If your DR plan depends on backups but your infrastructure was built with a mouse, you are not planning for a restore. You are preparing for a journey through your memory.

Think about your environment:

• Do you know what you have?
• Can you actually restore it?
• Where is the environment definition? (that would be the IaC code, or something similar).

It’s more often to find out that there’s actually none of that. For some reason, after search people can find the first orders or emails about the infra. But that is where the trail ends.

Even that is bad. But think about the situation where you would need to move from that cloud region to another, or change the cloud altogether.

Restore is not the same as rebuild

Then your recovery stops being restore this one thing and becomes rebuild the environment somewhere, it just is not enough that the people you work with remembers how / why you build that one application. You need to think about the complete cloud estate. The whole infra.

And if you find yourself in a situation where the answer is:

“Well… everything was created mostly using the portal. You know how it goes.”

Your recovery plan has already taken a hard turn into archaeology.

A running environment does not mean a reproducible environment.

An environment can be stable for years, have backups, and be well monitored — and still be impossible to rebuild from scratch.

Reproducibility isn’t about whether the environment exists today.

It’s about whether you can build it again without depending on memory and sheer luck.

At this point it should be clear that the infrastructure as code is not a fancy DevOps slogan but actual part of your environments recovery capability.

If the platform is unavailable, compromised, or simply no longer where you want it to be, the question is no longer just:

“Where is the data?”

It becomes:

Can we reconstruct the place where that data becomes useful?

If it only lives in the portal, it only sort of exists

Many organizations don’t want to think about this. The topic is acknowledged, then quietly postponed into the board’s “yes, yes, maybe later” compartment.

But when a cloud environment has been built over years through the portal — incremental fixes, copied settings, last‑minute exceptions — it may be perfectly maintainable, and still practically impossible to rebuild.

Maintenance is not the same as reconstruction.

If the original environment is gone — or if you deliberately want to leave it behind — you need explicit definitions for things like:

• network architecture

• identity and access model

• compute topology

• data storage design

• governance

• secrets management

• and all the platform and operational dependencies that exist only because “they’ve always been there”

Without these, recovery stops being a technical exercise and turns into a nightmare.

This is where IaC tools become practical

Below are a couple of tools that actually can help you.

Even if you do not have any code for your environment, you don’t have to rewrite everything from zero.

Tools like Azure Export for Terraform or Azure‑native **Bicep **tooling can export large parts of an existing environment into IaC.

This won’t make your environment “beautiful” overnight, but it moves it out of mythology and into version control.

A sensible way to take control

If I were doing this in a real environment, I would not try to bring the entire estate under IaC in one glorious transformation project.

I would start with the things that actually matter when recovery becomes real:

• the core network
• identity‑dependent components
• storage and data platforms
• critical workloads
• shared services that everything else depends on

I would bring those under code gradually.

This makes a phased approach far more realistic than the usual fantasy of “we’ll just rebuild everything properly later.”

Later is where bad recovery plans go to hide.

Summary

Backups protect your data. Infrastructure as code protects your ability to recover.

An environment built only through the portal may run for years — and still be impossible to rebuild.

Without IaC, disaster recovery depends on memory, undocumented decisions, and assumptions about a platform that may no longer be available.

IaC does not magically fix architecture, but it turns recovery from archaeology into an engineering problem.

Without code, you’re guessing. With code, recovery might be difficult — but possible.

Archaeology is not a recovery strategy.