Recover
deleted photos.
With Claude.

Help me inspect a local backup of my own iPhone on my Windows PC or Mac for photo records, thumbnails, and recoverable media. Perform the work when your tools support it; otherwise explain exactly what I must do manually. Never claim a backup, query, or export succeeded without checking the result.

The goal is to discover what this backup contains, including records marked as Recently Deleted where supported. Do not promise recovery of permanently deleted photos or assume every cached image was deleted.

1. PREPARE THE BACKUP

Detect my operating system and execution environment first. Use commands, path syntax, and installed tools appropriate to Windows or macOS; do not assume Unix commands or a sqlite3 CLI are available. Python with its built-in sqlite3 module is suitable when installed. If running under WSL or Git Bash, resolve the actual Windows user profile and observed drive mounts instead of assuming the shell home is the Windows backup location.

Check for existing backups before creating a new one. Preserve older backups that could be replaced: use the backup app's Archive option when available, or copy the entire completed backup folder unchanged to a separate local location. Do not rename or move the source. An older backup may contain a photo that a newer backup does not.

If needed, guide me through connecting and unlocking my iPhone and trusting the computer. On Windows, use Apple Devices: select the iPhone, open General, choose the option to back up all device data to this computer, and select Back Up Now. For an older Windows setup using iTunes, use the device's Summary page, This Computer, and Back Up Now. On macOS, use Finder: select the iPhone, open General, choose the option to back up all device data to this Mac, and select Back Up Now. I will enter passcodes and passwords directly into Apple's interface, never into chat.

Do not disable existing backup encryption automatically. If this workflow cannot process an encrypted backup, explain that limitation and stop before changing encryption settings. An unencrypted backup is less protected.

Check available disk space and wait for the backup app to confirm completion. Backup creation writes data; the audit of the completed source must be read-only.

2. SELECT AND VALIDATE THE SOURCE

Check the applicable locations, expanding variables using the actual user's profile:
- macOS: ~/Library/Application Support/MobileSync/Backup/
- Windows with Apple Devices or Microsoft Store iTunes: %USERPROFILE%\Apple\MobileSync\Backup\
- Windows with older desktop iTunes from Apple: %APPDATA%\Apple Computer\MobileSync\Backup\

Verify which folders exist; a migrated or redirected installation may use a different location. If needed, use the app's Manage Backups / Show in Explorer or Show in Finder option when available, or ask me to locate the backup. Do not assume a nonexistent default path means no backup exists. Identify the newest completed backup for the intended device using available device and backup metadata. Do not rely solely on folder modification times. Ask me to choose if the device is ambiguous.

Read Manifest.plist and its IsEncrypted value. If encrypted, do not treat the stored files as plaintext. Confirm Manifest.db exists and inspect available Info.plist and Status.plist metadata. Record backup date, completion status, and iOS version where available. Stop if the backup is incomplete, unreadable, or changing.

3. PROTECT THE SOURCE AND MY PRIVACY

Create a unique audit folder at ~/photo_audit/<YYYY-MM-DD_HH-MM-SS>/ on macOS, or %USERPROFILE%\photo_audit\<YYYY-MM-DD_HH-MM-SS>\ on Windows, with separate working, exports, and reports directories. Resolve this to a real path and verify that it is not cloud-synced, including through OneDrive or iCloud Drive; ask for another destination if it is. Do not overwrite a previous audit.

Never edit, move, rename, delete, repair, or change permissions on source backup files. Copy databases and their matching -wal, -shm, or journal files, when present, into the working directory before opening them. Only copy a stable, completed backup. Record source-database SHA-256 hashes before analysis and verify them afterward.

Use local scripts for detailed processing and export. Keep images, filenames, personal identifiers, and detailed metadata in local reports, not tool output or chat. Return aggregate counts and minimal diagnostics. Do not upload backup files or media. Claude is a cloud service: prompts and any returned tool output may be processed remotely, so do not describe this as guaranteed offline or zero-data-transfer analysis.

4. INVENTORY PHOTO-RELATED FILES

Inspect the working Manifest.db schema before querying. Use read-only SQLite connections for analysis. Find relative paths containing PhotoData, Thumbnails, DCIM, or Photos.sqlite, case-insensitively.

Save inventory.csv with available fileID, domain, relative path, record type, resolved physical path, byte size, and existence status. Group counts by domain and logical parent folder. Separate regular files from directories and count overlapping matches once.

Resolve fileIDs using the backup's observed storage layout, including the usual first-two-characters/fileID layout where applicable. Verify each physical file exists. Log missing records rather than silently dropping them.

5. EXAMINE PHOTO RECORDS

Locate Photos.sqlite through the manifest. Copy it and associated sidecars together, preserving their database filenames. Inspect tables and columns because schemas vary by iOS version.

If ZASSET and ZTRASHEDSTATE exist, report their trash-state distribution and query ZTRASHEDSTATE = 1. Verify the interpretation for this schema; otherwise label the value without assuming its meaning. Recently Deleted is not equivalent to permanently deleted.

Save recently_deleted.csv with available asset identifiers, filenames, directories, media-type values, and creation, addition, or trash dates. Preserve raw timestamps alongside converted dates; verify each field's epoch and units and label the timezone. Keep unknown values explicit. Match records to physical files using reliable identifiers or paths and label uncertain matches.

6. EXPORT AND REPORT

Estimate required space, then copy discovered media and thumbnails into exports, preserving domain, logical directory structure, and available filenames. Prevent path traversal, symlink or Windows junction escapes, and name collisions. On Windows, handle invalid characters, reserved names, case-insensitive collisions, and path-length limits; record any filename changes so each export remains traceable to its original logical name. Never move source files. Retain unfamiliar cache formats unchanged instead of inventing extensions or image counts.

Create export_manifest.csv with source fileID, logical path, destination, size, SHA-256, and export result. Create summary.md reporting matching records, available files, folder counts, thumbnail files versus containers, trash-state records, successful exports, bytes, missing files, failures, and oldest/newest valid asset dates with their field names. Include source-hash checks and output locations.

If useful media is missing, offer to inspect older preserved backups separately. Explain that backup exclusions and iCloud Photos can limit available content. A thumbnail is not necessarily a full-resolution original; an unmatched cache file is not proof of deletion; no results do not prove no remnants exist elsewhere. Do not restore the phone, delete caches, alter the photo library, or perform cleanup.