Secure Backups security
Handing your media to somebody else's storage is a security decision, so this page states the mechanism rather than the marketing. It covers where the data goes, who can reach it, what encryption does and does not buy you, and what happens when something on your side is compromised.
Where your data lives
Each backup is stored in the region that belongs to its storage class, chosen when the backup is created and fixed thereafter.
| Storage class | Region | Operated by |
|---|---|---|
| Standard | North America | Cloudflare, on R2 |
| Long term storage | Canada (Canada Central) | Microsoft, on Azure |
Both are commercial object storage services with replication across multiple facilities inside the stated region, and both encrypt at rest. Cardinal names them here because a security page that will not say where your files physically are is not much of a security page. They are named nowhere else, because which company holds the disks is an implementation detail that may change; the region and the protections are the commitment.
Data does not move between regions. A Long term storage backup stays in Canada, and a Standard backup stays in North America, for the life of the backup.
How your account is isolated
Your Media Server never talks to storage. Every byte — up and down — passes through Cardinal's gateway, and the gateway decides which storage location that byte belongs to.
Your Media Server Cardinal Storage
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ encrypt (opt.) │──TLS──▶│ gateway │──TLS──▶│ your private │
│ upload │ │ · verifies auth │ │ storage area │
│ │ │ · picks target │ │ │
│ │ │ · counts bytes │ │ (no public │
└──────────────────┘ └──────────────────┘ │ endpoint) │
▲ └──────────────────┘
signed authorization
issued per run
Fig. 1 — every byte goes through the gateway
Three properties follow from that shape:
- The destination is never something your server asks for. The gateway derives your storage area from a cryptographically signed authorization. A client cannot name a path, so reaching another account's data would require forging a signature rather than guessing a location.
- The storage endpoint is not on the public internet. It appears in no address your apps ever see, and it refuses connections from every source except the gateway.
- There are no storage credentials on your hardware. Your Media Server holds a Cardinal token that can talk only to Cardinal's backup service, never to storage - and that token is created with your approval, limited to backups, and revocable from your account portal at any time.
Scoped authorization
When a backup or restore starts, your server asks Cardinal for an authorization scoped to one account, one backup, and one direction. Your server can ask whenever it needs to - running unattended backups is its job - so the protection is not that access is fleeting. It is what an authorization cannot do, and that Cardinal stands at every issuance:
- A backup authorization can write new data. It cannot read, list, overwrite or delete - so a machine that can start a backup whenever it wants still cannot touch what is already stored.
- A restore authorization can read. It cannot write anything.
- Every authorization carries a byte ceiling that the gateway counts against in real time, not after the fact.
- Every issuance and renewal is a checkpoint on Cardinal's side: your subscription, your remaining space, and the backup's own state are re-checked. An authorization can be revoked mid-transfer, and the next byte is refused.
Delete and list are not verbs any client is given, ever. They exist only in Cardinal's control plane, behind your Cardinal Account login.
Encryption
Always on: in transit and at rest
Every backup, without exception, is encrypted in transit with TLS and encrypted at rest in storage with AES-256. Nothing you configure turns that off.
Optional: end-to-end encryption
End-to-end encryption is a per-backup option, chosen at setup, and it is recommended for Photos. When it is on, files are encrypted on your Media Server, before upload, with a key derived from a passphrase you choose. Cardinal stores only the encrypted form and never receives the passphrase.
With end-to-end encryption on:
- File contents are unreadable to Cardinal, to the storage operators, and to anyone who intercepts the traffic.
- File names and paths are protected too — a file is identified in storage by a value derived from your key, not by anything that could be matched against a catalogue of known files.
- Duplicate files still only upload once, so the space saving survives the encryption.
The encryption code is open source and published with Cardinal's self-hosted code, so the construction can be read and audited rather than taken on trust.
Your passphrase and your recovery kit
At setup, an end-to-end encrypted backup offers a one-time recovery kit — a file containing the key itself. Download it and store it somewhere you will still have it after the disaster you are backing up against. It is never sent to Cardinal.
If you lose the passphrase and the recovery kit, the backup cannot be decrypted by you, by Cardinal, or by anyone else. There is no reset, no support override, and no recovery path. That is the point of the feature, and it is the cost of it.
What encryption can and cannot protect
Encryption is often sold as if it solves everything. It does not. Here is what each layer actually buys, in the order the layers stack.
1. What every backup gets. Encryption in transit and at rest means the data is not readable off the wire, and not readable from a stolen disk, a mislaid drive, or a storage-side leak of raw data. It does not hide anything from Cardinal: for a backup without end-to-end encryption, Cardinal's systems can technically read the file contents, because Cardinal holds the keys that storage uses.
2. What end-to-end encryption adds. The keys move to your side. Cardinal cannot read your files, the storage operators cannot read your files, and neither can anyone who compromises Cardinal's cloud, subpoenas it, or intercepts the network. What reaches storage is ciphertext with names that leak nothing.
3. What nothing here can protect against. Anyone with root on the machine running your Media Server can read your library directly — the original files sit there in plain form, which is the entire point of self-hosting. End-to-end encryption does not change that, and it cannot: to run unattended backups at three in the morning, the Media Server has to keep the key for the cloud copy on that same machine. So somebody with root gets both the plaintext library and the key to the cloud copy.
This matters most if you do not fully control the hardware. A managed hosting provider, a VPS operator, or anyone else with administrative access to your server can read your library whether or not end-to-end encryption is enabled. End-to-end encryption protects the copy Cardinal holds. It is not a defence against your own host.
| Who | Non-E2E backup | End-to-end backup |
|---|---|---|
| Someone intercepting network traffic | Cannot read it | Cannot read it |
| The storage operators | Cannot read it | Cannot read it |
| Cardinal | Can technically read it | Cannot read it |
| Anyone with root on your server, including your hosting provider | Can read it | Can read it |
If the last row is in your threat model, the answer is controlling the hardware your Media Server runs on. No cloud backup setting substitutes for that.
What Cardinal staff can see
Cardinal's internal tools exist to run the service, so they show operational figures: how many bytes an account stores, how many files and snapshots exist, when the last backup ran, and how much restore coverage remains. Those tools are restricted to staff accounts. They contain no file browser, and no path to the contents of an end-to-end encrypted backup.
These are the questions people actually ask:
| Question | Answer |
|---|---|
| Can staff see how much you store, and when your backups ran? | Yes. These are the operational figures the tools exist for. |
| Can staff browse your file names or folder structure? | No. There is no file browser in any staff tool. |
| Can staff read the contents of a backup without end-to-end encryption? | Not through any tool that exists — but Cardinal holds the storage keys, so it is technically possible. Assume it is, if that matters to you. |
| Can staff read the contents of an end-to-end encrypted backup? | No. The stored data is ciphertext and the key never leaves your server. |
Why a compromised Media Server cannot destroy your backups
Ransomware that reaches a machine typically goes after its backups next. That path is closed here by construction rather than by policy:
- No client is issued a delete verb or an overwrite verb. A backup pass can only create data that does not already exist.
- Existing content cannot be replaced, because writes that would overwrite an existing object are rejected outright.
- Deletion happens only through Cardinal's control plane, which requires your Cardinal Account — not the token stored on the server.
- Deleted data is flagged first and removed permanently later, so even a mistaken deletion on Cardinal's side has a window in which it can be undone.
The worst a fully compromised Media Server can do is upload junk, and that is bounded by your storage quota. It cannot corrupt, overwrite or erase what is already backed up. The full deletion path, including the cooldowns, is described in Deletion and retention.
Integrity
Every file is stored under a name derived from a hash of its own contents, which makes a mismatch between name and content detectable at any point. On restore, each file is hashed again after download and checked against the manifest before it is written to disk. The manifest itself has its hash recorded by Cardinal at the moment the snapshot is committed, so a manifest altered afterwards does not go unnoticed.
With end-to-end encryption on, each chunk also carries an authentication tag, and chunks are bound to their position in the file. Tampering, reordering and truncation all fail verification rather than silently producing wrong data.
Related pages
- Secure Backups — setup, scheduling and what gets backed up
- Restoring — including the passphrase prompt on a fresh server
- Deletion and retention — how stored data is removed
Was this article helpful?