iBackupExtractor: A Rust CLI for Pulling Files Out of iOS Backups

The Problem: iOS Backups Do Not Preserve File Paths

When you back up an iPhone or iPad, the files are stored in a flat structure inside a directory that contains a Manifest.db database. The original directory layout, like the app sandbox paths, is not visible directly. If you need a single file from a specific app, you have to dig through a mess of hashed filenames. iBackupExtractor solves that by reading the manifest and reconstructing the original paths. It is aimed at users who want to inspect or recover files from a backup without restoring the whole device. The README states that the tool can extract all files from a backup archive, letting you view the sandbox filesystem as it was originally stored. That is the core value: turning an opaque backup into a browsable directory tree.

How It Works: Reading Manifest.db and Reconstructing Domains

The tool relies on the Manifest.db file inside the backup archive. That database contains the mapping between the stored files and their original paths, grouped by iOS domains. The info subcommand reads archive-level metadata such as timestamps, device and iTunes metadata, and total file counts. The list-domains subcommand aggregates that data by domain and sorts by the amount of exportable data. Extraction then walks the manifest, copies or links files to a destination directory, and recreates the original folder structure. The migrate command does the same but writes into another backup archive instead of a plain directory. The README emphasizes that Manifest.db is opened in read-only mode except during migrations, which means the tool can work even when the archive is on a read-only filesystem like HFS+ on Linux. That is a thoughtful design choice for a recovery tool.

Getting It Running: Cargo Build and Three Subcommands

The project is written in Rust and builds with Cargo. The README gives a single command: cargo build --release. Pre-built binaries are available for macOS from the GitHub releases page, but Linux users must compile from source. After building, you get a binary named ibackupextractor. The usage pattern is consistent across subcommands. First, locate the backup archive, which is a directory containing Manifest.db. The info subcommand takes the archive path and prints summary information. The list-domains subcommand shows all domains in the archive, sorted by exportable data size. The extract subcommand takes either -d for a specific domain or --all to extract everything, followed by the archive path and a destination directory. For example, ibackupextractor extract --all /path/to/backup /path/to/dest. The migrate subcommand transfers a domain from one backup to another, preserving the directory structure. All commands follow a positional style, which is simple but requires remembering the order.

Limitations: Encrypted Backups Are Not Supported

The most significant limitation is that the tool can only handle unencrypted backup archives. The FAQ explicitly states this. If your backup is encrypted, you must disable encryption in iTunes or Finder before creating a new backup. That is a hard requirement, not a config option. Another limitation is that the extract command fails if it tries to write over an existing file. The README recommends an empty destination directory. That is safe but inconvenient if you want to update an extraction. Also, the tool does not modify the source archive for info, list-domains, or extract, which is good, but migrate writes to the destination archive, so you need read/write access there. The read-only mode for Manifest.db is a nice touch, but it does not protect against your own mistakes if you point the tool at your only copy of a backup. The README warns: never work on the only copy of your data.

A Real Alternative: Manual SQLite Queries or Other Extractors

If iBackupExtractor does not fit, you can query Manifest.db directly with sqlite3. The database is a SQLite file, and you can write your own queries to map file IDs to paths. That gives you full control but requires knowing the schema, which the README does not document. Another alternative is to use a commercial tool like iMazing or PhoneView, which offer GUI-based extraction and support encrypted backups. The difference in approach is that those tools handle the encryption and provide a polished interface, while iBackupExtractor is a minimal CLI that assumes an unencrypted archive. If you need encryption support or a graphical interface, those alternatives are better. If you prefer a scriptable, lightweight tool, iBackupExtractor is a reasonable choice, but you must handle the encryption problem yourself.

Maintenance and License: A Small, Stable Snapshot

The project is licensed under MIT, which permits free use and modification. The last push was in September 2023, and the only release is v0.1.0 from the same date. This is not an actively maintained project. The README is clear and complete for the current feature set, but there is no roadmap, no issue tracker activity visible in the material, and no indication of future development. The tool is a single-purpose utility, and its stability is a double-edged sword. On one hand, a simple tool that does one thing well does not need frequent updates. On the other hand, iOS backup formats can change with new iOS versions, and without maintenance, the tool may stop working with future backup formats. The MIT license means you can fork it and fix issues yourself, but you should be prepared to do that if you rely on it long-term.

Who Should Use It and What to Verify First

iBackupExtractor is for users who have unencrypted iOS backups and want to extract files without restoring a device. It is especially useful for developers or power users who need to inspect app sandbox data. The tool is not for users with encrypted backups, nor for users who need to modify the source archive. Before using it, verify that your backup is unencrypted, that you have read access to the archive directory, and that you have a copy of the backup to test on. The README warns against working on the only copy, so make a backup of the backup. Also, decide whether you want copies or symbolic links. The -L option creates links, which saves disk space but can be confusing if you move the destination. The migrate command is a niche feature, but it is useful for transferring a domain between backups without re-extracting and re-importing. Overall, this is a focused tool that does exactly what it promises, with clear boundaries on what it cannot do.

Editorial conclusion

Adopt iBackupExtractor if you manage unencrypted iOS backups and need to retrieve files without a full restore, especially on macOS or Linux where you can build from source. Do not use it if your backups are encrypted, if you need to modify the source archive, or if you cannot afford to risk working on your only copy. Before relying on it, verify that your backup is unencrypted, that you have read access to the archive directory, and that you test extraction on a copy of the backup first. The tool's read-only default behavior and explicit domain selection make it a safe choice for targeted recovery, but its narrow scope and lack of recent development mean you should treat it as a utility, not a platform.

Official sources

1. Official README
2. Project repository
3. Release notes