What your backup is actually storing

Most people turn on phone backup once, during setup, and never think about it again. That’s the point of it: it’s supposed to be invisible. But “invisible” also means most people have no idea what’s actually sitting in that backup, who can technically get to it, and under what conditions. Here’s what’s actually in there and how the encryption around it really works.

What actually ends up in a phone backup

A full device backup is not just your photos. Depending on your settings, it typically includes:

• Text messages and iMessage/RCS history, including attachments
• Call logs
• Contacts
• App data, which can mean chat databases, saved logins inside apps, and cached content from apps that don’t obviously look like they store anything sensitive
• Photos and videos, along with their metadata (location tags if you have location on for the camera app)
• Health app data on iOS, or fitness and step data on Android
• Saved Wi-Fi network names and passwords
• Your keychain or password manager vault, if it’s built into the OS
• Voicemail, in some configurations
• Device settings and, on iOS, some Apple Watch data

Notifications people usually forget: a backup is a snapshot of app data as it sits on the device, not just what you’d see in a chat window. If an app stores a local database of your messages (and most do, that’s how offline access works), that database gets swept into the backup wholesale. Deleting a message from your view doesn’t always mean it’s gone from that underlying file at the moment the backup runs.

The difference between encrypted and end-to-end encrypted

This is the part that actually matters, and it’s also the part most explanations get muddy on.

“Encrypted” on its own just means the data is scrambled using a key. It says nothing about who holds that key. Standard cloud storage, including standard iCloud and Google backups, is encrypted at rest on the provider’s servers, but the provider holds the decryption key. That’s what lets you log into a new device and have your backup just work: the service can decrypt it for you.

“End-to-end encrypted” (E2EE) means the key is derived from something only you control, usually your device passcode or a key that never leaves your device. The provider stores the encrypted blob but cannot decrypt it, because it doesn’t have the key. If you forget your passcode and have no other recovery method, an E2EE backup can be permanently unreadable, including to the company storing it. That’s not a bug, it’s the actual mechanism working as designed.

Apple’s Advanced Data Protection extends end-to-end encryption to iCloud Backup and most categories of iCloud data, when you turn it on. Without it, a standard iCloud Backup is encrypted at rest but decryptable by Apple. On Android, Google backs up app data and photos with encryption in transit and at rest, and for some backup categories (Google’s end-to-end encrypted backup for select data, keyed to your screen lock) Google itself can’t read it. But this isn’t universal across every category of data Android backs up, and coverage has changed over time, so it’s worth actually checking your settings rather than assuming.

Turning on end-to-end backup encryption doesn’t make your phone “private” as a blanket statement. It changes who can decrypt one specific pool of data (your cloud backup) under normal circumstances. It doesn’t touch what apps themselves collect, what your carrier logs, or what’s visible to anyone who has your unlocked device in hand.

Who can actually get to a standard backup

With a standard (non-E2EE) cloud backup, access generally requires one of a few things: your account credentials, a device already signed into your account, or the cloud provider itself acting on the data it holds the key for. That last case matters for legal process: a provider that holds the decryption key is technically capable of producing readable data from it in response to a valid legal request, because the key sits on their side, not yours. This is a description of how the technical custody of a key works, not advice about your legal situation, and it varies by provider, jurisdiction, and what specific data category is being requested.

Account compromise is the more common real world risk. Phishing for an Apple ID or Google account password, or SIM-swapping to intercept an SMS-based recovery code, gives an attacker the same access a legitimate sign-in would. This is why the account credentials protecting your backup often matter more day to day than the backup’s encryption model.

Messaging apps aren’t automatically excluded

A common assumption is that a messaging app marketed around privacy or disappearing messages is somehow exempt from device backup. It usually isn’t, unless the app specifically opts its data out of the OS backup system or uses its own separate encrypted backup mechanism with a key you control. If an app stores messages in a local database and doesn’t explicitly block that database from being included in the system backup, that data rides along in your iCloud or Google backup like everything else, under whatever encryption model that backup uses. Check the specific app’s own documentation on backups rather than assuming the app’s privacy marketing extends to how the OS backs it up.

What local backups change

An encrypted local backup, made through Finder on a Mac or through a wired connection with backup encryption turned on, stores the same categories of data but keeps them on a drive you physically control instead of a company’s servers. The encryption key is a password you set, not tied to your cloud account. This removes the cloud provider from the picture entirely for that copy, but it introduces a different failure mode: if that drive is lost, stolen, or fails, and you don’t have another copy, the backup is gone (and if you forget the password, it’s unreadable to you too). It also means you lose the convenience of restoring a new phone by just signing into an account.

Neither approach is strictly better. They trade different things: convenience and cross-device sync against who else, if anyone, technically has custody of a decryption key.

What’s actually worth doing

None of this is a case for turning off backups altogether. A backup exists to protect you from losing a decade of photos when a phone gets dropped in a lake, and that’s a real, common failure mode, not a hypothetical. The more useful move is matching your setup to what you’re actually worried about, rather than either ignoring it or assuming the default settings are minimal by design (they’re usually not; they’re set for maximum convenience).

A few concrete things worth actually checking rather than assuming: whether Advanced Data Protection is on if you’re on iOS, whether your Android backup includes end-to-end encrypted categories or standard ones, whether the account protecting your backup has a strong password and a non-SMS two-factor method, and whether any specific app you use for sensitive conversations has its own backup opt-out or separate encrypted export. Reading through your phone’s own backup settings menu once, and seeing exactly what toggles exist, tells you more than most general advice will.

No single setting here makes your phone “private” in some absolute sense, and nothing in this list makes data untraceable or guarantees nobody can ever get to it. What changes is the specific, narrow set of conditions under which a specific pool of data is readable to someone other than you. That’s a smaller claim than most privacy advice makes, but it’s the one that’s actually true.

If you want more breakdowns like this that stick to how things actually work instead of what sounds reassuring, check out the rest of The Privacy Wire.