Can't make backup jobs and pitr work properly

I’m testing the XtraDB Operator v.1.17 on a AKS cluster (version 1.33.2). The cluster is running well, but I’m unable to make the backups and PITR to work properly.

I deployed MinIO in my cluster to use as S3 compatible storage for backups. I’m able to reach MinIO endpoint from another pod, and I tested my access key and secret key.

Unfortunately, backup jobs and pitr are both crashing. I’ve attached the pods’ logs

Here is the backup section from my cluster’s yaml file:

backup:
pitr:
enabled: true
storageName: minio-mysql
timeBetweenUploads: 60
timeoutSeconds: 60
storages:
minio-mysql:
type: s3
verifyTLS: false
s3:
bucket: mysql-operator-test
credentialsSecret: mysql-backup-s3
region: us-east-1
endpointUrl: https://myminio-hl.minio-tenant.svc.cluster.local:9000
schedule:
- name: “daily-backup”
schedule: “0 0 * * *”
keep: 5
storageName: minio-mysql

The credentials secret is defined like this:

apiVersion: v1
kind: Secret
metadata:
name: mysql-backup-s3
type: Opaque
data:
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:

What am I missing?

Thank you

backup.log (20.5 KB)

pitr.log (238 Bytes)

As a complement, I also tried with Azure Blob Storage, and I get basically the same errors.

Logs from PITR pod:

025/08/05 21:19:26 initializing collector
2025/08/05 21:19:27 creating collector functions
2025/08/05 21:19:27 running binlog collector
2025/08/05 21:19:28 reading binlogs from pxc with hostname= cluster1-pxc-0.cluster1-pxc.mysql-test.svc.cluster.local
2025/08/05 21:19:39 ERROR: collect binlog files: load binlog cache: get cache from storage: download stream: gtid-binlog-cache.json: Get “https://my-storage-account.blob.core.windows.net/mysql-operator/gtid-binlog-cache.json”: net/http: invalid header field value for “Authorization”

Hello, @eprevost ! Thank you for your request.
Could you please recheck your azure secret? It should look like this:
apiVersion: v1
kind: Secret
metadata:
name: azure-secret
type: Opaque
data:
AZURE_STORAGE_ACCOUNT_NAME:
AZURE_STORAGE_ACCOUNT_KEY:
Without any newlines or spaces
Could you please also try to verify that the base64-encoded values decode to clean strings with no extra characters like line breaks, spaces, or hidden symbols.

Hi,

Yes, that is exactly the template I used for the secret. The strings are base64 encoded. I decoded them to check if they have any extra character, it looks good. I followed instructions in the documentation to encode the values: echo “the string” | base64 –wrap=0

the only space in the yaml is between the “:” and the base64 value

Oh. I used different tools to check the encoded values. echo “the string” | base64 –wrap=0 adds a new line character at the end of the string. echo -n “the string” | base64 –wrap=0 should be used instead.

I doubled-check the documentation.. It mentions echo -n. So.. my bad, I read too quickly.

Don’t worry! Does it work now?

PITR works, but full backups still fails. I modified the configuration to add –verbose parameter to xbcloud. It looks like it still have issues with authentication with Azure Blob storage:

