Why Google creates several archives
Google splits an export when it exceeds the archive size selected during Takeout setup. Each numbered ZIP is a separate archive, but together they represent the requested data set. Increasing the selected archive size may reduce the number of parts, not the need to verify every downloaded part.
Place all parts in one source folder and keep their original names until the inventory is complete.
Do not overwrite folders one ZIP at a time
Manually extracting several archives into the same destination can merge directories without telling you which repeated files were identical, conflicting or incomplete. Processing each extraction separately can also prevent media from finding sidecars in another part.
A library-level tool should index all archives first and keep the archive path for every candidate.
Validate before a long run
Open every archive entry and verify its CRC before repair. A truncated part should stop the job before hours of output have been produced. Record compressed size, expanded size, media count and sidecar count during the same pass.
If a part fails integrity, download that part again while the Takeout link remains valid. Do not treat missing files from a broken ZIP as unmatched metadata.
Build one conservative index
Index normalized filenames, JSON titles, album records and media candidates across all archives. Exact local matches should win, while cross-folder matches require stronger evidence so a similarly named photo is not assigned another file’s date or GPS.
The index should retain source ZIP and entry paths so every repair decision can be reported and reproduced.
Reconcile album copies after matching
The same bytes may appear in a year folder and several album folders. Full content hashes can identify those exact repetitions and merge album membership without deleting edited or merely similar images.
If two files have the same name but different hashes, both must be preserved or explicitly reviewed.
Plan temporary and output space
A complete expanded cache can require as much space as the entire library before output begins. Bounded temporary batches and direct archive-to-output streaming reduce the peak, but the repaired output still needs its own capacity.
Review compressed size, expanded size, expected temporary peak, output estimate and available destination space before starting. Keep the original ZIPs on separate storage when possible.