Sovereign Disaster Recovery for European SMEs: Building a Truly Open Source Alternative

The announcement of Europe’s first Sovereign Disaster Recovery Pack by Cubbit, SUSE, Elemento Cloud and StorPool Storage at the European Data Summit in Berlin marks an important milestone. It validates what many of us in the European infrastructure space have been saying for years: organisations need a concrete, deployable answer to the question of what happens when a critical foreign cloud dependency puts services or data at risk.

The initiative deserves credit for framing disaster recovery as the natural entry point for a broader sovereign cloud strategy. Rather than asking enterprises to rip and replace their entire stack overnight, it offers a pragmatic first step: build and validate a sovereign recovery environment, then progressively extend it. That is the right approach.

But the announcement also raises a deeper question: what does “sovereign” actually mean when you look beneath the marketing? And can European SMEs achieve genuine sovereignty, the kind where every layer of the stack is inspectable, replaceable and free from single-vendor control, using proven open source components that are already available today?

At Innoframe, we believe the answer is yes. Here is how.

Sovereign Disaster Recovery: Bundled Stack vs Open Source Stack

What “Sovereign” Should Mean

The word “sovereign” has become a popular label in European cloud marketing. Gartner forecasts worldwide sovereign cloud IaaS spending to reach $80 billion in 2026, a 35.6% increase from 2025. Europe is projected to record 83% growth in sovereign cloud spending in 2026 and is forecast to surpass North America in total sovereign cloud IaaS spending by 2027. With numbers like that, every vendor wants the label.

But sovereignty is not just about where the company is headquartered or where the data centre is located. True digital sovereignty requires three things:

1. Transparency: you can inspect the source code of every critical component in your stack.
2. Replaceability: you can swap out any single vendor or component without rebuilding from scratch.
3. Independence: no single entity, corporate or governmental, can unilaterally restrict your access to the tools you depend on.

These criteria matter because European enterprises have been burned before. Canonical restricted LXD’s community governance and moved it under a corporate CLA, prompting the Linux Containers community to fork it as Incus. The HashiCorp/Terraform licence change forced the community to fork OpenTofu. Redis moved to SSPL, leading to the Valkey fork. Elasticsearch’s licence change spawned OpenSearch. Each time, organisations that depended on proprietary layers, even within an “open source” product, had to scramble.

A sovereign DR stack should be built to survive not just a data centre failure, but a vendor failure, a licence change, or a geopolitical shift that suddenly makes a supplier unavailable.

The Operating System: Why the Foundation Matters

Any sovereign stack starts with the operating system. It is the layer everything else runs on and it is the layer that is hardest to replace in a crisis.

The Sovereign DR Pack from Cubbit, SUSE, Elemento Cloud, and StorPool uses SUSE Linux Enterprise and in Elemento’s case, RHEL-compatible distributions like AlmaLinux 9 or Rocky Linux 9. These are all capable enterprise distributions with strong track records.

However, from a sovereignty perspective, there is an important distinction to consider. AlmaLinux and Rocky Linux are downstream rebuilds of Red Hat Enterprise Linux. Red Hat is a wholly-owned subsidiary of IBM, a US corporation. In June 2023, Red Hat restricted public access to RHEL source code, forcing both AlmaLinux and Rocky Linux to find alternative methods to continue their distributions. AlmaLinux shifted from bug-for-bug RHEL compatibility to ABI compatibility using CentOS Stream sources. Rocky Linux maintained compatibility through creative source acquisition methods.

This episode demonstrated that a single US corporation can unilaterally change the rules of access to the source code that these distributions depend on. It happened once; it can happen again.

There is also a jurisdictional dimension. Under the US CLOUD Act, US authorities can compel American companies to provide access to data and systems under their control, regardless of where that data is stored. While this applies primarily to services and data rather than to OS binaries, the underlying principle matters for organisations building a sovereignty strategy: when your most fundamental infrastructure layer depends on the goodwill of a US corporation, your sovereignty claim has a gap in its foundation.

Debian, by contrast, is governed by the Debian Project, an international volunteer community operating under the Debian Free Software Guidelines. There is no corporate parent. No single company can restrict source access, change licensing, or be compelled by any government to alter the distribution. Debian maintainers and infrastructure are distributed across dozens of countries. The project’s decision-making happens through an elected project leader and developer votes, not a corporate board.

This is not a criticism of SUSE, AlmaLinux, or Rocky Linux as technical choices. They are excellent distributions. But when the conversation is specifically about sovereignty, the governance model of your operating system matters as much as its package manager.

Compute and Container Layer: Incus 7.0 LTS

The Sovereign DR Pack uses Elemento’s AtomOS as its hypervisor layer. AtomOS is built on standard Linux KVM/QEMU, using upstream, unmodified kernel virtualization. The proprietary value that Elemento adds sits in the orchestration and management layer: Electros (the dashboard and CLI), the C4 clustering protocol and the Atomosphere multi-cloud API.

