Back to blog
FILE 0x5F·WHY GOOGLE DRIVE EATS HYPERBACKUP, AND WHAT TO DO INSTEAD

Why Google Drive eats HyperBackup, and what to do instead

May 18, 2026 · homelab, backup, synology

I had 27 TB of stuff on my NAS that I wanted backed up to Google Drive. Synology HyperBackup ran for weeks, made it about a third of the way, and the queue of "stuck" files kept growing. So did Cloud Sync's. Both tools were technically running. Neither was getting anywhere.

What was happening

Bandwidth wasn't saturated. The Drive web UI showed the bucket filling slowly but steadily. What the dashboards didn't show: the queue of "in flight" objects on the Synology side was at 400,000+ and climbing. After several days, the actual throughput was on the order of megabits, not megabytes.

The classic failure signature: hundreds of thousands of stuck files, tiny trickle of bytes through, restart-required-to-recover state.

What I found

The bottleneck was Drive's per-file API rate limit, not bandwidth. Drive sustains roughly 2–3 file operations per second per OAuth client. HyperBackup and Cloud Sync both upload millions of tiny chunks, each as an individual file. At 3 ops/sec, 27 TB of small chunks would take literally months.

A second cause amplified it: HyperBackup's S3-compatible backend was configured with a long socket timeout, so any transient Drive blip would hang an entire upload connection for two minutes before failing the whole task instead of just the one PUT. Aws-sdk-php's built-in retry-with-backoff never got a chance.

The fix

Two changes, both targeted at "stop letting one slow upload stall everything."

First, tighten the upstream timeout so a single bad PUT bubbles up fast and gets retried by the SDK instead of killing the connection:

# In the S3 backend config, drop the per-request wall timeout from
# the default ~120s down to ~1.5s before the error surfaces.

Second — and this is the real answer — stop using HyperBackup and Cloud Sync for this shape of workload entirely. The per-file model is wrong. Tools that pack small files into ~100 MB blobs before upload turn millions of objects into a few hundred thousand. That fits inside Drive's per-second limit by orders of magnitude.

Kopia (and restic) are both designed this way: content-addressed packs, incremental forever, end-to-end encrypted, parallel uploaders. After swapping the topology to a packer + rclone Drive backend:

That topology can sustain real GB/s rates and finish a 30 TB seed in about two weeks of wall time.

What I'd do differently

I would have done back-of-envelope arithmetic on file count before trusting HyperBackup with this volume. "400,000 stuck items" wasn't a config bug; it was a math result. The tool was doing exactly what it was designed to do — the design didn't match the data shape.

The next time I evaluate a backup tool, I'm asking one question first: does it pack? If yes, it can handle a 30 TB seed to a per-file-throttled destination. If no, it can't, no matter how much bandwidth you throw at it.