DeviceBackupVerification2026

iPhone Backups: What Is (and Isn't) in a Backup

A backup is a point-in-time snapshot you restore from — it always holds some things, holds others only if you configured it, and never holds a third set, and an unverified backup is a hope, not a net. Here is the restore-verification reframe, the three-tier inclusion ledger, the freshness-decay clock, the two backup routes, the backup anatomy, and the unverified-backup boundary. The page is a verification discipline, not a cynicism about backups; a backup is genuinely useful, the device's own settings are the authoritative surface, and the discipline is to name the tier before you rely on the net — because some items are always in, some only if configured, and some never in — to check the backup's date against the item's creation date (a snapshot decays), to prove the net with a restore test, and to keep a backup distinct from a sync (127) and from an export (120).

General information only — not a statement of any universal contents list, retention period, encryption behaviour, or route mechanic, not an export guide, not an erasure task, and not a device-specific menu path. This page explains the shape of a backup-contents read — the restore-verification reframe, the three-tier inclusion ledger, the freshness-decay clock, the two backup routes, the backup anatomy, and the unverified-backup boundary — in broad terms. What a backup contains, which tier each item sits in, whether Health/password/other sensitive data are included, whether the backup is encrypted, the route (computer versus cloud) and its contents and restore mechanics, the retention of old backups, the recency requirement, and the menu paths vary by device, model, OS version, region, account, plan, route, and manufacturer, and they change over time; they belong to the device's own backup settings, the OS vendor's support documentation, the manufacturer, and a data-protection or consumer-protection authority — not a guide page. And the load-bearing limits: a backup is a point-in-time snapshot you restore from, and its completeness decays from the moment it is taken, so a stale backup misses recent items and the restore point drifts; items sit in one of three tiers (always in / only if you configured it / never in), and the never-in tier is the loss zone — the categories people assume are covered but are not; an unverified backup is a hope, not a net, and the restore-verification test (confirm recency, check size and date, and where stakes are high test a restore) is the load-bearing move; the backup route (computer versus cloud) decides the contents and the restore mechanics, and some sensitive data may require an encrypted computer backup; a backup is not a sync (127 — a live mirror that propagates deletes) and not an export (120 — a readable copy you take elsewhere), and conflating them is the wrong-tool loss; and the page asserts no universal contents list, no universal retention, and no 'your backup is complete' promise. The discipline is to name the tier, check the clock, prove the net, and keep the three tools distinct.

A plain blank paper sheet lying beside a small unmarked empty plain open mesh pouch holding a few plain blank smooth stones, with one plain blank stone left outside the pouch resting on the sheet, on a clean light surface — The blank sheet beside the small unmarked empty plain open mesh pouch holding a few plain blank smooth stones, with one plain blank stone left outside on the sheet, is the contents gap made physical: the pouch is the backup, the stones inside are the always-in and only-if-configured tiers, and the single stone outside is the never-in tier — the item you assumed was covered but is not. The mesh is see-through on purpose, because a backup you can inspect is a net you can trust, and the most common loss is reaching for the stone outside the pouch at the moment of restore and finding the pouch never held it.

Updated October 2026By the AI Help Guide editorial team11 min read

The Stone Outside the Pouch

The Most Common Loss Is Not a Missing Backup — It Is the Backup That Was There but Never Held the Thing You Needed

The mental image of "I have a backup" is a single safety: the net exists, so the fall is caught. The image is comforting and it is exactly what fails, because a backup is not a uniform net; it is a point-in-time snapshot with a three-tier contents map, and the tier an item sits in decides whether the net holds it. Some items are always in (many device settings and app data); some are in only if you configured it or only on certain routes (Health and password data often require an encrypted computer backup; some app content is re-downloadable rather than backed up); and some are never in (the contents of the recently-deleted window once it expires, certain logged-in sessions, and items that live only in the cloud or only on another device). The most common loss is not a missing backup. It is the backup that was there but never held the thing you needed — the reader who reached for the restore after a loss and found the photo, the message, the Health record, or the login was in the never-in tier, or was created after the last snapshot and so was in no tier at all. And the second loss is the unverified net: the reader who trusted a backup they had never tested, and discovered it was stale, partial, or corrupt at the worst possible moment — the restore. A backup you have not verified is a hope, not a net.

This page is the contents half of the Apple device series; its companions, the photos-location guide, the updates guide, the export-or-delete guide, the storage guide, and the Apple-ID guide deal with where a photo lives, the net beneath a leap, the portable copy, the live stock, and the master key. The restore-verification reframe below imports the state-naming-before-the-action discipline our photos guide built and the net-beneath-the-leap posture our updates guide built, and *adds the contents tier the location model never had*: 127 taught that a photo lives in one of three locations (device / cloud / both); 128 teaches that an item sits in one of three inclusion tiers (always / only-if-configured / never) — and the never-in tier is the loss zone 127 could not express, because a backup excludes categories people assume are covered. 125's backup-before-major boundary said "keep a pre-update backup"; 128 is the page that boundary depends on — it decodes what is in the net and whether the net holds (the restore-verification test). And it ends where those guides did not have to: with the freshness-decay clock and the three-tools-distinct guardrail, because the most common loss is the backup that never held the thing, and the second is the sync mistaken for a backup (127) or the backup mistaken for an export (120) — and a page that taught the contents without teaching the clock and the verification would be handing out a pouch with no map of which stones are inside and no test of whether it holds.

The restore-verification reframe — a backup is a point-in-time snapshot with a three-tier contents map, an unverified backup is a hope not a net, and the restore-verification test is the load-bearing move. I have a backup, so I'm covered — whatever I lost will come back when I restore. A backup holds some items always, some only if you configured it or only on certain routes, and some never — and it is a snapshot, so anything created after the last backup is not in it. An unverified backup is a hope: you discover it is stale, partial, or corrupt at the restore. The discipline is to name the tier before you rely on the net, to check the backup's date against the item's creation date, and to prove the net with a restore test where the stakes are high. This is the reframe the page exists to make, and it is the most carefully hedged line in the batch, because the naive version — "a backup means I'm covered" — leads a reader to trust a net they never tested, to assume a never-in item is in, and to discover the gap at the worst moment, while the second naive version — "the sync is my backup" — leads a reader to trust a live mirror that propagates deletes (127).

The honest position is neither paranoia nor simplicity: a backup is genuinely useful, most items resolve into a clear tier, and a current verified backup is a real net. But the three-tier map is real, the snapshot decays, and the unverified net is a hope, so the discipline is to name the tier, check the clock, prove the net, and keep the backup distinct from a sync (127) and an export (120). The page teaches the contents read and the verification test; it does not assert your contents list, your retention, or your route's specifics, because those are the manufacturer's and your own settings' to state. The most common loss is the backup that never held the thing, and the second is the unverified net discovered at the restore.

Tier 1 — Always in the backup

The reliable core: present on most routes without special configuration.

Device settings and configuration
Many apps' local data and documents
The home-screen layout and app arrangement
Some messages and call history (route-dependent)
The read: this tier is the net's floor — but "always" is the manufacturer's to state, and the route can move an item out of it

Tier 2 — Only if you configured it (or only on certain routes)

The conditional middle: in the net only if you set the switch or chose the route that covers it.

Health and fitness data (often requires an encrypted computer backup)
Saved passwords and some sensitive settings (often encryption-gated)
Some app content that may be re-downloadable rather than backed up
Items that depend on the route (computer vs cloud) or a toggle you must turn on
The read: this tier is where "I thought it was backed up" usually breaks — the switch you never flipped

Tier 3 — Never in the backup (the loss zone)

The excluded set: the categories people assume are covered but are not, on any route.

Contents of the recently-deleted window once it has expired (127)
Certain logged-in sessions and some security-gated data
Items that live only in the cloud or only on another device (not local to back up)
Some purchased/licensed content that is re-downloadable via the account, not stored in the backup (115)
The read: this tier is the page's distinctive payload — the stone outside the pouch — and reaching for it at the restore is the most common loss

Schematic only — the three tiers are the shape of a backup's contents map, not your device's list or any universal catalogue. Which tier a given item sits in depends on the route (computer vs cloud), the settings, the OS version, and the manufacturer's current behaviour, and it changes over time; the device's own backup settings are the authoritative surface. The point of the ledger is the third tier: the never-in zone is where "I have a backup" silently fails, and the most common loss is reaching for an item there at the moment of restore. Name the tier before you rely on the net.

The three-tier ledger is the page's entire reframe compressed into one vertical list, and its power is that it converts a binary ("backed up or not") into a positional read with a loss zone. The reader's instinct is to treat the backup as a uniform net; the discipline is to ask which tier is this item in — always (the floor), only-if-configured (the switch you may not have flipped), or never (the stone outside the pouch). The `.always` / `.cond` / `.never` left-border colours are deliberate: green is the reliable core, amber is the conditional middle where "I thought it was backed up" usually breaks, and red is the loss zone the page exists to name. The tiers are not your catalogue; your device's own backup settings are, and the page routes the specifics there rather than asserting a universal contents list. The distinctive payload versus 127 is the third tier: 127's three locations all hold the photo somewhere; 128's third inclusion tier holds it nowhere — and that is the gap a location model cannot express.

fresh — captures everything up to here drifting — recent items not yet in stale — the restore point is far behind your life

Schematic only — the clock is the shape of a snapshot's decay, not a universal interval. A backup is a point-in-time copy: everything created, changed, or deleted after the "snapshot taken" pin is not in it until the next backup runs, so completeness decays and the restore point drifts from green (fresh) to red (stale) as time passes. The discipline is to check the backup's date against the item's creation date before assuming coverage, and to keep the net current — because a backup that has not run in days is a days-old picture, not a live one, and the item you lost yesterday may be in no tier of a week-old snapshot.

The freshness clock is the page's temporal payload, and its power is that it converts a static "I have a backup" into a decaying snapshot with a drift. The reader's instinct is to treat the backup as a standing fact; the discipline is to see that the net's completeness is a function of when it last ran versus when the item was created, and that the gap between the two pins is the uncovered window. The `.taken` and `.due` pins and the green→red gradient are deliberate: the snapshot is a single moment, and everything after it is, until the next run, in no tier at all. The clock is not a universal interval; your device's own backup schedule and the manufacturer's behaviour are, and the page routes the specifics there. The distinctive consequence is the stale-backup tell: the reader who lost a photo created after the last snapshot and assumed the backup covered it, only to find the restore point days behind their life.

The computer / local backup route

The object — a copy made to a computer over a cable or local connection
The contents — often broader, and may include sensitive data (Health, passwords) if encrypted
The encryption choice — an unencrypted local backup may omit or expose sensitive data; encrypting is a decision with a password you must not lose
The restore — from the computer; depends on the computer being available and the backup uncorrupted
The catch — the net is only as good as the computer holding it and the encryption password you kept
The route decides the contents and the restore mechanics; read the device's own settings for what this route actually holds

The dividing line is the route: a computer/local backup and a cloud backup are two different nets with different contents, different encryption behaviour, and different restore mechanics — and an item can be in one route's tier and not the other's. The most common loss is assuming "backup" is one thing and that whichever route you never configured still covers the sensitive set. The discipline is to name the route you actually use, to check whether the sensitive items (Health, passwords) are in that route's tier or require the other route or an encryption toggle, and to keep the encryption password itself backed up somewhere you can reach — because a lost encryption password can make an encrypted backup unreadable, a loss inside the net.

The cloud backup route

The object — a copy made automatically to the account's cloud storage
The contents — device settings and a defined set; may not include everything the local route can, and depends on the account quota (120/127)
The convenience — automatic, no computer required, restorable to a new device signed into the account
The dependency — the account and the quota gate the net (the Apple-ID and photos guides' access-route point)
The catch — a full quota or a lost account can strand the net out of reach
The route decides the contents and the restore mechanics; read the device's own settings for what this route actually holds

The two bands and the divider are the page's route model in one distinction, and its power is that it converts a single "backup" into two different nets with different tiers and different failure modes. The failure mode the split prevents is the sympathetic one: a reader who relied on the cloud route for convenience, never encrypted a local backup, and then found the Health and password data were in neither route's tier — the cloud route never carried them, and the local route was never made. The discipline is to name the route you use, to check whether the sensitive set requires the other route or an encryption toggle, and to keep the encryption password reachable (a lost password can make an encrypted backup unreadable — a loss inside the net). And the honest limit is that the contents and restore mechanics of each route are the manufacturer's to state on your device's own settings; the page teaches the route model, not the catalogue.

The backup-audit sequence — name the route, read the tiers, check the clock, prove the net, and keep the three tools distinct

Name the route you actually use — computer/local or cloudOpen the device's own backup settings and find out which route is on: a computer/local backup, a cloud backup, or both. The route decides the contents tiers and the restore mechanics, so naming it first is the load-bearing move — an item can be in one route's tier and not the other's.

The two-route bands in action: "backup" is not one thing; the route you never configured may be the one that holds the sensitive set.

Read the three tiers for the items you care about — always / only-if-configured / neverFor the irreplaceable set, ask which tier each item sits in on your route: always in (the floor), only if you configured it (the switch you may not have flipped — Health, passwords often encryption-gated), or never in (the loss zone — expired recently-deleted, cloud-only items, re-downloadable licences). Name the tier before you rely on the net.

The `.inout` ledger in action: the most common loss is reaching for a never-in item at the restore, or for a conditional item whose switch you never flipped.

Check the clock — the backup's date against the item's creation dateA backup is a snapshot, so completeness decays from the moment it was taken. Check the last-backup date and time against when the item was created or last changed; if the item post-dates the snapshot, it is in no tier until the next run. Keep the net current, or keep a separate net for the irreplaceable set.

The `.snapclock` in action: a week-old backup is a week-old picture, and the photo you took yesterday may be in none of its tiers.

Prove the net — the restore-verification testAn unverified backup is a hope. Confirm the backup ran recently, check its size and date against expectation, and where the stakes are high, test a restore of a non-critical item or to a spare device, so the net is proven before you fall. Do not discover a stale, partial, or corrupt backup at the worst moment — the real restore.

The restore-verification reframe in action: the test is the move that converts a hope into a net, and it is the page's load-bearing discipline.

Handle the encryption choice and keep the password reachableIf the route offers encryption, decide knowingly: an encrypted local backup may be the only way sensitive data (Health, passwords) is included, but a lost encryption password can make the backup unreadable — a loss inside the net. Keep the password somewhere you can reach it (and that is itself a thing to back up), and read the device's own settings for what encryption actually gates.

The encryption paradox: the switch that includes the sensitive set is the same switch that can lock you out of it, so the password is part of the net.

Keep the backup distinct from a sync (127) and an export (120)A backup is a copy you restore from (often opaque, for recovery); a sync is a live mirror that propagates deletes (127); an export is a readable copy you take elsewhere (120). Three different jobs. Treating a sync as a backup is the mirrored-delete loss; treating a backup as an export is the wrong-tool loss. Route the location model to the photos guide and the portability/erasure task to the export guide.

The three-tools-distinct guardrail: the net, the mirror, and the portable copy are not interchangeable, and conflating them is a common and avoidable loss.

Check the quota and the account that gate the cloud route (120/127/129)If you use the cloud route, the account and its quota gate the net: a full cloud storage can stop the backup, and a lost or compromised account can strand it out of reach (the Apple-ID guide's master-key point). Check the account's storage status beside the device stock (122), and secure the account (129) as a backup-preservation move.

The 127/120 import: a cloud net is gated by the account, so the quota warning and the account security are backup issues, not just billing and login issues.

The vector

A reader who expected a backup to produce a readable, portable copy of specific data, or who treated an export as a restore net.

The catch

A backup is often opaque and for recovery; an export is a readable copy you take elsewhere (120); an erasure removes data (120). Three jobs. Route the portability/erasure task to the export guide and keep the backup for restore.

Surface	What it holds	The tier / behaviour	The catch
Always-in tier	Device settings, many app data	The floor, on most routes	Not the ceiling; route can move items out
Only-if-configured tier	Health, passwords, some app content	In only if switched on / route covers it	The switch you never flipped; often encryption-gated
Never-in tier	Expired recently-deleted, cloud-only items, re-downloadable licences	Excluded on any route	The stone outside the pouch; keep a separate net
Freshness clock	A point-in-time snapshot	Completeness decays from the taken moment	Check backup date vs item creation date; keep current
Encryption + password	May gate sensitive-set inclusion	Lost password can make the net unreadable	The password is part of the net; keep it reachable
Computer/local route	Often broader; restore from the computer	Encryption-gated sensitive data	Net only as good as the computer and the password
Cloud route	Settings + a defined set; auto, account-gated	Restorable to a signed-in device	Quota and account gate the net (120/127/129)
Restore-verification test	Proof the net holds	Converts a hope into a net	Unverified = discovered stale at the real restore
Not a sync (127)	A snapshot, not a live mirror	A sync propagates deletes both ways	Run the mirror test; irreplaceable set needs this net
Not an export (120)	Opaque, for restore	An export is a readable portable copy; erasure removes	Three jobs; route portability to 120

The anatomy is the same claims-vs-mechanism habit the payslip, bill, and photos guides taught, applied to a net where the claim is "I have a backup, so I'm covered" and the mechanism is the three tiers, the clock, the encryption, the routes, the verification, and the three-tools-distinct guardrail. The always-in tier is not the whole net. A conditional item is not in until you flip the switch. A never-in item is the stone outside the pouch. A snapshot decays. A lost password can lock you out of the net. A route is not the other route. An unverified backup is a hope. A sync is not a backup. An export is not a restore net. The discipline is the anatomy: read the tier, check the clock, prove the net, and keep the three tools distinct — because the most common loss is the backup that never held the thing, and the second is the unverified net discovered at the restore.

The backup tells — the assumptions that break the net

"I have a backup, so I'm covered" "everything is always in the backup" "Health and passwords are backed up by default" "the backup includes what I made yesterday" "the cloud sync is my backup" "a backup gives me a readable copy of any item" "encrypting it is safe even if I lose the password" "one route covers what the other route holds" "I'll find out if it works when I need it" "the recently-deleted item is in the backup"

The tells are the net-breaking assumptions, and the discipline is to read them as the three tiers, the clock, and the verification test rather than as prudence. The first three tells are the tier errors — "covered" treats the always-in floor as the whole net; "Health and passwords by default" ignores the only-if-configured middle; "includes what I made yesterday" ignores the snapshot decay. The sync and export tells are the three-tools-distinct conflations (127/120). The password tell is the encryption paradox — a lost password can lock you out of the net. The one-route tell is the route error. The "find out when I need it" tell is the unverified-net error the page exists to prevent — you discover a stale or corrupt backup at the worst moment. And the recently-deleted tell is the never-in loss zone (127). The safe posture is the backup audit: name the route, read the tiers, check the clock, prove the net, handle the encryption, keep the three tools distinct, check the quota and account, and re-audit — because the most common loss is the backup that never held the thing, and the second is the unverified net discovered at the restore.

The unverified-backup-is-a-hope boundary — a backup you have never tested is a hope, not a net, and the restore-verification test is the load-bearing move that converts one into the other. You discover a stale, partial, or corrupt backup at the worst possible moment — the real restore — so the net must be proven before you fall.

Confirm recency. Check the last-backup date and time; a snapshot that has not run in days is a days-old picture, and recent items may be in no tier.
Check size and date against expectation. A backup that is suspiciously small, or whose date has not moved, is a tell that the net is not forming — a failed run, a full quota, a turned-off route.
Test a restore where the stakes are high. Restore a non-critical item, or the whole net to a spare device, so the net is proven before you rely on it. The test is the move that converts a hope into a net.
Keep the password and the account that gate the net. An encrypted local backup needs its password (a lost password can make the net unreadable), and a cloud backup needs the account and the quota (129/120/127) — both are part of the net, not separate concerns.

The contents tiers, the retention, the encryption behaviour, the route mechanics, and the restore process are the manufacturer's to state on your device's own backup settings and the OS vendor's support documentation; the location model belongs to the photos guide (127) and the portability/erasure task to the export guide (120). This page's job is one sentence long: name the tier, check the clock, and prove the net before you fall. A page that taught the backup without teaching the verification would be handing out a pouch with no map of which stones are inside and no test of whether it holds — the contents gap and the unverified net, in one package.

A worked example: the two readers, and the one who proved the net

Concretely, the restore-verification reframe, the three-tier inclusion ledger, the freshness-decay clock, the two backup routes, the backup anatomy, the backup tells, and the unverified-backup-is-a-hope boundary meeting two readers who each "have a backup" and then lose something.

Reader one trusted an unverified net and found the gap at the restore. Their device was replaced after a fault, and they assumed the cloud backup covered everything. It did not. The Health and password data were in the only-if-configured tier — they had never encrypted a local backup, and the cloud route never carried them — so that set was gone. The photos they took in the last three days were in no tier at all, because the snapshot was three days old and the clock had drifted; the restore point was behind their life. And a document they had deleted last week and hoped to recover was in the never-in tier, because the recently-deleted window had expired (127). Reader one had never run a restore test, never checked the backup date against the item's creation date, and never read the tiers; they discovered all three gaps at the worst moment — the real restore. The loss is not the missing backup; it is the unverified net, the stale snapshot, and the never-in assumption.

Reader two named the tiers, checked the clock, and proved the net before falling. The same cloud backup, the same discipline-installing habit. Reader two opened the device's own backup settings and named the route (cloud, automatic), then read the three tiers for the irreplaceable set: the device settings and app data were in the always-in floor; the Health and password data were in the only-if-configured middle, so reader two also made an encrypted computer backup to cover them — and kept the encryption password in a place they could reach, knowing a lost password can lock you out of the net. They checked the clock: the last backup was current, and they confirmed the recent photos post-dated the snapshot were covered by the next scheduled run, keeping a separate net (the photos guide's irreplaceable-set backup, 127) for the one-of-a-kind shots so a stale snapshot could not strand them. They proved the net with a restore test of a non-critical item to a spare device, converting the hope into a net before they needed it. They kept the backup distinct from the cloud-photos sync (127 — a mirror, not a net) and from an export (120 — a portable copy, not a restore), and they checked the account quota and secured the account (129) because the cloud net is gated by both. When a fault later forced a real restore, the net held: the floor, the encrypted middle, the current clock, and the proven test all came good.

The lesson is the whole page. Both readers had a backup and the same loss risk; the difference was not the net but the read. Reader one trusted an unverified net, ignored the tiers and the clock, and discovered the gaps at the restore. Reader two named the route, read the three tiers, flipped the encryption switch for the conditional middle, checked the clock against the item's creation date, proved the net with a restore test, kept the three tools distinct, and secured the account and quota that gate the cloud net. The restore-verification reframe is what converted the hope into a net — an unverified backup is a hope, not a net — and the three-tier ledger is what named the gap before the fall. The honest limit is that the page cannot assert your contents tiers, your retention, your encryption behaviour, or your route mechanics, because those are the manufacturer's and your own settings' to state. The most common loss is the backup that never held the thing, and the discipline is to name the tier, check the clock, and prove the net before you fall.

The Check

A Sensible Default

Hold the reframe: a backup is a point-in-time snapshot with a three-tier contents map, and an unverified backup is a hope, not a net — the restore-verification test is the load-bearing move.
Read the three tiers before you rely on the net: always-in (the floor), only-if-configured (the switch you may not have flipped — Health and passwords are often encryption-gated), and never-in (the loss zone — expired recently-deleted, cloud-only items, re-downloadable licences).
Check the freshness clock: a snapshot decays from the moment it is taken, so check the backup's date against the item's creation date, and keep the net current or keep a separate net for the irreplaceable set.
Prove the net: confirm recency, check size and date against expectation, and where stakes are high test a restore of a non-critical item or to a spare device — do not discover a stale or corrupt backup at the real restore.
Name the route you use (computer/local vs cloud) and check whether the sensitive set needs the other route or an encryption toggle — the routes have different contents and restore mechanics.
Handle the encryption choice knowingly and keep the password reachable — a lost encryption password can make an encrypted backup unreadable, a loss inside the net.
Keep the three tools distinct: a backup (restore from) is not a sync (127 — a live mirror that propagates deletes) and not an export (120 — a readable portable copy); run the mirror test and route portability/erasure to 120.
Check the quota and account that gate the cloud net (120/127/129), and re-audit on a schedule, because a snapshot decays and tiers shift — the audit is a routine, not a one-time switch.
Assert no universal contents list, retention, encryption behaviour, or route mechanic; route the specifics to the device's own backup settings, the OS vendor's support documentation, the manufacturer, and a data-protection or consumer authority.

The honest takeaway is that a backup is a three-tier snapshot you must prove rather than a uniform net you can assume, and the discipline that converts a hope into a net is the backup audit: name the route, read the three tiers for the irreplaceable set, check the clock against the item's creation date, prove the net with a restore test, handle the encryption and keep the password, keep the backup distinct from a sync (127) and an export (120), check the quota and account that gate the cloud net (120/127/129), and re-audit on a schedule. For the location model this page's never-in tier references, see our photos guide; for the net-beneath-the-leap boundary this page fulfils, see our updates guide; for the portability and erasure task this page must not duplicate, see our export-or-delete guide; for the live stock this page's snapshot contrasts with, see our storage guide; for the master key and quota that gate the cloud net, see our Apple-ID guide; and for the actual contents tiers, retention, encryption behaviour, route mechanics, and restore process, see the device's own backup settings, the OS vendor's support documentation, the manufacturer, and a data-protection or consumer-protection authority — the authorities this page keeps routing you to, because the shape of the three-tier-snapshot-and-verification is durable, the specifics are not ours to assert, and the backup that never held the thing is the loss.

A plain blank paper sheet lying beside a small unmarked empty plain pair of separate plain blank glass jars, the nearer one filled with clear water to an unmarked line and the farther one empty, standing unjoined on a clean light surface — The blank sheet beside the small unmarked empty plain pair of *separate* plain blank glass jars, the nearer one filled with clear water to an unmarked line and the farther one empty, standing unjoined, is the freshness-decay clock made physical: the filled jar is the snapshot at the moment it was taken, the empty jar is the live device now, and the fact that they are *unjoined* is the point — unlike the photos guide's joined mirror jars (127), a backup is a separate copy that drifts, so the water level in the snapshot jar is a days-old picture, not a live one. The jars stay plain and unjoined on purpose — the lesson is that a backup is a point-in-time snapshot whose completeness decays from the moment it is taken, and the most common loss is reaching for the snapshot jar to find the thing you needed was poured into the live jar after the snapshot closed.

Common Questions

Frequently Asked Questions

What does an iPhone backup actually contain?

In three tiers, and naming the tier before you rely on the backup is the load-bearing discipline of the page. Some items are always in a backup (device settings, many app data); some are in only if you configured it or if the route covers them (Health and password data often require an encrypted computer backup; some app content may be re-downloadable rather than backed up); and some are never in a backup (the contents of the recently-deleted window once it expires, certain logged-in sessions, and items that live only in the cloud or only on another device). The exact tier a given item sits in depends on the backup route (computer versus cloud) and the settings, and it is the manufacturer's to state on your device's own surfaces — the page teaches the three-tier model and the verification test, not a universal contents list.

Is my backup enough, or should I verify it?

Verify it, and the restore-verification test is the load-bearing move of the page. An unverified backup is a hope, not a net — you discover a backup is incomplete or corrupt at the worst possible moment, the restore. The discipline is to confirm the backup ran recently, to check its size and date against expectation, and where the stakes are high, to test a restore of a non-critical item or to a spare device, so the net is proven before you fall. The page does not assert that any specific backup is complete; it teaches the test.

Why didn't my backup include my recent photos?

Because a backup is a point-in-time snapshot whose completeness decays from the moment it is taken — the freshness-decay clock. Anything created, changed, or deleted after the last backup is not in it until the next one runs, so a stale backup misses recent photos, messages, and settings. The discipline is to check the backup's date against the item's creation date before assuming it is covered, and to keep the backup current (or keep a separate net for the irreplaceable set, the cloud-photos mirror test's consequence). A backup that has not run in days is a days-old picture, not a live one.

Is a backup the same as iCloud Photos or an export?

No, and the three-goals split is a load-bearing guardrail. A backup is a copy you restore from (often opaque, for recovery); iCloud Photos is a live sync/mirror (deleting in one place deletes in the other, the cloud-photos guide's test); an export is a readable copy you take elsewhere (the export-or-delete guide). They are different jobs: a backup retains data for restore, a sync mirrors it live, an export makes it portable. Treating a sync as a backup is the mirrored-delete loss; treating a backup as an export is the wrong-tool loss. The page routes the location model to the photos guide and the portability/erasure task to the export guide.

Should I encrypt my backup, and what if I lose the password?

Encrypting is often the only way sensitive data (Health, saved passwords) is included in a computer/local backup, so for many readers it is the switch that moves those items from the never-in tier into the only-if-configured tier — but it carries a real risk: a lost encryption password can make the encrypted backup unreadable, which is a loss inside the net. The discipline is to decide the encryption choice knowingly, to keep the password somewhere you can reach it and to treat that password as part of the net (back it up too, by whatever safe means you use), and to read the device's own backup settings for what encryption actually gates on your route. The page does not tell you to encrypt or not — that is your decision against your own sensitivity and your own password-keeping — but it does say that the password and the net are one system, and losing one can lose the other.

How often should I back up, and how do I know the last one worked?

Often enough that the drift between snapshots is smaller than the loss you could tolerate — the freshness clock's consequence — and the device's own backup settings show the last-successful-backup date and time, which is the evidence to read. The discipline is to check that date against the items you care about (a photo created after the last snapshot is in no tier until the next run), to treat a backup date that has not moved, or a size that looks wrong, as a tell that the net is not forming (a failed run, a full quota, a turned-off route), and to prove the net with a restore test where the stakes are high rather than assuming the schedule ran. There is no universal interval the page asserts; the right cadence is yours to set against your own loss tolerance, and the verification test is what converts a schedule into a proven net.

I restored from a backup and some things were missing. Is the backup broken?

Not necessarily — and this is the three-tier read doing its work. A restore that is missing items is often not a broken net but an item that was in the never-in tier (an expired recently-deleted file, a cloud-only or other-device-only item, a re-downloadable licence that comes back through the account rather than the backup, 115/127), or in the only-if-configured tier whose switch you never flipped (Health, passwords, often encryption-gated), or created after the last snapshot (the clock). The discipline is to read the missing item's tier and date before concluding the backup failed: check the route, check the switch, check the snapshot date against the item's creation date, and only then, if a genuinely always-in item is absent, treat it as a failed or corrupt net and re-verify with a restore test. The page does not assert that any specific restore is complete; it teaches the tier-and-clock read that tells you whether the gap is the net's failure or the item's tier.

Ask our AI. Naming a tier, checking the clock, or proving the net? Tap the chat icon and tell us which route you use (computer/local or cloud), whether the backup is encrypted and you can reach the password, the last-backup date against the item's creation date, and which items are irreplaceable, and it can place each item in the three-tier ledger, read the freshness clock, run the restore-verification test, and flag the three-tools-distinct guardrail (127/120) and the encryption-password paradox — and it will never assert a universal contents list, retention, or route mechanic, or treat a sync as a backup or a backup as an export. It will route the location model to the photos guide, the portability/erasure task to the export guide, the account and quota that gate the cloud net to the Apple-ID guide, and the contents tiers and restore mechanics to the device's own backup settings and the OS vendor's support documentation.

More device & backup guides like this

We treat a backup as a three-tier snapshot you must prove rather than a uniform net you can assume — so the discipline is the backup audit: name the route, read the three tiers for the irreplaceable set, check the clock against the item's creation date, prove the net with a restore test, handle the encryption and keep the password, keep the backup distinct from a sync (127) and an export (120), check the quota and account, and re-audit on a schedule.

Explore All Guides

Keep Reading

MobileiCloud Storage vs iPhone Storage: Where Your Photos Really Live

MobileiPhone Software Updates: Should You Install Them Right Away?

SoftwareHow to Export or Delete Your Amazon Data

MobileApple ID and 2FA: The Account Behind Your iPhone

Sources:

Your device's own backup settings and the OS vendor's support documentation — what a backup contains, the computer/local versus cloud routes, encryption and the password, the last-backup date, the restore process, and the retention (contents, behaviour, and mechanics vary by device, model, OS version, region, and route; use your local documentation)

Your national data-protection or privacy authority — backups of personal and sensitive data, encryption, and your rights over the copy (the sensitive-data and password question; use yours)

Your national consumer protection authority — the remedy route when a backup or restore service fails (the failed-net question; use yours)

Other Projects

More from the creator

Explore two other projects from the same creator.

Titan Converter

A video conversion and frame-extraction tool.

Visit project →

The Shelf Games

A library of small games and interactive projects.

Visit project →