The Uncalculated Risk: Why "Rebuild It" Is No Longer a Strategy

By the IssTech Team

In this week’s issue, we look at the uncomfortable truth about data protection in a cloud-native world. We sat down with Christian Petersson, founder of IssTech, to understand why a veteran who built global disaster recovery (DR) solutions for Fortune 500 companies is so worried about modern Kubernetes environments.

The Evolution of the "No Backup" Excuse

If you work in DevOps or SRE, you’ve heard the mantra: "We don't need backups. We are stateless. If it breaks, our pipeline just rebuilds it."

Christian Petersson has heard this before. In fact, he’s been hearing versions of it for 25 years. Christian’s history in the industry runs deep; he was involved in building the prototype for the first Bare Machine Recovery for Windows NT 3.51. In collaboration with two major Swedish banks and IBM, he helped create a generic, standardized solution capable of recovering central and branch office servers globally—precisely because automated rebuilds weren't reliable enough.

The driving force behind this innovation was to achieve staff and knowledge independence—ensuring that disaster recovery relied on a robust system rather than the memory of specific individuals.

"The technology changes, but the excuses stay the same," Christian says. "Decades ago, people said they didn't need disaster recovery because they had fully automated network re-installation tools. They thought they could just rebuild the servers with a single click and then restore the data."

But the story always ends the same way: You eventually need a dedicated DR solution. Relying solely on "rebuilding" inevitably falls short when a critical component isn't backed up, turning a "quick fix" into a recovery process that takes weeks.

Why "Rebuilding" Fails

"Rebuilding" often relies on tribal knowledge—specific configurations stored in the head of an employee who might leave the company. It also fails because of threats you couldn't calculate when you originally designed the system. Often, companies find themselves in scenarios where actual recovery times increase month by month, even as Service Level Agreements (SLAs) demand faster turnarounds.

The Threat You Can't See Coming

The core of IssTech’s philosophy is that you cannot architect a defense against a threat that doesn't exist yet.

"Take ransomware," Christian explains. "Between 2000 and 2010, it wasn't a major corporate threat. The primary risks then were natural disasters—hurricanes, fires—and Windows 'blue screens.' The first real waves of ransomware didn't hit until around 2014. If you built your DR strategy in 2010 based only on known risks, you were defenseless four years later."

We are seeing history repeat itself with SaaS. When Microsoft 365 launched, many IT leaders assumed Microsoft protected everything. It took years for the industry to internalize the Shared Responsibility Model: Microsoft protects the infrastructure, but you are responsible for your own data.

Today, we face geopolitical risks. Ten years ago, the idea that a US-based cloud provider could become a business risk for a European company due to political shifts was considered laughable. Today, for a European CIO, data sovereignty is a cause of sleepless nights.

The Kubernetes Blind Spot

We now have a brilliant generation of Cloud Engineers and SREs who have never racked a physical server. While the speed of Kubernetes is a double-edged sword—reducing "time-to-creativity" to minutes—it has also increased the potential for chaos.

Even in "stateless" environments, problems arise that code re-deployment cannot fix:

  • RPO and RTO Requirements: Sometimes "rebuilding" simply takes too long for the business to survive.

  • The "Creative" Employee: An engineer bypasses standard policy to implement a quick workaround. This new tool might store persistent data in your cluster, but because it was a "temporary" fix waiting for internal administration to catch up, it was committed to the repo. When the system breaks, the pipeline can implement the fix, but not restore the data. “It was only a temporary” fix. 

DORA and NIS2: The Wisdom of the Past

It is easy to view new EU regulations like DORA and NIS2 as bureaucratic hurdles designed to slow down innovation. Christian sees them differently.

"These regulations are not the villain," Christian argues. "They are a guiding hand." For him, these frameworks are essentially a letter from the previous generation to the next.

"We—the generation born before 2000—already made these mistakes. We suffered the data losses, the extended outages, and the security breaches. DORA and NIS2 are simply those hard-learned lessons codified into law. They exist to help the next generation avoid the same stones we stumbled over. These regulations will continue to evolve as they are updated to address new, upcoming, and unknown disasters."

The Future: AI Agents and Shadow IT

The newest threat? AI. We are entering an era where AI agents work autonomously or after hours to help engineers be more creative.

"How do you know your AI agent hasn't created a dependency or a function in your Kubernetes platform that you don't know about?" Christian asks. "If an AI builds a bridge between services and that bridge collapses, how do you rebuild it if you didn't write the code?"

We saw the fragility of modern pipelines during the first quarter of 2026, when a major GitHub outage brought many companies to a standstill. When you cannot reach your online repository, you cannot deploy or commit new code, leaving teams paralyzed until the service is restored.

The Bottom Line

IssTech isn't just about backup; it's about protecting against the "unknown unknowns." Whether it's a political shift, a new form of ransomware, or an AI agent that got too creative, the only safety net is a robust, independent data protection strategy.

Read more about securing your infrastructure at IssTech.io.


Next
Next

RTO: The Hidden Time Bomb in Modern Infrastructure