This is a common pattern in enterprise software known as “open core”: the foundation is open source, but the management and orchestration layers where the real operational dependency lives are proprietary. The challenge with open core in a sovereignty context is that if the vendor changes terms, raises prices, or disappears, you keep the foundation (KVM disk images) but lose the tooling that makes your infrastructure manageable. You would need to rebuild your entire control plane.

Incus 7.0 LTS, released in May 2026 by the Linux Containers project, takes a different approach. The entire system, from the CLI and REST API to clustering, storage driver integration, image management and live migration, is open source under the Apache 2.0 licence. It manages both system containers (lightweight, sharing the host kernel) and full virtual machines (KVM/QEMU) through the same unified interface.

For disaster recovery, Incus offers several native capabilities that are directly relevant:

Cross-host container and VM replication. The incus copy --refresh command synchronises a container or VM to a standby host, transferring only changed data. This provides warm standby capability without any additional software.

Snapshot-based recovery. Incus integrates directly with its storage backends (Btrfs, ZFS, Ceph, LINSTOR) to create instant copy-on-write snapshots. Hourly snapshots with 24-hour retention provide rapid rollback for accidental changes or corruption.

Golden image deployment. You can build a fully configured container or VM, publish it as an Incus image and launch new instances from it in seconds. In a DR scenario, this means recovery is not “reinstall and reconfigure” but “launch from image, restore data, done.”

Clustering. Incus nodes can form a cluster with shared database state, enabling workload placement across multiple physical hosts with automatic failover.

Because all of this is open source, any engineer can inspect the clustering protocol, any consultancy can take over management and the project can be forked if the original maintainers ever step back. That is replaceability in practice.

Storage: Btrfs/ZFS Today, LINSTOR/DRBD When You Scale

The Sovereign DR Pack uses StorPool for its software-defined storage layer. StorPool is a capable, high-performance block storage solution with a solid reputation. Both StorPool and LINBIT (the company behind the open source alternative LINSTOR) are European companies, which is positive from a sovereignty standpoint.

The key difference is licensing. StorPool is proprietary. If StorPool changes its pricing model or licensing terms, organisations using it have no fallback within the same technology. They would need to migrate to a different storage platform entirely. As LINBIT themselves note in their cloud-native SDS platform comparison: while StorPool and LINBIT provide similar offerings and support many different platforms, LINBIT SDS is open source, fully transparent and without vendor lock-in, whereas StorPool is proprietary software. Both are strong products; the distinction matters when sovereignty and long-term independence are the deciding criteria.

For the majority of European SME deployments, the storage question starts simpler than distributed block storage. At Innoframe, our production infrastructure runs on Btrfs and ZFS, both proven, open source filesystems with capabilities that cover most SME requirements out of the box:

• Copy-on-write snapshots: instant, space-efficient snapshots for hourly rollback and pre-upgrade safety nets.
• Data integrity: built-in checksumming detects silent corruption (bitrot) before it reaches your backups.
• Compression: transparent compression reduces storage costs without application changes.
• Efficient replication: both Btrfs and ZFS provide native send/receive functionality, allowing incremental transfers of only changed data to a standby host at a different location. This provides cross-site replication without additional software.

This is not a theoretical stack. We run Btrfs on servers at Hetzner, Netcup and OVH in production, with hourly snapshots, daily incremental replication to geographically separated hosts and Kopia backups to immutable S3 storage. The combination is battle-tested and covers the disaster recovery needs of single-server and small-cluster deployments that are typical for SMEs.

When a deployment grows beyond what a single server or simple replication can handle, there is a clear open source upgrade path: LINSTOR with DRBD. Developed by LINBIT (headquartered in Vienna, Austria), LINSTOR is open source under the GPLv3 licence and manages DRBD-replicated block storage volumes across a cluster of nodes. DRBD itself is a kernel module that has been actively developed for over two decades and is part of the mainline Linux kernel. Because replication happens in kernel space rather than user space, DRBD delivers low-overhead, high-performance data replication.

With Incus 7.0 LTS, LINSTOR is now a natively supported storage driver, alongside Btrfs, ZFS, Ceph, and LVM. This means organisations that outgrow single-server Btrfs or ZFS can create an Incus storage pool backed by LINSTOR and get synchronous replication across multiple nodes, automatic failover and the ability to separate compute and storage nodes. The underlying storage still uses LVM or ZFS, so the transition builds on familiar technology rather than replacing it.

Full transparency: we have hands-on experience with DRBD from earlier in our career and it was not always a smooth ride. In those earlier versions, split-brain scenarios and data loss were real operational risks that made us step away from it. DRBD has matured significantly since then; version 9 introduced multi-node replication (beyond the original two-node limit), improved quorum handling and better automatic recovery from network partitions. The fact that the Incus community contributed a native LINSTOR driver for the 7.0 LTS release and that LINBIT (a European company headquartered in Vienna, Austria) actively supported its inclusion, signals that the technology has reached a level of stability and integration maturity that warrants a fresh evaluation.

