milvus-backup 0.6 adds snapshot restores with indexes on Milvus 3.0.1
The bigger win is not just restore speed but that indexes come back pre-built, so recovered collections are query-ready without a rebuild window that can stretch much longer on large datasets. Teams running disaster-recovery drills or migrations on Milvus 3.0.1 or later should switch to snapshot backups via the milvus-backup tool. Compared with binlog restores, snapshots eliminate the post-restore index rebuild wait entirely.
Zilliz released milvus-backup 0.6, which uses the snapshot backup format on Milvus 3.0.1 and later to restore data and existing indexes together. Snapshot restores skip the row-by-row import scan and index rebuild that the older binlog backup format requires. In an internal test with three collections totalling roughly 92 GB of data and 32 GB of indexes, snapshot restore took 324 seconds versus 505 seconds for binlog restore, about 36% less time, with indexes still pending rebuild afterward. Collection loading and query verification follow the restore step.
Rebuilding vector indexes can add a long wait when restoring a Milvus backup. On Milvus 3.0.1 and later, 𝗺𝗶𝗹𝘃𝘂𝘀-𝗯𝗮𝗰𝗸𝘂𝗽 𝟬.𝟲 𝘂𝘀𝗲𝘀 𝘁𝗵𝗲 𝘀𝗻𝗮𝗽𝘀𝗵𝗼𝘁 𝗯𝗮𝗰𝗸𝘂𝗽 𝗳𝗼𝗿𝗺𝗮𝘁 to restore data and existing indexes together. Snapshot restores avoid the row-by-row import scan and index rebuild required by the older binlog backup format. After restoration, you can load the collection and verify your queries. In our internal test, we used three collections with 10 million 768-dimensional vectors each: roughly 92 GB of data and 32 GB of indexes. • Snapshot restore: 𝟯𝟮𝟰 𝘀𝗲𝗰𝗼𝗻𝗱𝘀, including indexes. • Binlog restore: 𝟱𝟬𝟱 𝘀𝗲𝗰𝗼𝗻𝗱𝘀, with indexes still to rebuild. That’s about 𝟯𝟲% 𝗹𝗲𝘀𝘀 𝘁𝗶𝗺𝗲 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗿𝗲𝘀𝘁𝗼𝗿𝗲 𝘁𝗮𝘀𝗸 in this test. Collection loading and query validation come afterward. For your next migration or recovery drill, create a snapshot backup so you can github.com/zilliztech/mil… ng with the data. Learn how to restore Milvus from a snaphot: https://t.co/szRi6ALNT1 💬 0 🔄 0 ❤️ 0 👀 58 ⚡