Zero-Knowledge Backups: How Client-Side Encryption Works
A zero-knowledge backup service is generally one whose operator cannot decrypt the backed-up file contents because encryption happens on a device you control. The phrase is not a precise product standard, though, and it does not mean the service knows literally nothing about your account or data. This guide separates backup encryption from cryptographic zero-knowledge proofs, explains the architecture and remaining risks, and shows how to plan a recoverable encrypted backup.
What Are Zero-Knowledge Backups?
In a backup context, “zero-knowledge” usually describes client-side encryption: a backup application encrypts data before sending it to a remote repository, and the storage provider does not hold the key needed to decrypt it. The provider stores ciphertext rather than readable documents.
That usage is different from a zero-knowledge proof (ZKP), a cryptographic protocol for proving that a statement is true without revealing the secret information, or witness, that supports it. A ZKP is not itself a way to encrypt a backup. Read our zero-knowledge proofs explainer for the proof system.
The label alone does not establish how a product handles encryption, account recovery, metadata, sharing, or software updates. Check its technical documentation and threat model. Depending on the implementation, a provider may still control account authentication or distribute the client software, and may observe traffic patterns or storage use. “Client-side encrypted” is a more specific description of the protection than a bare marketing claim.
The Problem They Address
Ordinary cloud storage often encrypts data in transit and at rest, but the provider may control the keys. That protects against some network and disk exposure, yet it may not prevent the provider or an attacker with access to its key-management systems from decrypting stored content.
Client-side encryption changes that trust boundary. It can reduce exposure if a storage account or provider infrastructure is compromised, and can keep the storage operator from reading file contents. It does not prevent an attacker who compromises the source device before encryption, steals the recovery key, or accesses an unlocked client from seeing plaintext.
| Approach | Who can normally decrypt stored content? | What it is useful for | Important limitation |
|---|---|---|---|
| Provider-managed encryption | The customer and the provider or its key-management service | Protecting disks and network transfers without extra client setup | The provider remains within the decryption trust boundary |
| Client-side encrypted backup | A client with the repository key or passphrase | Keeping backup contents unreadable to the storage operator | Lost keys can make every retained snapshot unrecoverable |
| Encrypted file-sync vault | Authorized clients that hold the vault key | Synchronizing selected files across devices | Sync history, deletion protection, and restore workflows vary; sync alone may not be a backup |
| Zero-knowledge proof | Not a storage-encryption method | Proving a claim without disclosing its witness | Does not encrypt files or provide backup recovery |
Confidentiality is only one part of a backup plan. Encryption does not stop someone with deletion rights from erasing a repository, guarantee that a stored copy is complete, or ensure that applications can be restored. Keep independent copies and use the recovery guidance in CISA’s ransomware guide, which recommends maintaining and testing backups as part of resilience planning.
How Client-Side Encrypted Backups Work
A typical encrypted backup follows this flow:
Source data -> consistent snapshot or application export -> backup client chunks and optionally compresses data -> authenticated encryption -> encrypted repository -> verify and restore with the required key
The steps and file formats depend on the product, but the trust model has several parts:
- Capture a usable state. The client reads files or an application-consistent export. Databases and active services may need their native dump tools or snapshots so a restore is internally consistent.
- Prepare the backup. A repository tool may divide data into chunks, deduplicate unchanged content, compress it, and record snapshot metadata. The order and details vary by implementation.
- Encrypt before upload. The client encrypts content locally, typically using authenticated encryption so it can also detect unauthorized changes to encrypted records. Well-designed tools manage data keys and nonces; do not implement this cryptography yourself.
- Protect the repository key. A passphrase, recovery key, or key file protects the encryption key. Some products derive key material from a passphrase; others use a randomly generated key protected by it. The exact design matters for recovery and offline guessing resistance.
- Store ciphertext and operational metadata. The remote backend receives repository objects and may see their sizes, access times, update frequency, or account-level information. What else is visible depends on the client and storage format.
- Restore and verify. An authorized client retrieves the repository, authenticates and decrypts records, then writes data to a target. A successful upload is not proof that the full restore path works.
For general key lifecycle, protection, and recovery considerations, see NIST SP 800-57 Part 1. If you are evaluating how a tool protects passphrases, use its implementation documentation rather than assuming every product uses the same key derivation or encryption scheme.
Components and Common Variants
- Backup client and repository format: Tools such as Restic and BorgBackup create encrypted, versioned repositories. Their formats, storage backends, key handling, and operational commands differ.
- Passphrase and recovery material: A strong, unique passphrase can protect a repository key, but it must remain available during a disaster. Keep an offline or separately controlled recovery copy. If a team uses multiple recovery keys or custodians, document who can restore and how access is approved.
- Metadata and deduplication: Deduplication can reduce storage by reusing matching chunks. It can also reveal information through observable repository changes or sizes, depending on the design. Encrypted names do not necessarily hide traffic patterns or total storage use.
- Backup versus synchronization: A sync client propagates changes between devices. It may also propagate deletions or corrupted files. A backup should retain recoverable prior versions and have a restore process independent of the source device.
- Proofs of storage: Proof-of-retrievability schemes are a separate family of mechanisms for checking that data is retained. They do not replace encryption, ordinary repository integrity checks, or an end-to-end restore test.
Real-World Use Cases
Client-side encrypted backups are useful when the storage operator should not routinely read the stored contents: personal records in a cloud repository, source code and design files, legal or research material, or off-site copies for a small organization. They are also useful in a self-managed environment where a separate storage account or administrator should not automatically hold the decryption key.
The design is appropriate only when the people responsible for recovery can protect and retrieve the key. A business needs a process for staff changes, incident response, and authorized recovery; an individual needs a documented plan for device loss or incapacity. If a service must index or inspect plaintext on the server, client-side encryption may be incompatible with that feature.
Practical Considerations: Setup and Recovery
Before choosing a tool, decide what data is in scope, who you are protecting it from, how much data loss is acceptable, and how quickly a restore must complete. Then document repository access, key recovery, retention, and a restore test. A self-hosted backup architecture can help separate local recovery from an encrypted off-site copy; broader retention and recovery objectives are covered in our backup strategy guide.
The following Linux example uses Restic with a local repository on a separately mounted backup disk. Install Restic using its official instructions first. Create a strong unique passphrase with a password manager and arrange an independent recovery copy before relying on the repository.
# Create a private directory for the automation password file.
install -d -m 700 "$HOME/.config/restic"
umask 077
# Enter the passphrase interactively; it is not placed in shell history.
read -r -s -p "Repository passphrase: " RESTIC_PASSWORD
printf '\n'
test -n "$RESTIC_PASSWORD" || { printf 'Passphrase must not be empty\n' >&2; exit 1; }
printf '%s\n' "$RESTIC_PASSWORD" > "$HOME/.config/restic/password"
unset RESTIC_PASSWORD
export RESTIC_REPOSITORY="/mnt/backup/restic-repository"
export RESTIC_PASSWORD_FILE="$HOME/.config/restic/password"
# Run once for a new repository.
restic init
# Back up a directory and inspect the resulting snapshot.
restic backup "$HOME/Documents"
restic snapshots
# Check repository consistency, then practice restoring outside the source path.
restic check
restic restore latest --target "$HOME/restore-test"The password file makes unattended jobs possible; it is not a substitute for an independent recovery copy. Keep it readable only by the account that runs the backup, protect that account and the backup disk, and store recovery material somewhere that will survive loss of the source device. Restic’s password handling guidance explains password-file and environment-variable options and their exposure risks.
Schedule the backup only after testing the commands manually. Alert on failures, monitor repository capacity, retain versions long enough to outlast likely detection delays, and periodically restore a representative file or application into an isolated location. A repository check and a sample restore exercise different parts of the recovery path; for critical data, perform a broader restore drill as well. If you derive keys from passphrases in a custom system, use a maintained library and a reviewed design; RFC 9106 specifies Argon2, but it is not a recommendation to build a custom backup-encryption format.
Common Misconceptions
“Zero-knowledge means the provider knows nothing”
The provider may still know account details, access times, traffic volume, and storage usage. The term usually concerns access to plaintext, and the exact boundary depends on the implementation.
“Zero-knowledge backups and zero-knowledge proofs are the same”
They are not. Backup products usually use the phrase for client-side encryption. A ZKP is a proof protocol and does not encrypt a backup repository.
“Encryption means the backup cannot be changed or deleted”
Encryption can provide confidentiality and authenticated formats can detect tampering, but a storage operator or compromised account may still delete or withhold data. Keep an independent copy with separate access controls and test recovery.
“The provider can recover my files if I forget the passphrase”
If the provider truly lacks the decryption key, it may not be able to restore plaintext for you. Plan key recovery before uploading irreplaceable data, and test that the recovery material works.
“An encrypted sync folder is automatically a backup”
Synchronization can reproduce deletions and damaged files. Confirm that the product preserves history, has adequate retention, and can restore independently of the original device.
Related Articles
- Zero-Knowledge Proofs in Blockchain explains the cryptographic proof concept that is distinct from backup encryption.
- Backup Strategy Best Practices covers retention, recovery objectives, and restore testing.
- Self-Hosted Backups shows how to combine local and off-site recovery copies.
- Storage RAID Configuration Guide explains why storage redundancy is not a substitute for backups.
- ZFS Administration and Tuning covers storage management and local snapshot capabilities.
- Ceph Storage Cluster Deployment introduces distributed storage architecture and its operational trade-offs.
