Client-side encryption is the right default for backups, and it comes with a bill that nobody reads until it is due: someone has to hold the key. Not the vendor, not the storage provider — someone on your team. That person goes on holiday, changes jobs, or forgets which password manager they used three years ago. The backups are still there, byte for byte. They are also unreadable.

This article is about the operational side of that trade-off. It covers who should hold a backup passphrase, how to rotate one without re-uploading terabytes, what escrow should look like when a management console stores keys on your behalf, and how Duplicati's two-key model keeps an escape hatch open without quietly making the vendor a key holder.

Client-side encryption moves the problem, it does not remove it

When a backup is encrypted before it leaves the machine, the storage provider holds ciphertext and nothing else. A leaked bucket, a subpoena to the provider, or a compromised vendor account cannot expose your data. That is the whole point, and it is why Duplicati encrypts on the client by default and why Duplicati-provided storage only holds data that was encrypted before it arrived.

The cost is that the provider also cannot help you recover. There is no "forgot passphrase" link, because anything that could reset the key would also be a way to read your data. The key management burden that a server-side-encrypted service absorbs for you (and that you implicitly trust them with) lands on your own team.

For an individual this is a note in a password manager. For a team it is a process question with three parts: custody (who has the key now), rotation (how it changes), and succession (what happens when the holder is gone).

The bus factor: how teams actually lose backups

The failure mode is almost never a sophisticated attack. It is a backup that was set up correctly in 2023 by an engineer who left in 2025, with a passphrase that lived in their head, their personal password manager, or a config file on a laptop that was wiped on their last day. The backup jobs keep running. Monitoring stays green. The first restore attempt is the first time anyone discovers the key is gone.

The same pattern shows up in a few variants:

• The founder's laptop. A small company's backups all use one passphrase chosen by the first technical hire, and nobody else was ever told it.

• The MSP technician. A managed service provider sets up backups for 40 client sites using per-site passphrases held in a tool only one technician has access to.

• The "we'll document it later" config. The passphrase is in the backup configuration file, the configuration file is backed up by the same job, and the job is the only copy.

In every case the data was never at risk from an outsider. It was at risk from a single point of failure inside the organization, and the stronger the encryption, the more total the loss.

Custody: where the passphrase should live

The rule that fixes most of the above: a backup passphrase belongs to a role, not a person, and it must exist in at least two places that do not share a failure.

In practice that means:

1. A team-owned secret store as the primary copy. A shared vault in your password manager, a secrets manager, or an encrypted document in a location that survives any one person's departure. Access is granted by role (backup administrator, IT lead) and revoked by off-boarding, not by asking someone to "send it over".

2. An offline copy under separate control. A printed sheet in a safe, or a second vault held by a different person, so that losing the primary vault's master password is not a total loss.

3. Never only in the backup configuration. The passphrase can live in the config file for convenience, but the config file is not custody. If the only copy is on the machine being backed up, a disk failure takes both the data and the key.

For MSPs the same rule applies per client: a client's passphrase is the client's property, held in the MSP's vault under that client's record, with the client given their own copy at handover. A client should be able to restore without you, and you should be able to restore without the one technician who onboarded them.

One more point that is easy to miss: the storage credentials and the encryption passphrase are different secrets with different blast radii. Losing storage credentials means you cannot reach the files. Losing the passphrase means you can reach them and they are useless. Keep both, but treat the passphrase as the one that cannot be re-issued.

Rotation: what rotating a backup key actually means

Rotation is where backup encryption differs from, say, rotating an API token. A deduplicated backup is a set of encrypted volumes on remote storage, and each one was encrypted with the passphrase in use when it was uploaded. Changing the passphrase on an existing backup set would mean downloading every volume, decrypting it, re-encrypting it, and uploading it again. For a multi-terabyte archive that is days of transfer and, on cloud storage, a noticeable egress bill.

So in practice, backup key rotation is a generational process rather than an in-place one:

1. Create a new backup job with a new passphrase, pointed at a new destination folder or bucket.

2. Let it run until it has a full history you are comfortable with.

3. Keep the old passphrase in custody until the old backup set's retention has expired or the data has been deliberately deleted.

4. Only then retire the old key.

This is also why rotation should be driven by events, not by a calendar. Rotate when a key holder leaves, when a device that held the passphrase is lost, or when a config file may have been exposed. Rotating every 90 days "because policy" produces a pile of half-expired backup generations and a growing list of passphrases that all still need to be kept.

