Fails to run a backup job for the ops-logs component with the following error:
The backup of component Operations Logs is failing due to API error. Check all Log Processor nodes are healthy.
Backup workflow failed for component: ops-logsSystem reports a repository error stating that backup-repo could not read repository data. Investigate the log-processor pod logs, calls to the OpenSearch snapshot API (_snapshot/backup-repo) return an HTTP 500 Internal Server Error with an output similar to the following:
[https://log-store:9200], URI [_snapshot/backup-repo/backup-<timestamp>], status line [HTTP/1.1 500 Internal Server Error]
{"error":{"root_cause":[{"type":"repository_exception","reason":"[backup-repo] could not read repository data from index blob"}]}}
This issue occurs when the backup-repo (the S3 bucket used to store OpenSearch snapshots) becomes corrupted. The expected repository index blob goes missing or falls out of sync with the actual contents of the bucket (e.g., due to concurrent modifications or underlying storage issues). Consequently, OpenSearch disables the repository to prevent any further data corruption.
To resolve this issue, remove the corrupted backup-repo configuration so it can be cleanly recreated, and then restart the backup processing.
Note: Apply this workaround only on the affected cluster's ops-logs namespace, and only when the exact error signature above matches.kubectl annotate bucket ops-logs-bucket -n ops-logs helm.toolkit.fluxcd.io/driftDetection=disabledkubectl -n ops-logs patch bucket.objectstorage.vmsp.vmware.com ops-logs-bucket --type=merge -p '{"spec":{"ttlDays":0}}'kubectl exec -it log-store-0 -n ops-logs -- sh -c \
'OS_USER=$(cat /usr/share/opensearch/config/ops-logs-secrets/username)
OS_PASSWORD=$(cat /usr/share/opensearch/config/ops-logs-secrets/password)
curl --request DELETE --url https://localhost:9200/_snapshot/backup-repo -u "${OS_USER}:${OS_PASSWORD}" -k'kubectl delete po log-processor-0 -n ops-logsAfter a successful application of this workaround, the _snapshot/backup-repo endpoint will respond without a repository_exception, and backup jobs will complete successfully. The log-store and log-processor pods in the ops-logs namespace will remain in a Running/Ready state.