When subscription fatigue pushed me to move things onto my own server, the first lesson was this: keeping data in the cloud is a choice, leaving it there is a habit. The difference between the two only shows up on the day you can't get into your account.
Most services show you a "download your data" button, and that button is reassuring. But the existence of the button and the data being yours are not the same thing. One question measures the distance between them: can you open that archive today and restore something out of it? In this piece I go through the export tools of the three big providers as their own documentation describes them — along with the limits they mention quietly.
A transparency note up front: the durations and limits below did not come from my own testing; they are commitments written in the providers' own documentation. Rather than inventing figures, I prefer to write down what the docs say and flag where it will hurt.
What does "export" actually give you?
Google's tool is the most plain-spoken of the three, which makes it a good place to start. After the archive is built, the Takeout documentation states two numbers, and those two numbers define the whole character of the thing: the archive expires in about 7 days, and each archive can only be downloaded 5 times.
So what you're holding is not a permanent backup but a timed window. Google doesn't hide this either: once the archive expires, you're expected to create a new one. In practice that means if you start an export "in case I need it someday" and postpone the download until next week, what you're left with is a dead link in an email.
The delivery options are generous: you can get a link by email, or have the archive dropped straight into your Drive, Dropbox, OneDrive or Box account. There's a fine irony there. The process you started to rescue your data from the cloud mostly offers exits that land you in another cloud. If it isn't coming down to your own disk, what you did wasn't a rescue — it was a move.
For file type you pick .zip or .tgz; the documentation marks zip as openable "on almost any computer" and notes that tgz may need extra software on Windows. You also choose the archive size, and anything above your chosen limit gets split into multiple archives — the 50 GB option exists precisely to make that splitting less likely.
Making it continuous: scheduled and incremental exports
A one-time archive is fine for moving day. But if your data grows every week, what you actually need is a repeating flow.
Takeout's scheduled export covers this: it automatically creates an archive of your selected data every 2 months for one year, with the first archive created immediately. Six snapshots a year, six windows.
The most useful change on the photos side landed this year. The documentation now says that for Google Photos you can schedule automatic exports of new and updated data — meaning you no longer have to pull your entire library down every single time. There's one condition, and it's easy to miss: to use this option, Google Photos must be the only product selected in your export. Add Drive alongside it and you lose the incremental behaviour.
For anyone whose library runs into hundreds of gigabytes, that's the difference between "a night of downloading every month" and "a few new folders." It matters especially if you run your own photo cloud; I wrote separately about the storage and backup plan on the Immich side.
And there's a door nobody expects: if you're enrolled in the Advanced Protection Program, scheduled exports aren't available. On top of that, accounts in the programme have even one-off archives scheduled two days into the future. The user who protects their account most strictly loses automated export, and waits two days on the day they're in a hurry. It's the clearest example of security and portability colliding, and anyone who wants both needs to plan around it.
Apple: getting a copy and transferring are different things
On Apple's side everything runs through the Data and Privacy page. Apple says these tools are offered in over 240 countries and regions; you can request a copy of your data, ask for corrections, temporarily deactivate your account, or delete it permanently.
The genuinely interesting part sits in a separate tool: transferring iCloud Photos directly to another service. Apple's document names a single destination here — Google Photos — and puts the process at three to seven days. During those days Apple verifies the request really came from you.
One item in the prerequisites is easy to skim past: Apple requires that your Google account have enough storage available to complete the transfer. This isn't a free tunnel; data leaving your iCloud quota gets written against your Google quota on the other side. If you're planning to move a 200 GB library onto a free tier, the arithmetic won't hold. Two-factor authentication on your Apple Account is required as well.
The real value of this tool is how openly it states what it does not transfer. Shared albums, smart albums, photo stream content, Live Photos, content stored in other folders or locations, and some metadata don't come along. Only the most recent edits carry over. The album limit isn't the loss it sounds like: with an album over 20,000 photos, the extra photos are still transferred, they just aren't added to the album. And the critical one: if Advanced Data Protection for iCloud is turned on, the transfer can't happen at all.
The same trade-off shows up at two different companies. The moment you turn on end-to-end encryption, the provider's ability to move your data on your behalf switches off too — because it can no longer read that data. This isn't a bug, it's the design — but a design you need to know about while planning.
Live Photos not transferring sounds minor, doesn't it? Right up until those three seconds of your child's first steps — a second and a half before the shutter and the same after — arrive on the other side as a single still frame.
Microsoft and the "legal window"
Microsoft lets you view and download your data through the privacy dashboard. There's a distinction worth catching here. The privacy FAQ gives no time commitment at all for the self-service download you run from the dashboard. The one duration it does state belongs to a different lane: under the heading about who to contact with further questions, it says requests and questions sent to the privacy team get a response as required by law and "within a period no longer than 30 days."
That distinction decides which lane you're in. As long as the dashboard serves you, you're fast; the moment you need something it can't do and fall back to the help channel, the unit of measurement shifts from minutes to weeks. And on the day you can't get into your account, the second lane is usually the only one left. Which is why the right time to export is always the same: before anything goes wrong.
The real trap is the format
Say everything went well and the archive is downloaded. Now the actual question: can you read what's inside?
Your email will most likely arrive as MBOX. It looks like a standard format and gets talked about as one. Yet RFC 4155 — the document registering the application/mbox media type — admits in the section describing mbox that the format is not documented in an authoritative specification, that it exists as a well-known output format documented anecdotally, and that there are a large number of variations between database formats. To mitigate that, the RFC defines a format parameter; the "default" format it specifies is simply the one compliant implementations must support and the one assumed for undeclared files. Even so, the document's own interoperability section states plainly that it expects non-conformant data to be erroneously tagged or exchanged.
Once that lands, your view of exports changes. What you hold is one interpretation the provider produced that day; the program on the receiving end may not share it. Photo metadata, contact cards, calendar recurrence rules — the same risk runs through all of them.
The only remedy is not to file the archive away and forget it. On the day you download it, check the archive's integrity (unzip -t does the job), actually import the MBOX into a client like Thunderbird, check that a few photos carry the right dates, import a calendar and open it. For split archives, noting each part's sha256sum answers the "did this file rot?" question months later. The logic from my restore-drill piece on restic applies here too: an untested backup isn't a backup. Neither is an untested export.
What you downloaded is now a risk
Here's the part of exporting nobody discusses: a successful export compresses the densest summary of your life into a single file. Mail, location history, photos, contacts. Getting into your account requires someone to defeat authentication; reading that zip requires a double-click.
The delivery options make this more delicate still. When you receive the link by email, access to the archive is only as strong as your mailbox. When you have it dropped into Drive or OneDrive, the file lands in an account that lives with its own sharing settings and signed-in devices.
A sensible arrangement looks like this: the archive lands directly on an encrypted disk (FileVault on macOS, LUKS on Linux, VeraCrypt for a portable drive), gets opened there, verified, and folded into backups. Give it an expiry date too — delete it once its job is done, because what you needed was never the archive itself but the data safely arrived. An archive forgotten in your Downloads folder quietly renders every security layer you put on the account meaningless; look at it with the same logic as keeping your passwords in your own vault.
Then there's scope. An export doesn't cover everything you can see in your account: purchased licensed content, files other people shared with you, and the categories we just listed as non-transferable may all sit outside it. Looking at the archive size and concluding "it's all here" is one of the more expensive assumptions available.
The right exists, but the tool belongs to the provider
In Europe there's a legal footing for this. Article 20 of the GDPR gives the data subject the right to receive the personal data they provided in a structured, commonly used and machine-readable format, and to transmit it to another controller. The same article makes direct transmission conditional on it being "technically feasible."
We saw above how that condition gets read: Apple offers exactly one destination for iCloud Photos. Technical feasibility, in practice, equals however much the provider invested.
Seen from Turkey the picture is simpler still. The tools you use aren't offered to you as a local right; you're benefiting from products the provider chose to offer globally. Which means if a provider restricts its tool tomorrow, you won't have much to lean on. The only thing you'll have is the copy you downloaded today.
One hour a year
Treat this as maintenance. Set aside an hour a year and do this: list the three accounts you depend on most, create an archive for each and download it to your own disk, open the archive and actually check three random files, turn on incremental scheduled exports for photos, and fold the copy into your 3-2-1 backup routine.
Then put the date in your calendar. Because the hard part here isn't technical; it's reminding yourself.
Data ownership isn't measured by the existence of a button; it's measured by whether what you were looking for comes out of the archive intact. Providers are opening the door, but nobody is checking whether you walked through it. Like planning your digital legacy, this is one of those jobs whose cost rises the longer you put it off.
Official Sources
- Google Account Help — Download your Google data (Takeout)
- Apple Support — Understand and control the personal information that you store with Apple
- Apple Support — Transfer a copy of your iCloud Photos collection to another service
- Microsoft — Privacy Frequently Asked Questions
- RFC 4155 — The application/mbox Media Type
Top comments (0)