The exception is the key that protects the configuration rather than the data. If a management console stores your backup configuration, the key that encrypts that stored configuration can be rotated cheaply, because the configuration is small. The Duplicati Console allows exactly that: configuration keys can be rotated from the Console, and a Duplicati administrator helping with a support case can trigger a rotation but can never read the key itself.

Escrow for managed configurations: the shown-before-storing key

There is a real tension in managed backup. If a console stores backup configurations and runs managed jobs on your behalf, it needs the encryption key to do its job. If it holds the key, you have made the vendor a key holder and given up part of what client-side encryption bought you. If it does not, you are back to the bus factor.

The usual resolutions are both bad. Either the vendor quietly holds the key and calls it "zero knowledge" anyway, or the vendor holds nothing and the "forgot passphrase" story is a shrug.

The Duplicati Console takes a third route. When you store a backup configuration in the Console, or set up a managed backup (Microsoft 365, Google Workspace), the encryption key for that configuration is shown to you before it is stored. You are asked to put a copy in your own custody, following the rules above, before the Console keeps its copy.

That ordering is the whole point:

• The Console's copy is an operational copy. It is what lets managed jobs run without a human typing a passphrase, and what lets a colleague take over a configuration after you leave.

• Your copy is the custody copy. It is what lets you restore if the Console is unreachable, if your subscription lapses, or if you simply decide to stop using the service.

Neither copy is privileged over the other, and the vendor holding one does not reduce you to depending on it. If you prefer the Console to hold no keys at all, the Console's confidential organization mode disables Duplicati-held key storage and managed runners entirely; the trade-off is that managed features that need the key are switched off. For most teams, the shown-before-storing model is the right balance: the vendor can operate, but cannot be the only one who can read.

The two-key model for Duplicati-provided storage

For backups that land on Duplicati-provided storage, there is a second key with a different purpose. The data key encrypts the backup. A separate restore-only storage key grants read access to the storage bucket itself, for a Duplicati client that is not connected to the Console.

The restore-only key exists for one scenario: you need your data back and, for whatever reason, you are not going through the Console to get it. A Console outage, a migration away from the service, or an incident where you want to restore from an isolated machine. You request the key, it is valid for 7 days from issue, and it lets a standalone Duplicati instance read the encrypted volumes directly from storage.

It does not let anyone read the backup. For that you still need the data key, which is in your custody. A managed backup stored on Duplicati storage therefore requires both keys to restore:

The split matters because the two keys have different threat models. A leaked storage key gives an attacker cipher-text. A leaked data key gives an attacker nothing without access to the storage. Duplicati's own administrators sit on neither side: admin tooling for troubleshooting can see Console metadata and trigger key rotation, but it is enforced in code that it cannot obtain storage keys or read backup data, and every use is audit-logged.

Two keys, two custodians, one escape hatch that does not route through anyone's goodwill.

When a key holder leaves: the checklist

The day someone with backup key access leaves is the day the process above gets tested. In order:

1. Verify custody before access is removed. Confirm every passphrase they could have held is in the team vault and the offline copy. Do this while they are still reachable; it is far easier to ask "which vault did you use for client X" on their last Tuesday than three months later.

2. Test a restore with the vault copy. Not with their copy, not with the config file. Restore one file from each backup set using only the passphrase as it exists in custody. A passphrase with a trailing space in the vault is indistinguishable from a correct one until you try.

3. Revoke access by role. Remove them from the vault group, the Console organisation, and the storage account. If your Console login goes through your identity provider, disabling the account there covers the Console as well.

4. Decide whether to rotate. If the passphrase lived only in a shared vault they could not export, revocation may be enough. If it was in a personal password manager, a chat message, or a laptop, start a new backup generation with a new key and keep the old one until retention runs out.

5. Rotate the cheap keys immediately. Storage credentials and Console configuration keys can be rotated without re-uploading data, so rotate those regardless.

6. Record who holds what. Update the custody record: which role holds each key, where the offline copy is, and when it was last verified by a test restore.

None of these steps need the departing person's cooperation if the custody rules were followed. That is the test of whether they were.

The short version

Client-side encryption means the key is yours, and "yours" has to mean the organization's, not one employee's. Keep every passphrase in a role-owned vault plus an offline copy, rotate by generation when an event calls for it, and test the custody copy before anyone's last day.

Where a console stores keys for you, insist on knowing exactly which keys it holds and that you were handed your own copy first. That is how the Duplicati Console works: configuration keys are shown before they are stored, restore-only storage keys are issued on request and expire, and a managed backup on Duplicati storage needs both. The vendor can run your backups without ever being the only party who can read them.

If you manage backups for a team or for clients and want to see how key custody works in practice, start a Console trial and set up a managed configuration. The first thing it will do is show you the key.