The question nobody puts on the comparison sheet

A managed backup service is a bet that someone else will be there on your worst day. The pitch is reasonable: let a vendor run the scheduling, the storage, the monitoring and the retries, and get on with your actual work. Most of the time that bet pays off.

But backups exist for the day something has already gone wrong. On that day, the question that matters is not how fast the dashboard loads or how many integrations the vendor lists. It is this: if the vendor is unavailable, in any sense of the word, can you still get your data back?

Almost no comparison sheet asks it. Feature grids compare retention policies, deduplication ratios and support tiers. They rarely ask what happens when the company behind the grid is the thing that has failed. Yet a backup you can only restore through one vendor's live service is not really a backup of your data. It is a backup of your relationship with that vendor.

This article argues that "can I restore without you?" is the single most important question to ask before choosing any managed backup service, and sets out what a convincing answer looks like. It uses Duplicati's own answer as an example near the end, including where that answer has limits.

Three ways a vendor becomes unavailable

"Unavailable" sounds like a single failure mode. It is at least three, and they fail on different timescales.

The outage

The vendor's control plane is down. Their status page says they are investigating. Your production server, meanwhile, has a dead disk, and the backup data is sitting in storage, fully intact, encrypted, and unreachable, because the only thing that knows how to decrypt it is the service that is currently offline.

Outages are the most common of the three and the easiest to dismiss. Every vendor has them, most are short, and most happen on days when you do not need to restore anything. The problem is correlation: the same cloud-region incident that takes your vendor offline may be the reason you need a restore in the first place.

The shutdown

The vendor is acquired, pivots, runs out of money, or quietly sunsets the product. You get an email with a deadline. Sometimes the deadline is generous; sometimes it is thirty days, and your backups are terabytes.

This is the slow-motion version of the outage, and it is the one people most often insist will not happen to them. It happens to good products made by good teams. The question is not whether your vendor will exist in ten years. It is whether your ability to restore depends on that.

The billing dispute

The least dramatic and, for many customers, the most likely. A card expires. A finance team disputes a charge. A renewal is missed over a holiday. An account is flagged by a fraud filter. On the vendor's side, the obvious response is to suspend the account until the money question is sorted.

Suspension is reasonable for most SaaS products. For backup, it means your data has become collateral in a payment negotiation. The vendor is not acting in bad faith; the system is simply designed so that access to your data and your standing as a paying customer are the same switch.

What the three have in common

In each case the data itself is fine. The storage is intact, the bytes are there. What is missing is the ability to turn those bytes back into files without the vendor's cooperation: the keys, the format knowledge, or a working restore tool. A real answer to "can I restore without you?" has to cover all three, not just the outage.

An export button is not an escape hatch

Ask a vendor the question and the usual answer is "of course, you can export your data at any time." That is true and almost beside the point. An export button has three properties that make it the wrong tool for the three scenarios above.

It lives inside the service. If the service is down, suspended or gone, so is the button.

It has to be pressed in advance. An export is something you do while things are fine, to guard against a day when they are not. Few people do this on a schedule, and an export from last quarter is not a backup of this quarter.

It produces a copy, not a capability. Even a successful export leaves you with a pile of data and no tooling. If the export is in a proprietary format, you now have two problems.

A genuine escape hatch is different in kind. It is not a feature you invoke when the vendor fails; it is a property of how the service was built, such that the vendor's failure does not take your restore path with it. In practice it has four parts:

1. Your data sits in storage you can reach directly. Either your own bucket, or a vendor-provided bucket you can address with ordinary tools and credentials, without going through the vendor's application.

2. The on-disk format is documented and open. Someone with no relationship to the vendor can read the specification and understand what the files are.

3. A restore tool exists that does not phone home. Ideally open source, runnable on a machine you control, with no license check, account login or API call back to the vendor.

4. You can hold the decryption key yourself, ahead of time. Not "request it from support," not "download it from the portal when you need it." A key you already have, in your own password manager, that the vendor cannot revoke.

The fourth part is where most services stop short. Managing the key for you is a large part of what makes a service "managed." It is convenient, and it is exactly the convenience that turns an outage, a shutdown or a billing hold into data loss. The honest version of a managed service is one that manages the key for you by default and lets you take a copy of it, or a restore-only derivative of it, whenever you want.

A simple test: if you can describe the restore procedure for the worst case without the vendor's name appearing in any step after "fetch the key," you have an escape hatch. If the vendor's name appears in every step, you have an export button.

How we answer it: the restore-only key

We built the Duplicati Console on top of an open-source backup engine, which gave us an unusual starting position. Parts one to three of the escape hatch were already there before the Console existed. Duplicati's storage format is open and documented, the client is open source, and the client has never needed an account or a server to restore from a backup it can reach. That is how the project has worked for over a decade, and the Console does not change it.

