cannot make backup. no data found in minio

[maxshatskiy]

I have create a "standalone" setup in K8S using the following manifest.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: ...
labels:
app: milvus
spec:
mode: standalone
components:
image: milvusdb/milvus:v2.5.7
imagePullPolicy: IfNotPresent
config:
common:
security:
authorizationEnabled: true

and have the following PODS:

I also have the following services running:

Then I connected using Python SDK and inserted data and I can access collection using python SDK.

However, when I try to make backup using milvus backup with the following configuration:

it gives me errors that no data is found:

when I list buckets on minio:

I cannot understand where are the data which I inserted and can access with Python SDK and how to make backup.

Unrelated question, is there way to change default minio password in the K8S manifest.

[yhmo]

Possible reasons:

1. the milvus standalone is using "a-bucket" as storage bucket, while the milvus-backup is trying to copy files from "milvus-bucket".
2. the data you inserted is still in memory buffer of datanode, not persisted into storage. You can call client.flush(collection_name="xxx") to force flush the data to storage.

[maxshatskiy]

No, I do not have second milvus. I have created it with manifest specified above. Then added new user, changed password of the root, remapped ports from K8S, created collection, so I am pretty sure that this is the only one.
attached is a log. I have created collection ABCDEFG.
milvus-pod-standalone - Kopie.log

[yhmo]

The milvus is using bucketname="lulc", not "milvus-bucket"

[2025/05/20 11:18:59.105 +00:00] [INFO] [storage/remote_chunk_manager.go:97] ["remote chunk manager init success."] [remote=aws] [bucketname=lulc] [root=files]

[maxshatskiy]

Yes, that worked. What is also misleading is that minio shows by default bucket size of 0 and even if I saw this bucket I thought it is also empty.

[yhmo]

Be careful if you manually change the target bucket of milvus.

MinIO/S3 is the major data storage of Milvus, all the original data and index data are stored here. The data is organized as collection/partition/segment/field. Data is stored as column-based.
Etcd stores the system metadata of Milvus, including the schema of collections, runtime address of each component, id/info of segments, etc.

The metadata in Etcd and the data in S3 must be strongly consistent. If you stop the milvus and change the bucket name to another, but the etcd is still the old one, there might be lots of errors after it restarts.

[maxshatskiy]

No, I have not changed it (at least not intentionally). Maybe I am wrong, but it seems to me in was created like this by default, maybe it has taken them from name in the metadata of K8S manifest, not sure.