faaleoleo · June 2026 · Business
Your Backup Data Should Belong to You
The Hidden Cost of Vendor Lock-In
Many organisations sign a backup contract, see a green status indicator every morning, and consider the problem solved. What they rarely ask is a more uncomfortable question: if they needed to leave their backup provider tomorrow, could they take their data with them? Could they even read it? Vendor lock-in in backup is not a theoretical risk. It is a structural feature of how most backup products are sold — and understanding it is the difference between data you control and data you merely rent.
What vendor lock-in actually means
Vendor lock-in occurs when switching away from a product or service becomes so costly, technically complex, or operationally disruptive that you effectively cannot do it — even if you want to. In most areas of business technology, lock-in is inconvenient. In backup, it is a direct threat to your ability to recover.
Lock-in in backup takes several forms, and they often appear together:
-
01
Proprietary data formats Your backup data is stored in a format that only the vendor's own software can read. If the vendor raises prices, discontinues the product, or goes out of business, you cannot restore your data without their software — which may no longer be available or licensed to you.
-
02
Cloud-only storage Your backups exist exclusively in the vendor's cloud. You have no local copy, no independent storage, and no path to your data that does not run through the vendor's infrastructure and the vendor's billing system.
-
03
License-gated restoration Restoring data requires an active subscription or a valid software license. The moment your licence lapses — even during a dispute, a company acquisition, or a vendor bankruptcy — restoration becomes impossible.
-
04
Opaque backup catalogs The index of what has been backed up, where it is, and how to find it is stored in a proprietary format that only the vendor can interpret. Without the catalog, you cannot identify what to restore even if the raw data exists somewhere.
Any one of these is a problem. When they appear together — as they commonly do in cloud backup products sold to enterprises — the organisation is not backing up its data. It is renting access to a copy of its data, on the vendor's terms, for as long as the vendor decides to provide it.
Three scenarios that expose the risk
Vendor lock-in is invisible until you need to exit. These three scenarios illustrate when it becomes visible — and costly.
A price increase you cannot refuse. Your backup vendor announces a price increase of 40% at contract renewal. You begin evaluating alternatives and discover that migrating your backup data would require re-running every backup job from scratch — months of re-protection time and storage costs at the new provider before you reach the coverage level you already have. The vendor knows this. The price increase is not arbitrary — it is set at precisely the level where it is cheaper to pay than to leave.
An acquisition that changes everything. Your vendor is acquired by a larger company. Six months later, the product is being sunset. Customers on the discontinued product are offered a migration path — to the acquirer's own solution, using the acquirer's storage, at the acquirer's prices. Alternatives exist, but your data is in a format nobody else can read, and the migration tools are proprietary. The cost of moving is equivalent to starting over.
A service outage at the wrong moment. A major incident — a cyberattack on the vendor's infrastructure, a cloud region failure, a billing system error — makes your backup data temporarily inaccessible. Your infrastructure has just experienced a failure of its own. You need to restore. The restoration path runs through the same infrastructure that is currently unavailable. The backup existed. You cannot use it.
None of these scenarios require negligence on your part. They are the natural result of a backup architecture built around a single vendor's infrastructure with no independent access path.
Why this is also a legal matter
Data ownership is not just an operational concern. For organisations operating under European data protection law, it is a compliance requirement.
GDPR places accountability on you. The General Data Protection Regulation requires that you, as the controller of personal data, can demonstrate that data is adequately protected and can be recovered when needed. The regulation does not allow you to transfer that accountability to a vendor. If a breach or loss event occurs and regulators ask for evidence of your backup and recovery capability, "our vendor handled it" is not a compliant answer.
NIS2 goes further. The NIS2 Directive, which became binding EU law in October 2024, explicitly requires organisations in scope to maintain backup and recovery capabilities as part of their cybersecurity risk management. Article 21(1)(c) mandates documented, tested backup procedures with defined recovery objectives. If your backup data is locked inside a vendor's proprietary system and you cannot demonstrate independent access and recovery capability, that requirement is not met — regardless of what the vendor's marketing materials say.
The question auditors ask. When a compliance auditor reviews your backup programme, they will ask: can you restore your data without this specific vendor's active involvement? Can you demonstrate this? Is the answer documented? If the answer to any of these is no, the backup programme has a gap — and that gap is not a technical detail. It is a governance failure with potential regulatory consequences.
What genuine data ownership looks like
Owning your backup data is not about who physically stores it. It is about what you can do with it, independent of any single vendor relationship.
Genuine data ownership means:
- Your backup data is stored in an open, documented format that multiple tools can read
- You hold at least one copy on infrastructure you control — whether that is your own hardware, a data centre you own, or a cloud account in your name where you control access independently
- Your backup catalog — the record of what has been backed up and how to find it — is accessible to you without requiring the vendor's software to be running
- You can initiate a restoration using your own tools and your own credentials, without depending on the vendor's systems being online or the vendor's staff being available
- You can move to a different backup provider without losing historical backup data
This is not an unusual set of requirements. It is what backup was always supposed to provide. The growth of proprietary cloud backup products has normalised a version of backup that meets almost none of these criteria — and because incidents are infrequent, the gap is rarely noticed before it matters.
Open standards: why they exist and why they matter here
Bacula Enterprise, the platform that underlies all faaleoleo managed backup services, was built on an open architecture because the engineers who created it understood this problem.
The Bacula catalog — the index of every backed-up file, every job, every version — is stored in a standard relational database (PostgreSQL or MySQL). Any database administrator can query it directly. The backup data itself uses a documented, open format. The software is available under open source licences, and a commercial support path exists independent of any single company.
This means that an organisation running Bacula can, at any point:
- Inspect their own backup catalog directly, with standard database tools
- Restore data using any licensed Bacula installation, not just the one their current service provider operates
- Move their backup data to a different provider or to self-managed infrastructure and retain full access to historical backups
- Verify independently that their backups are complete and valid, without relying on a vendor dashboard to tell them so
Open standards are not a workaround or a compromise. For backup infrastructure, they are the correct design choice — because backup infrastructure must be trustworthy and accessible under exactly the conditions where vendor relationships are most likely to be strained.
How faaleoleo approaches this
Every faaleoleo managed backup deployment is built around one principle: when you stop working with us, you take everything with you.
Your backup data is stored on infrastructure you control — in your data centre, your cloud account, or our managed hosting with your credentials. The Bacula catalog is yours. The backup jobs are configured in standard Bacula syntax that any Bacula installation can read. The encryption keys, where applicable, are held by you.
We do not offer a discount for storing backups exclusively on our infrastructure. We actively recommend against architectures where the only copy of your backup exists in a single location that requires our involvement to access.
When we deploy a Bacula environment for a customer, we provide a handover package that contains everything needed to continue operating independently: the full configuration, the catalog schema, the job definitions, the documentation. This is not a theoretical offering. Several customers have asked for exactly this — to verify that independence for themselves — and received it.
The managed service we offer is expertise, hardening, monitoring, and support. It is not a lock on your data. Those two things are entirely compatible, and we would argue that a managed service that locks your data is not a managed service — it is a long-term dependency dressed up as a solution.
The question to ask your current provider
If you are evaluating backup solutions — or reviewing an existing one — one question cuts through the marketing: if our contract ended today, what would it take to access all of our backup data tomorrow, using tools we choose?
A provider with nothing to hide will answer that question directly. A provider whose business model depends on retention will not.
The answer tells you more about your actual data ownership than any SLA, any uptime guarantee, or any compliance certification on a product brochure.
If data ownership and backup independence are requirements for your organisation — either because of compliance obligations or simply because you believe your data should be yours — we are the right conversation to have.