backup/restore of Git LFS objects broken
Summary
After a restore through the backup-utility the Git LFS objects are inaccessible because they have moved up one directory level in the git-lfs bucket.
Steps to reproduce
$ kubectl exec <taskrunner-pod> -it -- backup-utility
delete and recreate the git-lfs bucket
$ kubectl exec <taskrunner-pod> -it -- backup-utility --restore -t <backup-timestamp>
visit the project in the UI and click on a file that is tracked by LFS.
This is aggravated by not being able to fix it with a forced git lfs upload, e.g.
git lfs push --all origin
or
git lfs push --object-id origin <objectid>
Configuration used
I've placed the object storage in GCS buckets. Nothing special about the configuration. Couldn't test on the Minio instance because of #1765.
Current behavior
E.g. an object that gets stored as 2e/c7/b8969c0cbf6e... gets restored as c7/b8969c0cbf6e...
Running another backup/restore cycle restores the object as b8969c0cbf6e... in the root of the bucket.
Expected behavior
The objects should be restored with the full directory path, e.g. 2e/c7/b8969c0cbf6e...
Versions
- Chart: 3.3.3, first noticed with 3.2.4.
- Platform:
- Cloud: GKE
- Kubernetes: (
kubectl version
)- Client: v1.18.2
- Server: v1.15.11-gke.9
- Helm: (
helm version
)- Client: v3.2.1
Relevant logs
I didn't see anything interesting or helpful. Certainly no errors.
Edited by Christoph Badura