Full maintenance error "error rewriting contents in short packs: failed to rewrite 348 contents"

General Topics
1

hiya my repo is only a few days old and I’m already getting this problem

snapshots do not produce errors, quick maintenance does not produce errors, but full maintenance produces this every time, and the number gets larger each time

Running full maintenance...
GC found 3872 unused contents (6.9 GB)
GC found 4897 unused contents that are too recent to delete (14 GB)
GC found 177952 in-use contents (352.9 GB)
GC found 309 in-use system-contents (263.5 KB)
GC undeleted 0 contents (0 B)
Finished full maintenance.
error rewriting contents in short packs: failed to rewrite 348 contents

I’ve tried kopia snapshot verify at the command line and this shows no errors either

Listing blobs...
  10000 blobs...
Listed 16195 blobs.
Processed 0 objects (0 B). Read 0 files (0 B).
Processed 941 objects (95.6 GB). Read 0 files (0 B).
Processed 2856 objects (284.6 GB). Read 0 files (0 B).
Processed 5233 objects (363.7 GB). Read 0 files (0 B).
Processed 10852 objects (425.3 GB). Read 0 files (0 B).
Processed 26718 objects (440.4 GB). Read 0 files (0 B).
Processed 45395 objects (445.4 GB). Read 0 files (0 B).
Processed 64273 objects (450.6 GB). Read 0 files (0 B).
Processed 80560 objects (456.1 GB). Read 0 files (0 B).
Processed 98765 objects (480 GB). Read 0 files (0 B).
Finished processing 100862 objects (482 GB). Read 0 files (0 B).

and yet the “failed to rewrite” increases every time

my repo is on WebDav and I’ve aready set list parallelism to 1 as the first full maintenance was giving error 429 initially, that seems to have sorted that but I’m still getting this error

I have also tried running maintenance from my other system (both systems have snapshots in this repo) and exactly the same result there

the maintenance CLI logs contain many entries like this one

2026-01-30T12:31:09.114798Z DEBUG kopia/repo [STORAGE] GetBlob	{"blobID":"p71f37bda3bdda64bac331cb3f6578912-s9789fc19ac6cd0b513d","offset":32,"length":2598639,"outputLength":0,"error":"invalid blob offset or length","errorVerbose":"invalid blob offset or length\ngithub.com/kopia/kopia/repo/blob.init\n\t<autogenerated>:1\nruntime.doInit1\n\truntime/proc.go:7670\nruntime.doInit\n\truntime/proc.go:7637\nruntime.main\n\truntime/proc.go:256\nruntime.goexit\n\truntime/asm_amd64.s:1693","duration":"346.7033ms"}

I’ve checked in the repo location and the file is present, and is 2601164 bytes in size. I’ve only checked a few of the named files but they all exist and are not 0 byte files

what should I do next?

I’m tempted to just delete and start again rather than do any verification that involves downloading all the data (it’s a slow server), but also I’m concerned about using this for backups if this issue can come up so quickly and be not so easily resolved

2

seems I cannot restore any data whatsoever either. every attempt to restore anything just gives

Error: error restoring: restore error: copy file: error creating file: unable to open snapshot file for d:\test\test.jpg: unable to open object: a5239dacc0e265e48b365efd30649d91: unexpected content error: error getting cached content from blob "pccbf4d6d5fd410191c85d89f269597eb-s3b58b8af04e2db9913d": failed to get blob with ID pccbf4d6d5fd410191c85d89f269597eb-s3b58b8af04e2db9913d: invalid blob offset or length.

it’s as if no blob files can be opened at all, while the repo itself opens fine and I can continue making snapshots fine, and I can download the blob files from the WebDav server manually without problems

3

okay I just created a new repo in another location on the same WebDav server. it’s been taking a snapshot for an hour so there isn’t much in it, but I cannot restore any of the contents. just getting the same “invalid blob offset or length” error

4

A little bit of more information about your setup would sure help anyone willing to provide aid or some tip. Just going to say that WebDAV on Windows is propably the worst option to choose, as Windows generally impose a 50 MB size limit, afaik. When blobs get larger, Windows might just not retrieve them.

5

it’s WebDav to a cloud storage provider (OpenDrive), so there’s no windows webdav involved, and any issues with WebDav are with them I guess. but that is what seems to be the problem - I’ve now set up rclone to the same provider and that’s working well, full maintenance is running successfully, restores are working successfully, and the snapshot upload speed has more than doubled as well. my suspicion is that their WebDav isn’t correctly reporting file sizes, so every attempt to read blobs fails, despite the fact that the files themselves can be opened no problem (repository settings, policy settings, etc all work fine, and I can download blob files manually using a webdav client no problem)

6

I thought that Windows WebDAV client had that limitation, not the server. Can you check the size of the blobs which can’t be read?