Skip to content

pcloud

3 posts with the tag "pcloud"

Back Up Google Photos to pCloud Without Takeout

Back up Google Photos to pCloud without Takeout

The move comes up more than any other: get a Google Photos library out of Google and into a pCloud lifetime plan. The transfer breaks in the same place almost every time, and it is never the archive part.

The manual route starts with Google Takeout. You request an export and wait hours, sometimes days, for a pile of zip files. Each item arrives next to a JSON sidecar that holds Google's metadata, and you extract the zips. For the minority of files that need it, you merge that sidecar back into the files with an EXIF tool. Then you upload the result to pCloud, and when the upload breaks partway, you figure out what happened and try again.

For a big library, that takes days. It is why so many pCloud lifetime plans sit mostly empty.

Takeout does not break dates for most photos. Files uploaded at original quality keep their own EXIF, including the capture date, and a plain copy preserves it. The JSON sidecar is extra.

The metadata fix applies only to a subset: photos edited in Google Photos, which download as re-encoded files, and files that never had an embedded capture date, which covers screenshots, downloaded images, and forwards.[1] For those, the reliable date lives in Google's JSON. Most libraries are mostly original files, so the fix is a minority concern.

What that means for a transfer tool: the file should pass through unchanged. Whatever date is embedded in the file comes with it, no merge step and nothing stripped. That is the rule Blober follows. It reads each file as Google serves it and writes it to pCloud.

rclone used to list and download a Google Photos library. Google changed its API policy in March 2025, and since then rclone can only download photos it uploaded itself.[2] That leaves an existing library out of reach. Transfer services that run on your behalf face the same limit, or they meter how much data you can move per month.

For a library you built through the Google Photos app or the web, the direct path to pCloud needs a tool that reads Google Photos the way the service exposes it, plus pCloud support on the other side.

Blober sends Google Photos to pCloud directly

Section titled "Blober sends Google Photos to pCloud directly"

Blober is a desktop app with a Google Photos provider and a pCloud provider, so the Takeout step drops out of the job:

  • connect Google Photos as the source and pCloud as the destination in one workflow;
  • Blober reads the library through the provider and writes each photo and video to pCloud, passing the files through unchanged;
  • no Takeout archive, no zip extraction, no sidecar step;
  • transfers resume on their own if the connection drops, and files already copied stay done;
  • you can organize during the move with a path template if you want folders by year or by month instead of one flat folder.

If your pCloud account is on the EU data center, Blober picks that up during authorization and uses it for the transfer. There is nothing to configure.

To start, connect Google Photos and pCloud, then create a workflow with Google Photos as the source and pCloud as the destination. Select the library (or an album), select the pCloud folder, and run it.

For the general case of downloading Google Photos without Takeout, see how to backup Google Photos without Google Takeout.

Will the photo dates survive the move?

For the files that have a date embedded, yes. Blober passes each file through unchanged, so the capture date in the file comes along. It does not strip or rewrite anything.

Do I still need exiftool or a script?

Not through Blober. A metadata fix applies only to edited photos and files without an embedded date, which is a minority of most libraries. Blober transfers each file as it is, so the files that already carry their date come through unchanged and need nothing extra.

What happens if my connection drops halfway?

Blober keeps per-file progress. When you resume the task, the files that already transferred stay done and the rest continue. You do not redo the library.

Does this work with a pCloud lifetime plan?

Yes. Blober connects to the account the same way regardless of how you pay for it.

My pCloud account is on the EU servers. Do I need to do anything?

No. The data center is detected when you authorize, and Blober uses the right API host from then on.

Do I need to create my own pCloud app?

No. Blober pre-fills the public pCloud app keys, so you authorize in seconds without creating an app or waiting for a review. If you prefer your own app, the pCloud guide covers that too.

I still want to use Takeout as a fallback. Does that work?

It works, but you are back to the manual route: batches, zip extraction, and a metadata fix for the files that need one. Blober is the direct route, and it does not reintroduce the exact problem you were trying to avoid.

Blober is a one-time purchase with a lifetime license. No subscription, no transfer fees, no per-GB cap. It runs on Mac, Windows, and Linux.

Download Blober at blober.io

pCloud Uploads Are Slow. The Client, Not the Service, Is Usually Why.

pCloud uploads are slow because of the client, not the service

Slow pCloud uploads are routinely blamed on pCloud. The bottleneck is usually the desktop client, not the service. There are two paths into pCloud, and they behave very differently.

Where the slowness usually comes from

Section titled "Where the slowness usually comes from"

The pCloud desktop client, the thing that mounts a P: drive and syncs folders, does a lot of work per file. It stages uploads through a local cache, so the final stage of an upload touches disk on your machine.[1] It serializes work, so small files queue up and take a long time.[2] And it does not always recover cleanly, so people end up reinstalling it and testing their connection while the real cause sits in the app.[3]

The same account and the same connection produce two very different results depending on which path the bytes take. The client path crawls. The API path runs at the speed your connection allows.[4]

That split is why the common workaround is to zip a folder first, upload the one big file, then unzip it in the cloud. It is a workaround for the client's behavior with many small files, not for the service.

pCloud exposes a normal API. Files upload over it with a single request, and the API does not carry the client's cache or serialization. Terabyte-scale libraries move over that path at full connection speed. It is the same route Blober takes.

