[mvanhorn]

Why

With multipart download enabled, a backup download from Ceph RGW (including Hetzner Object Storage) fails for every part archive that was stored as a multipart object. The storage returns HTTP 412 PreconditionFailed and the download uses up its retries.

The multipart download sets concurrency and part size but leaves the transfer manager on its default, partNumber GETs. That mode takes the ETag from the first response and sends it as If-Match on later requests, while RGW answers a partNumber GET with that part's own ETag rather than the multipart object's ETag, so the precondition fails from the second part on. Byte-range GETs of the same object, with If-Match set to the object ETag, succeed.

What changed

s3.multipart_download_type, also read from S3_MULTIPART_DOWNLOAD_TYPE, defaults to part and validation accepts only part and range, case-insensitively, with a blank value keeping the part strategy. On the multipart download path the value is passed as GetObjectType: range selects byte-range GETs sized by the existing chunk calculation, and part keeps partNumber GETs. The README and changelog note that this runs only when allow_multipart_download is true and download_max_bytes_per_second is 0.

Tests

• gofmt -l on the edited Go files printed nothing, so those files are already formatted.
• go vet ./pkg/config/... ./pkg/storage/... finished with no reported issues.
• go test ./pkg/config/... ./pkg/storage/... passed for the config, storage, bwlimit, and object_disk packages.
• Ran make test in a Linux container (golang:1.24) for the clickhouse-backup S3Config change; it passed.

Fixes #1632

[mvanhorn]

Thanks @Slach for the follow-ups and the approval. Making range the default and rejecting an empty value both make sense, since the 412 from Ceph RGW is otherwise easy to hit with the old default.