2025-08-06 13:37:50.782 INFO: [SST script] + xbcloud put --parallel=4 --curl-retriable-errors=7 --verbose --storage=azure cluster1-2025-08-06-13:37:43-full
2025-08-06 13:37:50.811 INFO: [SST script] * Trying 20.60.242.227:443…
2025-08-06 13:37:50.811 INFO: [SST script] * Connected to .blob.core.windows.net (20.60.242.227) port 443 (#0)
2025-08-06 13:37:50.811 INFO: [SST script] * ALPN, offering h2
2025-08-06 13:37:50.811 INFO: [SST script] * ALPN, offering http/1.1
2025-08-06 13:37:50.811 INFO: [SST script] * CAfile: /etc/pki/tls/certs/ca-bundle.crt
2025-08-06 13:37:50.811 INFO: [SST script] * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
2025-08-06 13:37:50.811 INFO: [SST script] * ALPN, server did not agree to a protocol
2025-08-06 13:37:50.811 INFO: [SST script] * Server certificate:
2025-08-06 13:37:50.811 INFO: [SST script] * subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=.blob.core.windows.net**
2025-08-06 13:37:50.811 INFO: [SST script] * start date: Jun 21 01:47:54 2025 GMT
2025-08-06 13:37:50.811 INFO: [SST script] * expire date: Dec 18 01:47:54 2025 GMT
2025-08-06 13:37:50.811 INFO: [SST script] * subjectAltName: host “storageaccount.blob.core.windows.net” matched cert’s "
.blob.core.windows.net"
2025-08-06 13:37:50.811 INFO: [SST script] * issuer: C=US; O=Microsoft Corporation; CN=Microsoft Azure RSA TLS Issuing CA 04
2025-08-06 13:37:50.811 INFO: [SST script] * SSL certificate verify ok.
2025-08-06 13:37:50.811 INFO: [SST script] > HEAD /mysql-operator?comp=metadata&restype=container HTTP/1.1
2025-08-06 13:37:50.811 INFO: [SST script] Host: storageaccount.blob.core.windows.net
2025-08-06 13:37:50.811 INFO: [SST script] Accept: /
2025-08-06 13:37:50.811 INFO: [SST script] Accept-Encoding: gzip
2025-08-06 13:37:50.811 INFO: [SST script] Authorization: SharedKey
2025-08-06 13:37:50.811 INFO: [SST script] x-ms-access-tier: Hot
2025-08-06 13:37:50.811 INFO: [SST script] x-ms-date: Wed, 06 Aug 2025 13:37:50 GMT
2025-08-06 13:37:50.811 INFO: [SST script] x-ms-version: 2020-06-12
2025-08-06 13:37:50.811 INFO: [SST script]
2025-08-06 13:37:50.811 INFO: [SST script] * Mark bundle as not supporting multiuse
2025-08-06 13:37:50.811 INFO: [SST script] < HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
2025-08-06 13:37:50.811 INFO: [SST script] < Transfer-Encoding: chunked
2025-08-06 13:37:50.811 INFO: [SST script] < Server: Microsoft-HTTPAPI/2.0
2025-08-06 13:37:50.811 INFO: [SST script] < x-ms-request-id: f917cd5f-301e-0069-6ed7-06b891000000
2025-08-06 13:37:50.811 INFO: [SST script] < x-ms-error-code: AuthenticationFailed
2025-08-06 13:37:50.811 INFO: [SST script] < Date: Wed, 06 Aug 2025 13:37:50 GMT
2025-08-06 13:37:50.811 INFO: [SST script] <
2025-08-06 13:37:50.811 INFO: [SST script] * Connection #0 to host storageaccount.blob.core.windows.net left intact
2025-08-06 13:37:52.800 INFO: (8b3540ac-8493, ‘ssl://0.0.0.0:4567’) turning message relay requesting off
2025-08-06 13:38:02.073 INFO: [SST script] 2025/08/06 13:38:02 socat[379] E write(1, 0x559565016000, 8192): Broken pipe
2025-08-06 13:38:02.074 INFO: [SST script] + (( 0 == 0 ))
2025-08-06 13:38:02.074 INFO: [SST script] + touch /tmp/backup-is-completed
2025-08-06 13:38:02.075 INFO: [SST script] + log INFO ‘Backup finished’

Strangely, when I add –verbose to xbcloud, the pod ends successfully, but the backup is definitely not in the azure blob container:

2025-08-06 13:38:02 [INFO] Backup was finished successfully

If you try to run fixed keys for minio, does it work? I can suggest to add another key for azure storage (if it is possible) and test with it. Sometimes we met the problem with keys, if they have special characters.
I will recheck why we return successful backup if it is actually failed.

Switching back to minio worked with cleaned up secret.

For Azure, I tried to delete and recreate the secret, but it still not working. I’ll try with the second key.

I was able to do a full backup to azure blob storage using the second storage account access key in a new secret

1 Like