Introduction
Digital sovereignty is not a talking point anymore. It is a real technical requirement. Governments, telcos, and regulated enterprises are building sovereign clouds on OpenStack to keep data under their jurisdiction. But what about the backups?
If your sovereign cloud data protection solution uses a proprietary format, you have traded one lock-in for another. In this post, I will cover the sovereign cloud landscape, why OpenStack dominates it, and how Trilio’s open QCOW2 backup format keeps your data truly yours.
What Is Digital Sovereignty and Why Does It Matter?
Digital sovereignty means that an organization or nation retains full legal and operational control over its digital infrastructure and data. It is not just about where your data physically sits. It is about who has legal authority over it and who can be compelled to hand it over.
The regulatory pressure is real and growing. GDPR set the foundation in Europe. The Schrems II ruling invalidated the EU-US Privacy Shield. In 2025, DORA took effect for financial services. The EU Data Act prohibits unlawful third-country data access. NIS2 extends cybersecurity obligations across broad sectors.
Then there is the US CLOUD Act. It allows US courts to compel American companies to hand over data stored abroad. In 2025, Microsoft France’s general manager testified under oath that he cannot guarantee French data safety from US authorities. Google, Amazon, and Salesforce made similar admissions. Hyperscaler sovereign cloud offerings have structural legal limits.
This is why organizations are building their own clouds. The sovereign cloud market is projected to grow from $154.69 billion in 2025 to $823.91 billion by 2032. That is not a trend. That is a tectonic shift. And the platform these clouds are built on, overwhelmingly, is OpenStack.
The Sovereign Cloud Platform Landscape
OpenStack is the de facto foundation for sovereign clouds, and for good reason. It is open source. It is proven at massive scale. It runs on your hardware, in your data centers, under your jurisdiction. No phone-home to a hyperscaler. No dependency on a foreign legal entity.
But not all OpenStack is the same. Let me walk you through the four distributions and deployment methods that dominate the sovereign cloud conversation today.
Red Hat OpenStack Services on OpenShift (RHOSO) 18
RHOSO 18 represents Red Hat’s current-generation OpenStack, and it is a significant architectural evolution. The control plane runs as containerized operators on Red Hat OpenShift. The data plane consists of bare-metal compute node sets. This Kubernetes-native lifecycle brings modern operational patterns to OpenStack management.
What makes RHOSO 18 compelling for sovereign clouds is the enterprise backing. Red Hat has tested deployments up to 250 bare-metal nodes. Telcos like BT are running OpenStack-powered 5G across over 75% of the UK population. T-Mobile’s footprint covers around 6,000 bare-metal servers. When governments and carriers need OpenStack with long-term support, certifications, and a vendor standing behind it, RHOSO is often the choice.
The March 2025 feature release introduced the Workload Optimization Operator (based on upstream Watcher) for Day 2 operations, plus kernel live patching in tech preview — applying critical security patches without rebooting compute nodes. For sovereign cloud operators running sensitive workloads, that kind of operational maturity matters.
Canonical OpenStack
Canonical takes a different approach that appeals strongly to European sovereign cloud operators. Their OpenStack distribution deploys through MAAS (Metal As A Service) and Juju, with Charms providing the deployment intelligence. The newer Sunbeam architecture uses Kubernetes under the hood for the control plane while keeping operational simplicity front and center.
The cost model is attractive. The LTS commitment is exceptional: Canonical OpenStack 2024.1 is the first LTS release, with up to 12 years of full support. For sovereign cloud operators planning infrastructure lifecycles measured in decades, that predictability is valuable.
Sunbeam itself is an upstream OpenStack project hosted under the OpenInfra Foundation. It fully decouples OpenStack from the underlying operating system, making upgrades — traditionally the most painful OpenStack operation — substantially simpler. Canonical has a strong footprint in European sovereign clouds where regulatory compliance and open-source governance are non-negotiable requirements.
Mirantis OpenStack
Mirantis has evolved its strategy significantly. Their current offering, Mirantis OpenStack for Kubernetes (MOSK), runs OpenStack as containerized workloads on Kubernetes. MOSK 25.2, released in 2025, ships OpenStack 2025.1 “Epoxy” with Ceph 19.2 “Squid” for storage and expanded networking options across OVS, OpenSDN, and OVN.
Mirantis also released Rockoon in 2025, an open-source Kubernetes operator that acts as the OpenStack controller. It translates resource changes into Helm values and applies them to the underlying cluster. This is a genuinely interesting approach for organizations that want Kubernetes-native operations for both their container and VM workloads on unified infrastructure.
The managed services angle is where Mirantis differentiates. Through Mirantis Container Cloud, they offer multi-cloud and multi-cluster management. For sovereign cloud operators who want the control of private infrastructure but prefer to outsource Day 2 operations, Mirantis provides that option.
Kolla-Ansible: The Community-Driven Path
And then there is the path with no vendor at all. Kolla-Ansible deploys upstream OpenStack services in containers using Ansible automation. No vendor license. No commercial support contract required. Just you, the community, and the upstream code.
Kolla-Ansible’s mission is straightforward: provide production-ready containers and deployment tools for operating OpenStack clouds. It ships opinionated defaults for quick deployment but allows full customization as your experience grows. The 2025 Flamingo release (21.0.0) tightened operations for the control plane and observability stack. Recent improvements include the reintroduced kolla-ansible check command for rapid diagnostics, privilege de-escalation for post-deployment tasks, OVN tooling improvements, and Podman support.
For sovereignty-minded operators, the appeal is clear. There is no vendor dependency whatsoever. You run pure upstream OpenStack. You control every aspect of the deployment. Your sovereign cloud has zero commercial ties to any single entity. The trade-off is that you own the operational burden entirely, but for teams with strong OpenStack skills, that is a feature, not a bug.
What These Four Options Share
Despite their differences in deployment model and commercial backing, RHOSO 18, Canonical OpenStack, Mirantis MOSK, and Kolla-Ansible share the qualities that make them suitable for sovereign clouds. They are all open source. They all avoid hyperscaler dependency. They are all proven at production scale. And they all run on infrastructure you own and control.
But infrastructure sovereignty is only half the story.
Sovereignty Without Data Protection Is Incomplete
Here is where the conversation usually stops, and that is a problem. Organizations invest months choosing their sovereign OpenStack distribution, carefully deploying it within their jurisdictional boundaries, and configuring it to meet every regulatory requirement. Then they bolt on a backup solution that stores their data in a proprietary format.
Think about what that means. Your VMs, your volumes, your application data — the actual workloads you went sovereign to protect — now sit in a format that only one vendor can read. If that vendor raises prices, you cannot easily leave. If that vendor discontinues your product version, your backups become inaccessible. If that vendor is compelled by a foreign government to provide access, your sovereignty means nothing.
This is not a theoretical risk. Traditional enterprise backup vendors use formats heavily dependent on deduplication databases, making backups non-portable. Others ties you to proprietary file systems and hardware appliances. Even largest ones, arguably the most open of the traditional vendors, still requires specific tools for restore operations.
For a sovereign cloud operator, avoiding backup vendor lock-in is not optional — it is a compliance, operational, and sovereignty imperative. Your data protection must follow the same open principles as your cloud platform. Otherwise, your sovereignty has a single point of failure.
Trilio and the Open QCOW2 Backup Format
This is where Trilio for OpenStack takes a fundamentally different approach. Trilio is a native, agentless data protection solution purpose-built for OpenStack since 2013. It integrates as a service within the platform itself — registered in Keystone, visible in Horizon, aware of your tenants, projects, and RBAC policies.
With Trilio 6.0, Trilio added hybrid backup strategies and direct Kubernetes/OpenShift integration for RHOSO architectures. But the architectural choice that matters most for sovereign clouds is the backup format. Trilio stores backup data in QCOW2 and metadata in JSON. Both are open, documented, universally readable standards. No proprietary containers. Your backups are yours.
Why Open Formats Matter for Backups
When your backups are in QCOW2, they are not locked behind a vendor’s proprietary gate. Any system administrator with standard Linux tools can inspect, mount, and extract data from those backups. No Trilio license required. No Trilio software required. Your data remains accessible with the same open-source tooling you already use to manage your cloud.
Contrast this with proprietary backup vendors. X vendor backups depend on associated deduplication databases — the backup files are not autonomous. Y backup vendor locks you into proprietary file systems running on specific hardware appliances. These formats create artificial dependencies that directly conflict with the principles of digital sovereignty.
For sovereign cloud operators, this is not an abstract concern. GDPR requires data portability. National data sovereignty laws require that organizations maintain genuine control over their data. If your backup format requires a specific vendor’s software to read, do you truly control that data?
Hands-On: Inspecting and Using a Trilio QCOW2 Backup
Let me show you what “open format” actually means in practice. After running a Trilio backup, your data lands on your configured backup target (NFS or S3-compatible storage) as standard QCOW2 files with JSON metadata. Here is how you can work with those backups using nothing but standard Linux tools.
Step 1: Inspect the backup image with qemu-img
$ qemu-img info /mnt/backup-target/workload_abc123/snapshot_001/vm-disk-0.qcow2
image: vm-disk-0.qcow2
file format: qcow2
virtual size: 40 GiB (42949672960 bytes)
disk size: 8.2 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false
That is your backup. A standard QCOW2 file. The virtual size is 40GB but the actual disk usage is only 8.2GB thanks to sparse allocation. Any tool that understands QCOW2 can read this.
Step 2: Mount the backup with qemu-nbd
$ sudo modprobe nbd max_part=8
$ sudo qemu-nbd --connect=/dev/nbd0 /mnt/backup-target/workload_abc123/snapshot_001/vm-disk-0.qcow2
$ sudo fdisk -l /dev/nbd0
Disk /dev/nbd0: 40 GiB, 42949672960 bytes, 83886080 sectors
Device Boot Start End Sectors Size Id Type
/dev/nbd0p1 * 2048 2099199 2097152 1G 83 Linux
/dev/nbd0p2 2099200 83886046 81786847 39G 8e Linux LVM
You can see the partition table. This is a standard block device now. Mount it and browse the files:
$ sudo mount /dev/nbd0p1 /mnt/backup-browse
$ ls /mnt/backup-browse/
config-5.14.0-362.el9.x86_64 grub2 initramfs-5.14.0-362.el9.x86_64.img vmlinuz-5.14.0-362.el9.x86_64
Your files are right there. No proprietary extraction tool. No vendor license check. Just standard Linux commands.
Step 3: Use guestfish for safe filesystem inspection
$ guestfish --ro -a /mnt/backup-target/workload_abc123/snapshot_001/vm-disk-0.qcow2
Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.
><fs> run
><fs> list-filesystems
/dev/sda1: ext4
/dev/vg_root/lv_root: xfs
><fs> mount /dev/vg_root/lv_root /
><fs> ls /
bin
boot
dev
etc
home
...
><fs> cat /etc/hostname
sovereign-web-01
><fs> exit
guestfish runs a lightweight VM internally, making it safer for production use. You can browse, extract, and inspect files from the backup without modifying anything.
The takeaway is simple. Trilio backs up your OpenStack workloads. Those backups land as QCOW2 files you own. You can access them with qemu-img, qemu-nbd, guestfish, or any QCOW2-compatible tool. If Trilio disappeared tomorrow, your backups would still be there, readable, mountable, and recoverable. That is what open-format data protection means.
Putting It All Together: A Sovereign Stack You Truly Own
The sovereign cloud equation has three layers, and you need openness at every one of them.
Platform: Choose your OpenStack distribution — RHOSO 18 for enterprise support, Canonical for LTS simplicity, Mirantis for managed operations, or Kolla-Ansible for pure community control. All of them are open source. All of them run on your infrastructure under your jurisdiction.
Data Protection: Add Trilio for OpenStack for native, application-centric incremental-forever snapshot backups. Self-service through Horizon. Multi-tenant RBAC that respects your OpenStack identity model. Backup to NFS or S3-compatible storage that you control.
Backup Format: Your backups are QCOW2 and JSON. Open. Documented. Accessible with standard Linux tools. No vendor lock-in at the most critical layer — the layer that holds your actual data.
From infrastructure to backup format, every component in this stack is open. That is sovereignty done right.
Summary
OpenStack leads the sovereign cloud space through RHOSO 18, Canonical, Mirantis MOSK, and Kolla-Ansible. But sovereignty is incomplete without open data protection. Trilio’s QCOW2 backup format guarantees your backups stay accessible, portable, and truly yours — no lock-in at any layer.
Thank you for reading! I hope this gave you a clear picture of a truly sovereign stack. Try open-format backup for sovereign clouds.
