Articles

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 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 its 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

Client deliveries over Box run into the same problem every time. The web downloader handles a single file fine, and the trouble starts the moment you select a folder.

Select more than one file in Box and it builds a server-side zip before it gives you anything. For a folder of video files that zip takes a long time to prepare, the browser download can stall or time out, and when it fails you start the whole batch again.^[1] People who keep a Box account because a client or a school requires it hit this every time they need their own files back.

Box's Fair Use Policy caps bandwidth at about 1 TB per user per month. Exceed it and Box emails you, throttles the account for the rest of the month, and warns that it may permanently reduce your bandwidth or suspend the account.^[2] For someone who only holds a Box account to receive client footage, a couple of large deliveries can use up the cap in one month.

The download method matters here. Pulling the same set of files twice because a zip timed out is double the bandwidth. So is downloading to your machine and then uploading again to the cloud where you actually want the files.

The desktop app that mounts Box as a drive has its own problems. Slowness that appears for no reason,^[3] files that refuse to upload after an OS update, folders that will not open.^[4] Relying on Box Drive to copy a large folder out can stall exactly when you need the data most.

Blober connects to Box through the API, not the web client and not Box Drive. That changes the download in a few concrete ways:

• each file downloads on its own, so there is no server-side zip to wait for or retry;
• progress is per file, and an interrupted task resumes without redoing what is already done;
• you pick where the files land, which can be a local folder, an external drive, a NAS, or another cloud like Google Drive or pCloud, so you do not download once to your machine and upload again;
• nothing depends on the state of the Box Drive app on your computer.

Connect Box as the source, choose a destination, select the folder, and run the workflow. A whole client's project is where the difference shows up immediately.

Why does Box zip my downloads?

The web interface batches multiple selected files into a server-side zip. It is convenient for a few documents and painful for a folder of large media files, because the zip preparation is slow and the download can time out.

What is the Box bandwidth cap?

Box's Fair Use Policy limits users to about 1 TB of bandwidth per month. Exceed it and Box can throttle the account for the remainder of the month and warn of further limits.^[5] Downloading files once, deliberately, instead of retrying failed browser batches, keeps you inside it.

Do I need Box Drive to download my files?

No. Blober uses the Box API directly, so a slow or broken Box Drive does not block the transfer.

My Box account is free. Are there file size limits?

Free accounts cap individual files low (around 250 MB), and paid plans raise it, with Business listing 5 GB per file.^[6] The limit that matters for a bulk download is on your plan's terms, not on Blober's side. Blober transfers the files your account can hold.

Can I download Box files straight to another cloud?

Yes. Pick any supported provider as the destination and Blober streams each file there, so the data does not stage as a full second copy on your disk.

What happens if the download drops halfway?

Resume the task. Completed files stay completed and the rest continue.

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

Box accounts disappear more often than people expect. A university closes graduating students' accounts.^[1] A job hands you a departure date. A business stops paying for Box and the admin deletes the account on a schedule. One day the files are there, the next they are a support ticket.

The shape is consistent. Someone with a few hundred gigabytes in Box gets the deadline, asks around for the easiest way out, and the advice comes back as sign up for Google Drive or buy an external drive.^[2] Both answers assume a manual download and re-upload, and neither one moves a folder tree. The tooling for the actual job is missing, and that is the job Blober is built for.

To move a Box account by hand you download each folder from the web client, then upload it to the new home. Box's web downloads are the hard part: select several files and Box builds a zip that takes a long time to prepare and can time out.^[3] Then you are re-uploading the same data, which doubles the bandwidth you spend and the time you lose.

An external drive only helps if you have one, if it is big enough, and if you do not mind the data passing through it before it reaches its real destination.

Blober reads Box through the API and writes each file to the destination you choose, so the structure you see in Box is recreated where the files land:

• pick Box as the source and pick the destination, which can be Google Drive, pCloud, a local disk, an external drive, a NAS, or an S3-compatible bucket;
• the folder tree is rebuilt at the destination, so you are not left with one flat pile of files;
• you can preview the selection and the destination paths before you run anything;
• transfers resume on their own, so a dropout does not restart the account;
• no browser zips, no temporary external drive, no script.

Connect Box, connect the destination, and run a workflow with Box as the source.

Give yourself room to check the result. The practical sequence is:

1. run the transfer with the account still open;
2. open a sample of files at the destination, especially the folders that matter most, and compare file counts between the two sides;
3. only then close or forget the Box account.

Keep the old account until you have confirmed the copy. A deadline is exactly the situation where a resumable, per-file transfer beats a browser session.

Do I need an external drive to move out of Box?

No. Blober sends files from Box to the destination directly. A local or external drive is just one of the destination options, not a required stop.

Does the folder structure survive the move?

Yes. The folders you select in Box are recreated at the destination.

Can I go from Box to Google Drive, pCloud, or a NAS?

Yes. Any of those can be the destination in the same workflow.

What about Box file size limits?

You can transfer the files your Box account can hold. The limits that apply are your plan's terms, not a Blober restriction.

What if the transfer drops partway through?

Resume the task. Files already transferred stay done and the rest continue.

How do I verify the move before the account closes?

Open a sample of files at the destination and compare file counts for the folders you care about. Keep the Box account until you are satisfied.

Is there a subscription or per-GB fee?

No. Blober is a one-time purchase with a lifetime license.

Blober runs on Mac, Windows, and Linux. No subscription, no transfer fees, no per-GB cap.

Download Blober at blober.io

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.

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

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]

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