Field report: using rclone serve webdav + Kopia's WebDAV backend

General Topics
1

(instead of the rclone backend (Windows → Google Drive))

I set up Kopia to back up a Windows 11 user profile to Google Drive this week, and hit the question a lot of threads here circle around: the rclone backend is marked [Not maintained], native Google Drive is experimental — so what should you actually use?

I ended up on a third option that isn’t documented anywhere I could find, and it’s working well. Posting the details and measurements in case they’re useful. This is one machine over two days, not a recommendation — see the caveats at the end.

The problem

kopia repository create --help on 0.23.1 flags its own backends:

gdrive Create repository in a Google Drive folder [Not maintained]
rclone Create repository in a rclone-based provider [Not maintained]
b2 [DEPRECATED]
webdav Create repository in a WebDAV storage ← no flag
s3, gcs, azure, sftp, filesystem ← no flag

Both routes to Google Drive are flagged. WebDAV isn’t — and the docs give it no experimental warning either.

The observation

Kopia’s rclone backend doesn’t talk to Drive directly. It spawns rclone serve webdav as a subprocess and speaks WebDAV to it over loopback.

So you can do that step yourself, explicitly, and point Kopia’s maintained WebDAV backend at it. Same two programs, same data path, same encryption — but the Kopia code carrying your data is supported, and the rclone process becomes yours to configure, log, rate-limit and restart.

Setup

Start the bridge (loopback only, authenticated):

rclone serve webdav gdrive:KopiaRepo \
--addr 127.0.0.1:8973 \
--user kopia --pass <random> \
--vfs-cache-mode writes

--vfs-cache-mode writes matters — Google Drive can’t do partial or seeking writes.

Then create the repository against it:

kopia repository create webdav \
--url http://127.0.0.1:8973 \
--webdav-username kopia \
--webdav-password <same>

Measurements

kopia repository validate-provider → “All good” — conditional creates, list responses, partial reads, full reads, metadata, and a 30-second concurrency test over four connections. This was the check that convinced me the path was sound.
Source 93.4 GB, 219,188 files
Stored 67.9 GB in 723 blobs (zstd, ~100 MB packs)
Backup time 19 min 22 s (~500 Mbit/s, gigabit fibre)
Ignored errors 1 (a locked GPU shader cache file)
VSS engaged correctly when run elevated

Restore verified from a clean room: a Docker container with no rclone.conf, no repository config and no cached credentials, connected using only offline-stored credentials. Restored files came back byte-identical (8/8 SHA-256 match), including a filename with Japanese characters. A separate partial restore of 51.3 GB / 56,308 files completed without errors before I stopped it for unrelated reasons.

Two settings worth knowing, neither obvious:

  • Compression is OFF by default. Creation prints Compression disabled while repository status separately reports Content compression: true — that’s the repository capability, not the policy. Easy to misread. kopia policy set --global --compression=zstd.
  • A single unreadable directory aborts the whole walk. One Access is denied under AppData\Local propagated to the root and killed a full profile estimate. --ignore-dir-errors / --ignore-file-errors turn that into a completed backup plus a reported warning list.

Caveats — please read these before copying me

  • Two days, two snapshots. I have no long-term data, nothing on how this behaves after months of maintenance and expiry cycles.
  • One machine, one provider. Windows 11, Kopia 0.23.1, rclone 1.75.0, Google Drive via drive.file scope with my own OAuth client.
  • I have not benchmarked the rclone backend against this. I can’t tell you it’s worse — only that this path is the maintained one and this is how it performed.
  • It’s one more moving part. The bridge must be running before any backup, and if it dies the backup fails. That needs supervision and failure alerting; you don’t get Kopia managing the subprocess for you any more.

If anyone is running this at larger scale or over longer periods, I’d be interested to hear whether it holds up — particularly through repository maintenance and snapshot expiry, which is where the corruption reports in this thread seemed to concentrate.