We are planning to test LINSTOR/DRBD with Incus 7.0 in our lab environment before recommending it for client deployments. We will document our findings, including any rough edges, because that is how trust is built: through honest, experience-based reporting rather than marketing claims. LINBIT also offers commercial support subscriptions for organisations that need SLA-backed support, providing the same “open source software, commercial support” model that has proven sustainable across the industry.

Backup and Immutable Recovery: Kopia + S3 Object Storage

The Sovereign DR Pack announcement does not detail its backup and recovery mechanism. This is a significant gap, because disaster recovery without defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective) numbers is incomplete.

At Innoframe, we use Kopia, an open source backup tool that supports S3-compatible object storage with COMPLIANCE mode object locking. This provides ransomware-proof, immutable backups that cannot be deleted or modified, not even by an attacker who has gained root access to the production server.

We have validated this in production with Hetzner and Scaleway Object Storage, confirming that Kopia’s point-in-time recovery works correctly with COMPLIANCE mode retention. The recovery workflow is proven: delete a snapshot (simulating a ransomware attack), reconnect the repository with a point-in-time flag and the “deleted” snapshot reappears because the underlying objects are protected by object lock.

This is where Cubbit’s DS3 Cloud can play a valuable role in an open source stack. Cubbit’s geo-distributed model, where data is encrypted, fragmented and replicated across multiple European locations, adds genuine value for the backup target layer. Because Cubbit is S3-compatible, it integrates with Kopia (and with any other S3-compatible backup tool) through a standard API. The critical point is that S3 compatibility means the object storage backend is swappable: you can use Cubbit today and switch to Scaleway, Hetzner Object Storage, or even self-hosted Garage or MinIO tomorrow, without changing your backup tooling or procedures.

Using Cubbit specifically for the immutable backup target, rather than as the foundation of your entire stack, gives you the benefit of their geo-distribution technology where it adds the most value, while keeping the overall architecture vendor-independent.

A concrete DR architecture using this approach:

With this architecture, concrete RPO and RTO numbers are achievable:

• RPO: 1 hour for most workloads (hourly snapshots), near-zero for replicated containers (continuous refresh).
• RTO: Under 5 minutes for container recovery from golden image + data restore. Under 15 minutes for full VM recovery from warm standby.

Security: CrowdSec, nftables and Defence in Depth

A sovereign DR stack is only as good as its ability to resist the attacks that make disaster recovery necessary in the first place. The security layer should be open source and community-driven, applying the same sovereignty principles as the rest of the stack.

CrowdSec is an open source security engine that analyses logs, detects attacks and shares threat intelligence across its community. Combined with nftables (the modern Linux firewall framework that replaces iptables) and integrated with Nginx or Caddy as the reverse proxy, it provides real-time protection against brute force attacks, credential stuffing, vulnerability scanning and application-layer exploits.

Every component in this security layer can be inspected, audited, and replaced independently.

The Sovereignty Test: What Happens When a Vendor Disappears?

The ultimate test for any “sovereign” infrastructure is simple: what happens if one of your vendors disappears tomorrow?

With a bundled stack that combines four vendors’ proprietary technologies, the failure of any single vendor creates a gap that may require significant effort to fill. If the orchestration vendor exits, you need a new control plane. If the storage vendor exits, you need to migrate all block storage to a new platform. The more tightly integrated the bundle, the harder each replacement becomes.

With an open source stack, the answer is different. If the Incus project stopped development tomorrow, you could fork it (Apache 2.0), switch to plain LXC, or migrate VMs to any other KVM manager. If LINBIT stopped developing LINSTOR, the GPLv3 code remains available for the community to maintain and DRBD is in the mainline kernel. If Kopia stopped development, your backup repositories remain accessible (they are standard files on S3 storage) and you can migrate to restic, BorgBackup, or any other tool that reads from the same storage.

This is not a theoretical concern. European enterprises have watched CentOS be discontinued, Terraform change its licence, and Redis move to SSPL. Every time, organisations that built on open source foundations with standard interfaces recovered faster than those locked into proprietary ecosystems.

Who Is This For?

This approach is particularly well suited for European SMEs and mid-market organisations that:

• Need to comply with NIS2, DORA, or GDPR requirements around infrastructure control and data sovereignty.
• Want to reduce dependency on US cloud providers without taking on the complexity of managing dozens of unfamiliar tools.
• Are looking for a pragmatic, step-by-step path toward sovereignty, starting with disaster recovery.
• Value the ability to switch consultants or service providers without losing access to their infrastructure.

Innoframe specialises in assembling, deploying and managing these open source components as a coherent, production-ready stack on European infrastructure providers like Hetzner, Netcup, Scaleway and OVH. Our clients own their servers, their containers, their DNS zones, their TLS certificates, and their backup repositories. If Innoframe were to disappear, another engineer could pick up exactly where we left off, using the same open source tools, with full access to every configuration file and deployment script.

That is what sovereign infrastructure looks like in practice.

Frequently Asked Questions