My export arrived as a dozen separate zip files
You asked for your data and got a pile of numbered archives instead of one file. Apple labels them Part 1 of 3 and similar; Google just numbers them. It is not obvious which one to open, whether you need all of them, or whether they have to be stitched back together first.
Can you get it back?
Nothing is broken and nothing is missing. In almost every case these are complete archives that each open on their own, and you do not need to join them together. Downloading all of them still matters, because your files are spread across them, but that is a different thing from merging them.
What actually happened
You choose a maximum file size when you request the export - Apple and Google both offer it, and it is easy to accept the default without noticing. Anything larger than that gets written as several archives instead of one. Smaller files download more reliably on a poor connection, which is why it is offered and often why it is the default.
Apple also sends the same archive twice if you make the same request more than once, so you can end up with a file and a copy of it ending in (1). That is a duplicate rather than a missing piece.
The usual advice online is to merge the parts with a joining tool before opening anything, and for one kind of split archive that is correct and unavoidable. For the kind these exports actually produce it is wrong, and it is expensive: one guide to doing it notes needing about 68 GB of free space to merge a large set, and then more again to unpack the result. The test takes two seconds and it is the file extensions. If you have one .zip alongside files ending .z01, .z02 and so on, that is a genuine spanned archive and the parts really are fragments - you need all of them present and you must open the .zip, which pulls in the rest. If every file simply ends in .zip, they are separate complete archives and each opens by itself. A real Apple export checked here was 18 files, every one with its own working directory, 1,020 entries between them, and not a single spanned part.
How to fix it
Once you know which kind you have, it is straightforward.
- All files end in .zip
- Open each one normally. Nothing needs joining. It is worth extracting them into a single folder rather than one folder per archive, so that the export ends up in the shape it had before it was split up.
- You have .z01, .z02 and one .zip
- This is a real spanned archive. Keep every part in the same folder and open the .zip file - 7-Zip on Windows and Keka on macOS will pull in the numbered parts automatically. Do not try to open the .z01 directly. You need free space roughly equal to the whole set, twice over.
- Two files with the same name, one ending (1)
- Apple sending the same archive twice. Compare the file sizes: if they match, keep either one. Nothing is lost by deleting the copy.
How Muletto does it
Drop all of them in at once. Muletto reads them as a single library, so a photograph in one archive finds its metadata in another, and duplicates between them are found rather than imported twice. It also opens archives that contain further archives, which Apple exports do - in the one measured here, seven of the eighteen held more zips inside them, and 394 entries were invisible until those were opened.
Stopping it happening again
When you make the request, look for the maximum file size setting and choose a larger value if your connection can manage it. You will get fewer, bigger files. On a connection that drops, the default is the better choice and several files is the lesser problem.
Checked against a real Apple export of 18 archives: every one carried its own working central directory and opened independently, 1,020 entries in total, with no spanned parts anywhere in the set. Seven of the eighteen contained nested archives holding a further 394 entries.