误执行recreate_collection后，如何恢复Milvus独立版的集合数据？

兄弟，先别慌！你数据卷还占着8.2G，说明原始数据文件根本没丢，只是集合的元数据被清掉了，Milvus认不出这些数据而已。下面给你一步步来操作，记得每一步都小心，先备份是关键！

第一步：紧急停掉Milvus容器，避免数据被覆盖 #

先把正在运行的Milvus容器停了，防止后续操作的时候有进程在读写数据，搞出意外：

# 先查一下你的Milvus容器名，替换成自己的
docker ps | grep milvus
docker stop <你的Milvus容器名称>

第二步：全量备份数据卷，留好后手 #

这一步绝对不能省！把整个Milvus数据目录复制一份备份，哪怕后面操作炸了，还能回退：

# 假设你的Milvus数据卷在当前目录的volumes/milvus下，替换成你实际的路径
cp -r volumes/milvus volumes/milvus_full_backup_$(date +%Y%m%d)

第三步：找回原集合的数据标识（ID） #

Milvus的所有数据文件都是按集合的唯一ID来分类存储的。你可以进入data目录，查看各个子文件夹的名称，那串字符就是原集合的ID：

# 进入数据目录
cd volumes/milvus/data
# 查看insert_log下的文件夹，这个文件夹名就是原集合的ID
ls insert_log/

记下来这个ID，比如假设是123456，后面要用。

第四步：重新创建和原集合完全一致的空集合 #

启动Milvus容器，然后用你常用的客户端（比如pymilvus、Milvus CLI）创建一个和原集合结构完全相同的集合：

• 字段名、字段类型必须和原来一模一样
• 向量维度、距离度量方式（比如L2、IP）要完全一致
• 索引类型、索引参数也要和之前的相同（不然后续加载数据会失败）

创建好之后，再停掉Milvus容器，然后查看新集合的ID：

docker stop <你的Milvus容器名称>
cd volumes/milvus/data
ls insert_log/

这时候会看到一个新的文件夹名，就是新集合的ID，比如654321。

第五步：把原数据迁移到新集合的目录下 #

把原集合ID对应的所有数据文件，复制到新集合ID的目录里：

# 替换下面的old_id和new_id为你实际的ID
old_id=123456
new_id=654321

# 复制插入日志
cp -r insert_log/$old_id/* insert_log/$new_id/
# 复制delta日志
cp -r delta_log/$old_id/* delta_log/$new_id/
# 复制索引文件
cp -r index_files/$old_id/* index_files/$new_id/
# 复制mmap数据
cp -r mmap/$old_id/* mmap/$new_id/

第六步：启动Milvus，验证数据是否恢复 #

启动Milvus容器，然后用客户端连接，查看新集合的统计信息（比如collection.num_entities()），或者执行简单的查询，看看数据是不是回来了。

额外提醒：如果有元数据备份的话更简单 #

如果你之前有备份过Milvus的元数据库（默认是volumes/milvus/meta/meta.db），那直接停掉Milvus，把备份的meta.db替换掉当前的meta.db，然后重启Milvus就行，这是最快的方法。

内容来源于stack exchange