A mobile backup is a product-defined collection, not a promise that every item on a device is present. The evidence question should name the application, data type, relevant account, collection method, and time interval. An absent message in one backup does not independently establish that the device never held that message.
Identify the specific collection
Record the device model, operating-system build, application versions, collection tool and version, acquisition start and end, backup type, and relevant encryption state. Preserve collection logs and manifests alongside output. Distinguish a device-generated backup from an app export, a service download, or a forensic tool's logical acquisition. Similar presentation in an analysis interface does not make their scope equivalent.
Read the platform's exclusions
Apple’s backup-methods documentation distinguishes iCloud and computer backups and lists excluded categories. It explains that some synchronized iCloud information is outside an iCloud backup, and that encrypted computer backups have different coverage from unencrypted ones. Determine the method used rather than applying one list of exclusions to every iPhone acquisition.
Android’s Auto Backup documentation describes application backup eligibility, inclusion and exclusion rules, quotas, and version-dependent configuration. App developers can affect what participates. This is documentation about Android backup behavior, not a description of every commercial extraction product. A device-to-device transfer and a cloud backup can also follow different rules.
Separate four times
Keep the device's recorded event time, the backup creation interval, the export or download time, and the analyst's examination time. A service export obtained later may represent server state different from an earlier device backup. Do not overwrite that difference by placing both under one evidence date.
Document whether the source was a current backup, a pre-existing backup, or a restored copy. Restoring and opening an application creates a new operational state; it should not silently substitute for analysis of the preserved original collection.
Build an application coverage table
| Field | What to record |
|---|---|
| Application and account | Installed build, profile, and account identifiers visible in the collection. |
| Expected data type | Messages, attachments, settings, or other specifically scoped content. |
| Collection mechanism | Backup, app export, service export, or another documented method. |
| Observed limitations | Exclusions, errors, missing files, access limits, and unsupported formats. |
Compare a significant finding with an authorized server record, another participant's collection, or an independently preserved object when available. Such comparison can strengthen an activity interpretation, but different participants may have different content and retention. State that limitation rather than demanding identical histories.
Write a bounded absence finding
Ordinary alternatives include data residing in a synchronized service, application exclusions, an incomplete or older backup, unsupported parsing, and a different profile. Record which were checked. A useful statement is “No matching attachment was located in the supplied logical export; the application's server-side content was outside this examination.”