Encrypted backups explained: what “we can’t read your backups” really means
Almost every vendor says its backups are encrypted. The question that actually matters is who holds the key, and what happens on the day you need a restore.
On this page
- Three questions that explain any backup setup
- Encryption and key custody, in plain words
- What “we can’t read your backups” does not mean
- Tamper-evidence: backups you can trust
- Retention and copies
- Keeping the key safe
- Test the restore, not just the backup
- How Crewqo backups work
- Questions to ask any vendor about backups
- Frequently asked questions
The short answer: an encrypted backup is a copy of your data scrambled so that only someone with the right key can read it. Who can open it depends entirely on who holds that key. If the vendor holds it, encryption protects your backups from outsiders who get hold of the storage, but not from the vendor. If only you hold it, the vendor genuinely can’t open your backups, and neither can anyone who breaks into the vendor. The trade-off is that if you lose the key, nobody can open them.
Three questions that explain any backup setup#
- What is backed up? The workspace database only, or files too? How often?
- Where is it kept? Only with the vendor, or is a copy sent somewhere you control? For how long?
- Who holds the key? The vendor, you, or both?
If a vendor can answer all three in a sentence each, you understand its backups. If the answers are vague, that is an answer too.
Encryption and key custody, in plain words#
You will hear three kinds of encryption mentioned:
- In transit: data is encrypted while it moves between your browser and the server (HTTPS). Standard, and essential.
- At rest: data is encrypted where it is stored. Also standard, but usually with keys the vendor manages.
- With a customer-held key: data is encrypted with a key the vendor doesn’t keep. Much rarer.
| Setup | Who can open backups | Protects against | Main risk |
|---|---|---|---|
| No encryption | Anyone who gets the file | Nothing | A leaked or stolen backup is readable |
| Encrypted, vendor-held key | The vendor | Someone stealing the storage or the files alone | Anyone with access to the vendor’s keys |
| Encrypted, customer-held key | Only you | Storage theft and access from inside the vendor | Lose the key and the backups are unreadable |
The lock and the key
Customer-held keys often use a simple idea: a pair of keys, where one only locks and the other unlocks. The vendor keeps the locking half so it can encrypt a fresh backup every night. You keep the unlocking half. The vendor can make new backups, but it can’t open any of them. That is what “we keep only the lock, never the key” means.
What “we can’t read your backups” does not mean#
It is a strong promise, and it is worth being precise about its limits.
- It is not about the live app. Your workspace still runs on the vendor’s servers, so the application can read it in order to show it to you. Customer-held backup keys protect the backup copies, not the running service.
- It is not end-to-end encryption. End-to-end means only the people communicating can read the content, even while it is being used. Backup encryption is narrower.
- It is not a password. Losing a key file is not like forgetting a password. There is no reset link, because the vendor never had it.
- It does not cover everything. If files live in separate storage, they are not in the workspace backup at all. Check what is in scope.
None of this weakens the promise. It just puts it in the right place: your historical copies are yours alone.
Tamper-evidence: backups you can trust#
Good backup encryption does two jobs: it keeps content private and it proves the file hasn’t changed. Authenticated encryption modes such as AES-256-GCM add a check to every encrypted chunk. If a single byte is altered, or the file is cut short, decryption fails. For you, that means a damaged or tampered backup is refused rather than quietly restored with missing data.
Retention and copies#
How long backups are kept, and where the copies sit, decide what you can recover from.
- Retention. A 30-day window lets you recover from mistakes you notice a few weeks late, such as a deleted project or a bad import.
- A copy you hold. A backup copy in your own storage means you don’t depend only on the vendor for recovery.
- The 3-2-1 habit. A common rule of thumb: three copies of what matters, on two different types of storage, with one off-site. Your own storage copy counts toward it.
Keeping the key safe#
If you choose a customer-held key, key custody becomes your job. A simple routine:
- Store the key in your agency’s password manager or secrets vault, not in a download folder.
- Make sure at least two trusted people can reach it.
- Keep one offline copy somewhere physically safe.
- Write down where the key lives in your operations notes, without writing the key itself there.
- Review who has access whenever an owner or admin leaves.
TipDo a “bus test”: if the person who downloaded the key were unreachable tomorrow, could someone else restore the workspace? If not, fix that today.
Test the restore, not just the backup#
Backups fail in quiet ways: wrong scope, expired credentials, a key nobody can find. The only proof a backup works is a restore. Once a quarter, pick a recent backup, restore it the way you would in an emergency, and check a few things you know should be there. Note how long it took. That number is what you tell a client who asks about recovery.
How Crewqo backups work#
- Every night. Your workspace (tasks, messages, clients, invoices) is backed up, encrypted and kept for 30 days.
- A copy with you. A copy of each backup also goes to your own storage.
- Your key, if you want it. Turn on your backup key and it is downloaded to you once. We keep only the lock, never the key, so we can’t open those backups. Until you turn it on, backups are still encrypted, with a key held by Crewqo.
- Tamper-proof. Each backup is encrypted with AES-256-GCM in sealed chunks, so a changed or cut-short file is refused.
- Restore it yourself. Upload a backup with your key file and your workspace is back as it was.
- Files are separate. They were never on our servers; they live in your own storage.
Your live workspace runs on Crewqo’s servers, like any web app. See backups on our security page and encrypted backups in features.
Questions to ask any vendor about backups#
Backup questions for every tool that holds client data
Frequently asked questions
If the vendor can’t read my backups, how do they restore them?
You do. With a customer-held key, you provide the key when restoring, for example by uploading the backup with your key file. The vendor never needs to see the unlocked data.
What happens if I lose my backup key?
Backups encrypted with that key can’t be opened by anyone, including the vendor. With Crewqo, your live workspace isn’t affected if you lose it; only those backup copies become unreadable.
Is encrypted backup the same as end-to-end encryption?
No. End-to-end encryption keeps content unreadable to the service provider even while it is in use. Encrypted backups protect stored copies. A web app still processes your live data to show it to you.
Are my files included in Crewqo backups?
No. Files are saved straight into the storage you connect and were never kept on Crewqo’s servers. Use your storage provider’s own versioning or backup features for them.
Written by the Crewqo team. Spotted something out of date? Tell us at hello@crewqo.com.