v0.6.1

0.6.1 is a usability and reliability release. It adds live progress to create, restore, delete, and migrate, coordinated two-phase imports for replicating clusters, and more flexible snapshot backup storage. It also includes compatibility updates and storage, verification, and secondary-restore fixes.

Highlights

Live progress for long-running CLI commands

create, restore, delete, and migrate now render live progress when attached to a terminal. create and restore show aggregate and per-collection stages; delete and migrate show object or byte progress, speed, and ETA where available. Piped output remains plain text, so scripts and CI logs do not receive progress-bar frames. (#1270, #1271, #1275, #1278, #1282, #1285, #1317, #1318)

Two-phase restore commits for replicating clusters

Restoring into a Milvus 3.0+ cluster that replicates to secondaries can now hold each import job until its mirror is ready on every secondary, then commit the job on the restore target. The replicated commit brings the secondary mirrors to the same committed state instead of allowing independent auto-commits.

Use the new --secondaries flag, with endpoints separated by commas or supplied repeatedly:

milvus-backup restore -n my_backup \
  --secondaries http://10.0.0.2:19530,http://10.0.0.3:19530

The REST API accepts the same endpoints as the secondaries string array on POST /api/v1/restore.

This flow requires Milvus 3.0+ on the target and every secondary. All clusters must resolve the same staged object-storage paths, either through a shared bucket or synchronized bucket content. It is available for binlog merged imports; snapshot backups and --strategy per_seg are not compatible with it. (#1293, #1297, #1319)

Snapshot backups can cross storage backends

Snapshot backup creation no longer depends on Milvus's provider-side copy. milvus-backup reads the snapshot manifests and copies the bundle files itself, allowing backup data to move between any two supported storage backends. The existing transfer.mode policy controls how the copy is performed. (#1301, #1302)

Restore limitation: snapshot restore still uses a server-side copy within one storage service. The backup storage must therefore be on the target cluster's storage service. For cloud providers, another bucket, account, or region of the same provider is supported; a different provider or a separate self-hosted MinIO deployment is not. In those cases, move the backup to compatible storage before restoring. milvus-backup rejects an incompatible restore instead of producing a partial one.

Verification that scales with large backups

Backup verification now splits oversized listings by whole path levels and verifies the resulting groups in parallel. This avoids relying on one recursive listing that can time out on hierarchical S3-compatible gateways, while small collections still use a single listing. Thanks to @rere950303 for the initial fix in #1295; #1298 generalized the splitting logic into an adaptive path-level approach. (#1295, #1298)

Compatibility and behavior changes

• Milvus 3.0 support: Milvus 3.0.0 and later are supported. Snapshot backup now freezes the collection through the server snapshot API, then has milvus-backup read the manifest and copy the bundle files itself, instead of relying on the server-side snapshot export copy path. Restoring to Milvus 2.4 remains unsupported; the restore floor remains Milvus 2.5. (#1301, #1302)
• Default binlog restore path: with strategy=auto (the default), restores to Milvus 2.5+ now use merged-segment v2 import. Use --strategy per_seg to retain per-segment imports. --use_v2_restore and the REST use_v2_restore field are deprecated but still accepted; an explicit strategy takes precedence. The literal auto is now accepted as well. (#1290, #1306)
• Replicating targets: a restore without --secondaries is rejected before import when the Milvus 3.0+ target reports a replication topology. dataCoord.import.enableInReplicatingCluster=true remains a server-side prerequisite. (#1293)
• Create admission checks: create now checks source storage and the destination artifact directory before accepting a job. Storage failures and an existing backup directory fail before a task is registered, rather than leaving a job to fail later. (#1233, #1282)
• REST edge cases: malformed db_collections values now return a request error instead of being silently ignored. Server access logs and unmatched-route responses now use JSON; server.debugMode remains accepted for configuration compatibility but no longer has an effect. (#1259, #1303)

Other features and fixes

• Add caCertPath under milvus.storage and backup.storage for PEM-encoded private CA certificates. It supports S3-compatible storage with useSSL: true, and Azure; GCP, gcpnative, and local storage reject the setting. (#1287)
• Add asynchronous L0 compaction APIs: POST /api/v1/l0compact and GET /api/v1/get_l0compact, plus the read-only GET /api/v1/has_l0 endpoint. Job-style backup names are accepted, and the source backup is left unchanged. (#1250, #1252)
• Fix renewed collection GC lease tickets being dropped, which could leave GC paused for up to an hour after a long backup. Thanks to @rere950303. (#1227)
• Secondary restore now validates target configuration and zero channel checkpoints before opening replication streams. Repeated unconfirmed stream connections are backed off and summarized instead of flooding logs. (#1289, #1262)
• Snapshot restore now accepts a shard_num override when it equals the bundle's shard count; different values remain rejected. (#1244)
• Secrets in config show, check, and /api/v1/check are now always masked as ****, without retaining leading or trailing characters. (#1316)

New Contributors

• @mvanhorn made their first contribution in #1262
• @KurodaKayn made their first contribution in #1289

Thanks to @rere950303 for the GC lease and verification fixes, and to @lentitude2tk for the L0 compaction API improvements.

Full Changelog: v0.6.0...v0.6.1