Skip to main content

导入文件系统

不论是企业版还是社区版，JuiceFS 都支持用 juicefs [dump|load] 导出、导入文件系统的元数据。由于 JuiceFS 采用元数据与数据分离的架构，文件数据独立存储在你所选用的对象存储服务，因此导入文件系统，事实上就是导入元数据的过程——对象存储数据并不需要搬运。如果你还不熟悉这种分离存储的设计，阅读我们的架构介绍。

提示

和 JuiceFS 社区版不同，你不需要特意用 juicefs dump 来备份 JuiceFS 企业版的元数据——我们的运维团队已经保证了所有元数据服务都在定期备份。简而言之，企业版用户不需要操心备份和恢复的工作。

因此对于企业版，导出和导入功能可以用来：

  • 从企业版迁移到社区版，具体的操作步骤未在本章介绍，如有需要请联系我们的工程师
  • 导出元数据，用于分析排查

下面以从社区版迁移到企业版为例，介绍如何导入文件系统。

兼容性注意事项​

社区版和企业版的文件系统是兼容的、可以互相迁移，但需要注意：JuiceFS 企业版支持并默认开启「UID／GID 自动映射」，简单来说，JuiceFS 会将同名的用户和组映射成相同的 UID / GID。但由于社区版并未实现该特性，因此对于导入的文件系统，会自动禁用自动映射，防止产生权限错乱问题。

停写​

导出元数据之前，必须确保源文件系统已经停写、不会发生任何改动。确切地说，不光是需要提前停写，而且所有的非只读客户端都必须卸载，防止任何后台任务、碎片合并影响数据完整性。

为了保险起见，用 juicefs status 命令确保所有客户端均已下线（Sessions 字段为空），再进行后续步骤。

导出文件系统​

导出之前，先将文件系统的配置记录下来，比方说 block size、压缩和加密设置，这些设置都需要在目标文件系统进行对齐，导入才能顺利运行。不难想象，如果源文件系统和目标文件系统使用不同的 block size，或者压缩设置，那么对象存储的数据是绝对无法交叉读取的。

在一个能够访问元数据引擎的环境，使用 status 命令就能打印这些信息：

$ juicefs status META-URL
{
  "Setting": {
    "Name": "myjfs",
    "UUID": "6b0452fc-0502-404c-b163-c9ab577ec766",
    "Storage": "s3",
    "Bucket": "https://xxx.s3.amazonaws.com",
    "AccessKey": "xxx",
    "SecretKey": "removed",
    "BlockSize": 4096,
    "Compression": "none",
    "TrashDays": 1,
    "MetaVersion": 1
  },
  ...
}

接下来，使用 dump 命令导出 JSON 格式的文件系统元数据：

# 在目标文件添加 gz 后缀以启用压缩
juicefs dump META-URL /tmp/meta.json.gz

在导出结果中，同样也包含了文件系统的配置信息，如果在前序步骤中的 juicefs status 输出信息没有保存好，也可以直接从 JSON 文件中获取：

# 记录其他关键的文件系统配置，这些设置都记录在 JSON 文件的 Setting 字段中，此处不再一一列举
head -n 20 meta.json

元数据已经导出，文件系统的配置也已经记录好了，接下来开始创建目标文件系统。

准备目标文件系统​

导入流程的目标集群必须是全新的元数据集群，不能存在任何已有的文件系统，请提前联系 Juicedata 工程师为你创建新的专有区域、部署元数据服务，确保在全新的集群操作导入。

登录云服务控制台，点击右上角「创建文件系统」，但并不急着填写信息，而是继续点击对话框右上角的「导入文件系统」，在接下来的界面中仔细阅读各项设置，并按照源文件系统的情况进行填写。

import file system

导入元数据​

导入元数据需要用 JuiceFS 客户端来执行，因此你需要先挂载好文件系统。如果你尚不熟悉如何安装 JuiceFS 客户端、挂载文件系统，可以阅读「快速上手」。

# 挂载文件系统
juicefs mount myjfs /jfs

# 导入元数据文件
juicefs load /jfs /tmp/meta.json.gz

如果两个文件系统的关键设置都正确对齐，那么导入命令会顺利完成（退出码为 0）。接下来用 ls 访问挂载点，就能够看到文件元数据已经顺利导入了。挑选一个有实际内容的文件来读取、确认一切运作正常吧。

验证​

导入完毕以后，遵循下方步骤核实文件系统正确运行：

  • 再次核实源文件系统已经彻底卸载所有客户端、没有任何写入。这非常重要，如果在导出以后，源文件系统仍有修改，则会造成不一致，使导入数据损坏；
  • 读取一个很久以前创建或修改的文件（mtime 尽可能早），验证能够正常读取；
  • 读取一个最近创建或修改的文件（mtime 尽可能晚），验证能够正常读取；
  • 用类似 date > delete.txt 的命令验证写入正常，请不要使用 touch 命令，他是纯元数据操作，无法完整验证写入功能。

如果以上验证和测试均顺利通过，则认为导入成功，可以继续对接和使用。

如果不确定源文件系统是否彻底停写，或者读取测试果真出现问题，按照以下步骤排查：

  • 如果源文件系统是社区版 JuiceFS，首先检查元数据引擎的数据库日志，核实导出以后是否仍有修改；

  • 运行 juicefs fsck 子命令，扫描损坏文件：

    juicefs fsck myjfs

  • 根据扫描结果评估损坏的范围和原因，以及是否需要重新导出。如果确实是源文件系统未彻底停写导致的，那么再次导出时，需要提前用 juicefs status 命令核实所有客户端均已下线。如果无法确定损坏的原因，联系 Juicedata 工程师一起协查。

设置付费方案​

验证完毕后，请根据目前文件系统的用量，选择合适的付费方案。云服务用户请前往这里操作，私有部署用户请联系 Juicedata 工程师获取对应的操作步骤。

最后于 更新
Follow us on X
Let's chat on Slack