For most Console customers the fourth part is also already in place. The default setup points backups at storage the customer owns, with a passphrase the customer chose. The Console sees schedules, reports and health; it never holds the key. If the Console disappeared tomorrow, every one of those backups would backup and restore with the open-source client exactly as it did yesterday.

The Console adds two things on top of that: storage you can buy from us instead of bringing your own, and managed backups where the Console runs the job end to end. Each of those takes something out of your hands, so each one comes with a key you can take back.

The restore-only key covers Duplicati-provided storage. It is a credential you generate in the Console that lets a Duplicati client with no Console connection read the storage. It cannot write to it or delete from it, which is what makes it safe to use without the console key protection. It is valid for 7 days from the moment it is issued, and it is issued by the Console. That is the limit that matters: it is a way to get at your data with the plain client while the Console is up, not a credential you can bank against the day it is not. If you bring your own storage, you do not need this key; you already have the credentials.

The encryption key covers managed backups and any configuration the Console stores on your behalf. In those cases the Console has to hold the key to do its job. But it does not generate the key silently: it shows the key to you before it stores it, so you can keep your own copy. That copy is yours, and nothing we do afterwards can revoke it.

For a managed backup on Duplicati storage you need both: a restore-only key to reach the storage, the encryption key to turn what is there back into files. Because the storage key is short-lived, that combination only works while the Console is there to issue it. For a managed backup on your own storage you need only the encryption key. For the default setup, your storage and your passphrase, you need neither; the Console was never between you and your data.

With those keys in hand, the three scenarios play out differently:

• Outage. The Console is down. If your backups are on your own storage, you install the open-source client, point it at the storage, enter the encryption key, and restore. We are not in the loop. If they are on Duplicati storage, you wait for the Console, because the storage key comes from it.

• Shutdown. Same procedure for your own storage: the client and the format outlive the service that ran them, because neither depends on it. For Duplicati storage, the wind-down notice is the window in which to issue a storage key and copy the data out; after that there is nothing left to issue one.

• Billing dispute. Your account is disabled until the invoice is sorted. On your own storage, the encryption key you copied at setup still works, because it was never ours to revoke, and the storage was never ours to suspend. On Duplicati storage, a disabled account means no storage key and no storage; see the edges below.

Where the escape hatch has edges

An escape hatch is only honest if its limits are stated, so here are ours.

Duplicati-provided storage is not an escape hatch against us. The restore-only key is issued by the Console, lasts 7 days, and the storage itself needs a paid subscription. That means it protects you in none of the three scenarios: not an outage, not a shutdown, and not a billing dispute, since a disabled account can neither issue a key nor keep the storage. What it does give you is a clean exit while things are working: a plain client, no Console, and a week to copy everything to storage you control. Customers who want the storage independent of us should point managed backups at their own destination, where the encryption key is the only thing they ever needed from us.

The encryption key has to be kept from the start. It is shown once, at setup, and cannot be recovered from us during an outage or after a shutdown. This is the same "press it in advance" property we criticised in export buttons, with one difference: it is a one-time action, not a recurring export, and the key stays valid for everything backed up afterwards. Treat it like any other secret and store it the day the backup is created.

None of this makes the escape hatch perfect. It makes it real: a procedure you can test today, that does not require our cooperation, our uptime, or our continued existence to complete.

How to test any vendor's answer, including ours

Do not take the answer on trust, from us or from anyone. Run the drill.

1. Pick one backup that matters.

2. Obtain whatever the vendor says is your independent restore credential, and store it somewhere the vendor cannot touch.

3. Block the vendor. Log out, revoke the API token, firewall their domains, or simply pretend their status page says "major outage."

4. On a clean machine, restore a file from that backup using only the credential, the storage location, and publicly available tools.

5. Time it. Write the steps down. Note every point where you needed the vendor after all.

If step four works, you have an escape hatch and a runbook. If it does not, you have learned something important about your backup strategy while it is still cheap to learn, and you have a very precise question to ask the vendor.

We would rather customers run this drill against Duplicati on a quiet Tuesday than discover the answer during an incident. If you are a Console customer with managed backups and you did not keep a copy of the encryption key, that is the first step; the open-source client and the format documentation are the rest. If those backups sit on Duplicati storage, the drill will show you the limit of that choice, and moving them to your own destination is the fix.

The question, again

Managed backup is a good idea. Handing the daily work to a vendor is the right call for most teams, and the convenience is real. The mistake is letting the convenience extend to the one moment it should not cover: the restore you need on the day the vendor is not there.

So before the feature comparison, before the pricing call, ask the one question. Can I restore without you? Then ask for the procedure, not the promise, and test it.