Data Recovery Case File · Mac & Apple Ecosystem · The Library Is a Container
Apple Recovered Documents but Not the Photos
Her enquiry was one line and describes an outcome that confuses almost everyone who experiences it. "Apple Mac not powering on. Apple have only managed to recover documents, not photos." The obvious reading is that the photographs were more damaged than the documents — that some are gone and some survived. That is usually not what happened. The likelier explanation is structural, and it is genuinely hopeful: documents are individual files and a photo library is a single container. A transfer process that copies files one at a time will happily carry a folder of documents across while failing at a library whose internal database will not open — and failing at the container does not mean failing at the thousands of photographs inside it.
| Media | Mac internal storage — machine not powering on; a third-party transfer recovered document files but not the photograph library |
| Reported situation | Machine dead · partial recovery already performed elsewhere, returning documents only · photographs outstanding · library structure suspected rather than confirmed |
| Fault class | Transfer-based recovery halted by a damaged library container — individual originals inside typically intact and recoverable independently |
| Equipment used | Storage imaged write-blocked before any further attempt · library package opened on the image and its internal database examined · original images extracted independently of the library structure · format-aware carving for anything the library no longer indexed · every photograph validated by rendering |
The decode: why a library fails where documents succeed
What a photo library actually is: on a Mac it looks like a single item, and that is deliberate — it is a package, a folder presented as one object. Inside it are the original image files, generated previews and thumbnails, edit histories, and a database that ties them together: which photograph belongs to which album, what edits were applied, what the dates and locations are. Open the library and the application reads that database first.
Why that changes what a transfer can do: a migration or transfer tool copies items. A document is a self-contained item and copies cleanly. A library is copied as a whole, and it is only useful if its database opens afterwards — so if the database is damaged, the transfer either fails outright or produces a library the application refuses to load. From the customer's side both look identical: documents came back, photographs did not. But the failure is at the level of the container and its index, not the pictures.
Why the originals are usually fine: the encouraging part. The actual image files live inside that package in an ordinary folder structure, as ordinary files, and they are not stored in the database — the database only describes them. So a damaged library commonly sits over thousands of perfectly intact photographs that can be extracted directly, independently of whether the library will ever open again. What is lost in that route is the organisation: albums, edit histories and some metadata. What is kept is the photographs themselves, at full resolution, with their capture dates intact.
Why the earlier attempt is not a bad sign: a transfer that recovered documents proves the storage was readable enough to copy from — which is real information. Whoever performed it was doing a migration rather than a recovery, and migration is the right tool for a working machine and the wrong one for a damaged library. That they stopped rather than forcing it is fine; it simply means the job was not finished.
The two things worth establishing: whether the library's database can be repaired — which returns the albums and edits as well as the pictures — and, failing that, extracting the originals directly. Both are done on an image rather than the original storage, and both are attempted in that order, because the first outcome is materially better than the second.
On the bench
The storage was imaged write-blocked before anything else, so that a further attempt could not modify what a previous one had left. On the image the library package was opened as the folder it actually is, and its internal database examined and repaired where the damage allowed — that route returns the albums, edits and structure as well as the images. Where the database was beyond repair, the original image files were extracted directly from inside the package, independently of any index, and format-aware carving swept for anything the library had ceased to reference. Every photograph was validated by rendering at full resolution, ordered by embedded capture date, and delivered on fresh media.
The outcome
The library examined and its originals extracted, validated at full resolution and delivered. Free assessment, one fixed written figure including VAT; where a drive has to be opened or a chip removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone told their documents came back and their photographs did not: that is usually a structural outcome rather than a verdict on the pictures — documents are individual files that copy cleanly, while a photo library is a single container with a database inside it, and a transfer that meets a damaged database fails at the container rather than at its contents; the original images sit inside that package as ordinary files and are extracted directly; and a partial recovery elsewhere is not a bad sign, because it proves the storage was readable — the job was simply left unfinished.
Told your documents were recovered but not your photos
Don't assume the pictures were more damaged — that outcome usually reflects how photo libraries are built rather than what survived. Your documents are individual files and copy cleanly; a photo library is a single container with a database inside describing albums, edits and dates, and a transfer tool that meets a damaged database fails at the whole container. The photographs themselves are ordinary files sitting inside that package, and they can be extracted directly whether or not the library ever opens again — so ask specifically for the original images rather than for the library. Expect a trade-off if the database can't be repaired: you'll get full-resolution photographs with their capture dates, but albums and edit histories may not survive. Ask for library repair to be attempted first, since that returns the organisation too, and make sure everything happens on an image rather than the original storage.
The library failed, not the pictures — call Leeds Data Recovery on 0113 322 3083; imaged write-blocked, library repair attempted first, originals extracted and validated by rendering.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.