How importing works

An import runs in four stages. The Import page shows one bar per stage, plus an overall bar, so it is worth knowing what each stage does and why some take much longer than others.

Upload comes first and is its own step. Search indexing and other enrichment run after the import ends, on a separate schedule:

flowchart LR
    U["Upload<br/>stores and registers the archive"] --> S1
    subgraph S1["Stage one — Unpack"]
        C["Check free space"] --> X["Expand, including archives inside archives"]
        X --> A["Set aside anything unreadable"]
    end
    S1 --> S2
    subgraph S2["Stage two — Read"]
        R["Run every parser that recognises the tree<br/>one failure = partial, not failed"]
    end
    S2 --> S3["Stage three — Store files<br/>photos · videos · voicemails · attachments"]
    S3 --> S4["Stage four — Save<br/>messages · events · documents · things · locations"]
    S4 -.->|"then, in the background"| S5["Search indexing<br/>and enrichment"]

Upload, then import

Uploading stores your archive and registers it. Nothing is expanded or read yet — a 40 GB Takeout cannot be unpacked inside a web request, and a restart, a closed laptop or a browser tab you lost does not destroy the upload.

Starting the import is the second step, and how it happens depends on where the archive came from:

• The wizard starts the import the moment an upload finishes, and runs Unpack, Read and Store files. It holds Save back until you select Sync to my memory, so you can upload several archives and save them together.
• The inbox starts every stage, including Save, when you select Import or Import all.

An upload you never import is deleted after about a day.

Stage one — Unpack

The archive is pulled out of storage and expanded into a working directory that belongs to this run.

The importer checks free space before it starts, so an import that cannot fit fails immediately with a message saying so, rather than filling the disk and failing at 80%. It measures the volume that holds the working directory, and separately refuses to start when the database volume has less than 2 GiB free. Both figures are in Prepare your data.

Then it expands what it found inside. Real exports are archives of archives: Google Takeout ships as numbered zips, each holding a Takeout/ folder. Those are expanded too, and the wrapper folder is flattened so each category sits where its parser expects it. Each zip is deleted as soon as it has expanded, so the peak disk use is one archive plus the growing tree, not every archive at once.

An archive that cannot be read at all — most often a download that stopped early, which leaves a file that looks complete but has no index at the end — is set aside rather than failing the import. Its siblings still import, and the run reports what was set aside and why. Entries that no extractor can take, such as a name used as both a file and a folder, are reported the same way.

Unpack also refuses to write through links inside an archive, and removes any symbolic links it finds, so a hostile archive cannot make a later stage read or delete a file outside the run.

Stage two — Read

The appliance works out which parsers recognise what is in the tree, then runs each one.

A single archive usually feeds several. A Google Takeout is not “a Takeout” to the importer; it is Mail, Photos, Location History and Chrome history sitting in one folder, each read by a different parser and recorded under its own name.

If one parser fails, the others still run. A Takeout holding six sources where one hits a file it cannot read has imported five of them, and the import finishes as partial rather than failed, listing what went wrong. This matters: reporting that as a failure is what makes people re-upload 40 GB over one bad file.

If nothing is recognised, that is also reported as partial, not as an error. It means your appliance has no parser for what you uploaded, or the file is not in the format the parser expects — not that your file was broken.

The Read stage produces a staged copy of every record it found. Nothing is in your memory yet.

Stage three — Store files

Photos, videos, voicemails and message attachments have bytes that must live somewhere durable. This stage copies them from the run’s working directory into Memory’s file storage, in batches. Two of these stages can run at once, across different imports.

On a photo export this is often the longest stage. On an archive with no media it finishes in a moment.

The wizard runs this stage before Sync, not after, because the working directory is deleted when the run’s last stage ends. Files not stored by then would be gone.

Stage four — Save

What the parsers found is written into your memory as messages, events, documents, things, browsing history and locations. The stage matches each record to the people, places and things it involves, and creates the ones it cannot match. When it finishes, the stage lists what it saved — for example “12.4k events · 3.1k messages · 240 documents”.

Re-importing is safe

Every saved record carries where it came from and its identity within that source. Importing the same archive twice does not double anything: the second pass recognises what is already there.

That is also why you can run an interrupted import again. Each record tracks its own state, so the Save stage picks up what is left rather than starting over.

If a stage fails

The stage that failed says why, and offers Try again. A failure does not retry by itself — re-expanding a 40 GB archive because object storage hiccuped is expensive and surprising, so it waits for you to ask. Try again runs that stage from its start; the stages before it do not repeat.

A stage whose worker simply stopped is different: nothing failed, the work went away. The import strip reports Stalled — no heartbeat after 90 seconds of silence, and Companion Memory puts the stage back in the queue itself within about four minutes, marked “retrying, its worker stopped”.

A finished import can also leave individual records that could not be written. The Save stage says how many, and Try these again puts only those back in the queue.

Progress, and why it is uneven

The four stages are not the same size of job, and the overall bar is weighted accordingly rather than giving each a quarter. Unpack counts for 20 percent, Read for 35, Store files for 30 and Save for 15. Reading dominates because it runs the parsers over the whole tree; Save is bounded by how many records were found.

While a stage cannot yet count its work — a parser does not know how many messages a mailbox holds until it has read it — the bar animates and shows a live count instead of a percentage. It is not stuck. A bar that guessed would be worse than one that admits it does not know yet.

Stages of different imports overlap, but each kind runs at a fixed width: one unpack, one read and one save at a time, and two file-storage jobs. When you import a batch, “waiting to start” for many minutes is the normal state of the later archives, not a stall.

What runs after the import

The import ends when your data is saved. Everything that makes it more findable runs afterwards, as separate background jobs that the import bars do not show. You can watch them on the Jobs page.

• Search indexes. Text embeddings — the numbers that let the Semantic filter rank by meaning — are built as records arrive, with an hourly sweep as a backstop. New data is searchable soon after Save, but on a large import the embedding backlog can take much longer to clear.
• Photo descriptions. When the chat model you selected supports vision, Companion Memory uses it to describe your photos so a search can find what is in them. A daily sweep at 03:20 picks up anything undescribed, and turning image description on in Settings → Model starts one at once.
• Nightly enrichment. A window that opens at 01:00 by default, in the appliance’s time zone, does the slower local work: linking messages to the people in them, probing media dimensions, and estimating locations. It spends about 90 minutes of active work per night and serves one account at a time, so a household with several large imports takes several nights.
• Lookups from outside services. Reverse geocoding of places and link previews go to outside services, so they run only in the same window and with a cap per run. Place lookups run at most weekly and link previews at most daily. This is why a freshly imported place can show coordinates but no address for days.

If search results seem to be missing after an import, open Jobs and check whether the queues are still working through the backlog before you assume something is wrong.

What the appliance keeps

While an import runs, the appliance holds the uploaded archive, its expanded working directory and a staged copy of the parsed records. It deletes the archive and working directory as the run finishes. The staged records for a completed run are deleted after seven days, and the run’s history entry after 90 days. A run that was read but never saved is kept until you select Sync to my memory or Discard, because its staged records are the only copy of the parse.