Blober is a desktop app, but it does not use the pCloud client or the P: drive mount. It talks to the pCloud API directly, without the command line:

  • you pick the source and destination in a file browser instead of typing rclone flags;
  • each file uploads as its own request with progress shown;
  • a file that fails on a transient error (pCloud returns 4xxx for throttling and 5xxx for temporary failures)[5] is retried automatically;
  • completed files stay done when a task is interrupted, so a dropped connection does not restart the whole job.

The guide on connecting pCloud covers the authorization, which takes seconds because Blober ships the public app keys.

Two limits stay honest. If pCloud is throttling a specific account or a busy network path, no tool changes that, and Blober does not pretend otherwise. And pCloud has no resumable upload for a single large file, so a multi-gigabyte file that fails retries from the start of that file.[6] The difference is that the rest of the task is untouched and the same file does not fail silently in a queue while you wait.

If uploads from the pCloud client have been the problem, try a Blober workflow before you abandon the plan. The files you are trying to upload will tell you whether the service or the client was the slow part.

Does Blober make pCloud upload faster?

It removes the desktop client's cache and serialization, which is the reported bottleneck. It does not override server-side throttling, so results depend on the account and the connection.

Do I still need to zip folders before uploading?

No. Zipping was a workaround for the client. Blober sends the files as they are.

What happens if a file fails mid-upload?

Blober retries the file and keeps the task going. Files already uploaded stay uploaded. A single large file that fails starts over because pCloud has no resumable upload, but nothing else in the job is redone.

Does Blober use the pCloud Drive cache on my disk?

No. It streams through the API, so it does not fill the local cache the desktop client uses.

I have a lifetime plan. Does that matter for uploads?

No. Blober connects to the account either way.

Is this the same as rclone?

The upload path is the same idea. Blober is the part rclone is not: a visual app where you browse both sides, build the workflow, and watch progress without editing a config file.

Blober is a one-time purchase with a lifetime license. No subscription, no transfer fees, no per-GB cap. It runs on Mac, Windows, and Linux.

Download Blober at blober.io

Treat pCloud Like an Archive, Not a Sync Drive

Treat pCloud like an archive, not a sync drive

pCloud is good at one thing and risky at another. The split matters more than the product marketing does, and it is worth being clear about which side you are on.

The good part is the archive. The use that works is treating pCloud like a cloud external drive: keep RAW photos, music libraries, documents, and other files off the laptop's SSD, upload them, and leave them there. It is a sensible use, and a lifetime plan makes it a good deal.

The risky part is sync. The failure reports people file follow a consistent pattern. Someone edits a file on one device while another device still holds the old version. The stale version syncs back and overwrites the newer work, and the person does not find out until it is gone. pCloud's own support tells people not to edit application-specific files directly on the pCloud Drive (P:) and to keep them in a local working folder instead.[1]

The danger is not pCloud the archive. It is treating the sync drive as a place to edit live files. pCloud sync does not always flag a conflict, name a conflicted copy, or tell you it happened. You only find out after the old version has overwritten the new one.[2]

Use pCloud as an archive, and back up to it deliberately

Section titled "Use pCloud as an archive, and back up to it deliberately"

The safe pattern is to keep pCloud as a destination you write to, not a drive you edit on. You decide what goes up, you see it go up, and you can verify the result. That is a copy operation, not a sync operation.

Blober fits that pattern exactly. It is a transfer tool, not a sync client. You pick a source folder, pick a pCloud folder, run the workflow, and the files land in pCloud with per-file progress and resume. Nothing syncs in the background, and nothing overwrites a file you did not ask to touch.

The pCloud guide shows the setup, which takes seconds because the app ships the public app keys.

There are two reasons a single pCloud account should not be your only copy.

The first is traffic. pCloud ties download traffic to plan size, so a large account can hit the limit fast if you pull data back down repeatedly.[3] If pCloud holds the only copy of your photos, every restore is a download against that cap. A second copy somewhere else means you only download from pCloud when you actually need to.

The second is the account itself. Accounts get revoked, plans lapse, support tickets sit for days, and pCloud has publicly handled account cancellations for policy reasons.[4] None of that has to be fatal if the files also live somewhere you control.

Blober mirrors an archive to another place in the same kind of workflow. Copy a pCloud folder to a local disk, a NAS, or a second cloud, and the pCloud copy stops being a single point of failure. The 3-2-1 rule of thumb applies here the same way it does everywhere else: one cloud account is one copy.

Blober does not do two-way sync, and it does not claim to. If you want live multi-device editing with conflict handling, you want a product built for that. Blober is for the deliberate jobs: fill the archive, organize it while it moves, keep a second copy, and leave pCloud as the safe archive it was bought to be.

Can I edit files directly on the pCloud drive?

pCloud's own guidance is to edit in a local working folder and sync after. Editing application or database files on the P: drive is where the data loss cases come from.[5]

What is the pCloud download traffic cap?

pCloud ties monthly download traffic to plan size on many plans. Blober cannot change that limit, which is why the practical answer is a second copy so you rarely need to download from pCloud at all.

Is my pCloud lifetime plan enough as my only copy?

A single account is a single point of failure, no matter how it is billed. Blober can keep a second copy on local storage, a NAS, or another cloud.

Does Blober sync my folders both ways?

No. Blober does deliberate copy and move workflows with visible progress and resume. It does not watch folders and reconcile changes in the background.

Can Blober copy from pCloud to a local drive or NAS?

Yes. pCloud works as a source in the same way it works as a destination. Select the folder, pick the local or NAS destination, and run it.

Blober is a one-time purchase with a lifetime license. No subscription, no transfer fees, no per-GB cap. It runs on Mac, Windows, and Linux.

Download Blober at blober.io