Google Drive backend error: Trying to non-existent DeleteBlob(...)

I’m using Google Drive as the backend for my backups, and have noticed these random error messages during any operation:

Trying to non-existent DeleteBlob(sfda9e64e9c97382344c3706f91acc5a6-s1d78b78bd77db14313c)
Trying to non-existent DeleteBlob(s4ea588a4ec01dd1857296ade9fa0b021-sdaa2e8dbbfb376c513c)
Trying to non-existent DeleteBlob(sa97a7c0e6defa1d8ffc1daca52d5a77e-s85a3b0eecdc9a2bf13c)

These will flood the terminal during a kopia maintenance run --full

I am getting these errors using either the native gdrive or rclone backends. It’s understandable that GDrive is not meant to be used realiably by third party tools, like kopia, but I am curious if anyone else is having the same experience, or if you found any way to avoid that.

Some backups I have in Google Drive work well, while others are haunted by these errors messages.

Best regards!

FYI, the blobs referenced in these error messages are still present Google Drive, except kopia seems to be unable to delete them properly because the google API can’t find the requested blob for some reason.

# kopia --log-level=debug blob delete --dangerous-commands=enabled sfda9e64e9c97382344c3706f91acc5a6-s1d78b78bd77db14313c
throttling limits from connection info	{"limits":{}}
finished initial cache scan	{"cache":"contents","duration":"10.670806ms","totalRetainedSize":1905879668,"tooRecentBytes":124276580,"tooRecentCount":524,"maxSizeBytes":5242880000,"limitBytes":0,"inUsePercent":36}
finished initial cache scan	{"cache":"metadata","duration":"1.112315ms","totalRetainedSize":42743878,"tooRecentBytes":12584395,"tooRecentCount":85,"maxSizeBytes":5242880000,"limitBytes":0,"inUsePercent":0}
finished initial cache scan	{"cache":"index-blobs","duration":"390.113µs","totalRetainedSize":8542543,"tooRecentBytes":82170,"tooRecentCount":10,"maxSizeBytes":5242880000,"limitBytes":0,"inUsePercent":0}
[STORAGE] concurrency level reached	{"maxConcurrency":1}
[STORAGE] ListBlobs	{"prefix":"xw","resultCount":3,"error":null,"duration":"284.093707ms"}
[STORAGE] concurrency level reached	{"maxConcurrency":3}
[STORAGE] concurrency level reached	{"maxConcurrency":2}
[STORAGE] ListBlobs	{"prefix":"xn6_","resultCount":0,"error":null,"duration":"357.564871ms"}
[STORAGE] ListBlobs	{"prefix":"xn4_","resultCount":0,"error":null,"duration":"421.907759ms"}
[STORAGE] ListBlobs	{"prefix":"xn5_","resultCount":12,"error":null,"duration":"426.313387ms"}
[STORAGE] ListBlobs	{"prefix":"xn3_","resultCount":0,"error":null,"duration":"428.167187ms"}
Trying to non-existent DeleteBlob(sfda9e64e9c97382344c3706f91acc5a6-s1d78b78bd77db14313c)
[STORAGE] DeleteBlob	{"blobID":"sfda9e64e9c97382344c3706f91acc5a6-s1d78b78bd77db14313c","error":null,"duration":"848.504278ms"}
got error No results found for blob id (_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef): BLOB not found when getFileIDByblobID(_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef) (#0), sleeping for 100ms before retrying
got error No results found for blob id (_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef): BLOB not found when getFileIDByblobID(_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef) (#1), sleeping for 100ms before retrying
got error No results found for blob id (_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef): BLOB not found when getFileIDByblobID(_log_20251220122250_e00e_1766244172_1766244172_1_7c0c63190f46f173631c17838c1429ef) (#2), sleeping for 100ms before retrying
[STORAGE] Close	{"error":null,"duration":"2.168µs"}

If anyone else finds this pickle… here’s what I found.

Turns out, permissions on a Shared Google Drive must be full “Administrator”. Apparently “Content Administrator” does not have all necessary permissions for kopia to work properly.

Even though the non-existent blob messages no longer appear, gdrive native support is still unstable. That is certainly not a kopia issue, but rather a Google API that does not expect to be served as a backup storage for third party tools.

I’ve had better results with rclone as a backend, but the repo still gets corrupted quite easily. As reported by other users, if one single blob goes missing for any reason, kopia is unable to recover and the entire repo is compromised. That’s happened a few times for me now, so I’ll be moving on to other backends.

I want to thank the Kopia community for the excellent tool, so thank you!