企业官网建设流程全解析

Supermemory 自托管版数据目录在哪里、如何备份与迁移

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory

如果你在本地跑 Supermemory 的自托管二进制（supermemory-server），积累了一批记忆、文档和文件，就需要一个明确的备份对象；换机器或变更部署位置时，则需要把这份数据迁移过去。自托管文档给出的结论是：默认情况下全部状态都存放在一个目录里，这个目录"可以被备份或移动"（a single directory you can back up or move）。本文基于 Self-Hosting Quickstart 与 Self-Hosting Configuration，说明数据目录的位置、用什么配置变更位置、备份和迁移怎么做、以及如何验证结果。适用于 macOS（Apple Silicon & Intel）与 Linux（x64 & arm64）上的自托管二进制。

数据都存放在哪两个位置

Quickstart 的 "Where things live" 一节给出了完整清单：

另外两个事实决定了备份范围：

• 上传的文件（PDF、图片）"stored on local disk inside$SUPERMEMORY_DATA_DIR"，由服务器通过/files/:key提供访问——它们也在数据目录内，备份目录即覆盖这些文件（见 Configuration 的 File storage 一节）。
• 首次启动向导里选择的 LLM / 嵌入模型配置是加密保存在数据目录下的（见 Embeddings (self-hosted)）。

备份的核心对象因此是两个：数据目录 +~/.supermemory/env。前者决定数据和 API key 能否在新环境恢复，后者决定安装器保存的模型提供商密钥能否继续被加载。

如何确认当前机器的数据目录

两个文档化的确认方式：

1. 看首次启动的输出。文档给出的启动输出（示例结果）如下：

┌──────────────────────────────────────────────────┐ │ url http://localhost:6767 │ │ database ./.supermemory │ │ api key sm_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx │ │ org id xxxxxxxxxxxxxxxxxxxxxx │ └──────────────────────────────────────────────────┘

database一行就是数据目录，api key一行的密钥是所有请求的 Bearer token，文档明确要求保存好它。

2. 查配置文档的默认值：SUPERMEMORY_DATA_DIR的默认值是./.supermemory，即服务器启动时所在目录下的.supermemory子目录；若你通过环境变量改过位置，以环境变量为准。

备份数据目录

文档没有提供专用的备份子命令，操作路径就是"备份或移动这个目录"本身。用普通 shell 复制/归档即可完成，这类命令只读取源文件、不修改服务器数据：

# 归档数据目录（.supermemory 为默认数据目录； # 若设置过 SUPERMEMORY_DATA_DIR，则归档该环境变量指向的目录） tar -czf supermemory-backup.tar.gz .supermemory # 备份安装器保存的密钥文件 cp ~/.supermemory/env supermemory-env-backup

什么时候必须做备份，文档给了一个明确场景：回滚版本之前。Quickstart 的版本固定小节写道：安装器只会替换二进制，但旧版服务器可能无法理解新版产生的数据或 schema 变更，因此回滚前先备份数据目录：

# 安装（或回滚到）指定版本，而不是 latest curl -fsSL https://supermemory.ai/install | bash -s -- 0.0.3

由于数据目录里含 auth secret，备份文件与服务器凭据同等敏感，应放在受控位置，不要随手分发。

迁移到新机器

迁移就是"在新机器上还原数据目录，再让服务器指向它"。完整路径：

1. 在新机器安装二进制。注意目标版本不应低于写入数据的那台机器的版本，否则按上述警告，旧服务器可能无法理解新数据：

curl -fsSL https://supermemory.ai/install | bash # 或 npx supermemory local / bunx supermemory local

2. 把上一步的备份传输到新机器，还原数据目录。下面沿用文档生产示例使用的路径/var/lib/supermemory：

# 还原后得到 /var/lib/supermemory 数据目录 tar -xzf supermemory-backup.tar.gz -C /var/lib # 若要继续使用安装器保存的提供商密钥，把 env 文件还原到 # ~/.supermemory/env（~/.supermemory 目录不存在时先创建） cp supermemory-env-backup ~/.supermemory/env

如果你的还原位置就是服务器启动目录下的默认.supermemory，则无需下面的环境变量，直接运行即可。

3. 指向新位置并启动：

SUPERMEMORY_DATA_DIR=/var/lib/supermemory supermemory-server

SUPERMEMORY_DATA_DIR的作用在 Configuration 中定义为 "Where the graph engine's data, auth secret, and model cache live"，默认./.supermemory。文档的生产.env示例正是这样用的：

# Persistent data location SUPERMEMORY_DATA_DIR=/var/lib/supermemory

4. 验证。启动输出中database一行应显示你设置的位置（或默认的./.supermemory），api key应为原密钥——auth secret 随数据目录迁移，API key 因此保持不变。再用文档 Quickstart 中的搜索请求确认旧数据可被检索（sm_...替换为启动输出中的 API key，containerTag换成你实际使用过的值）：

curl http://localhost:6767/v3/search \ -H "Authorization: Bearer sm_..." \ -H "Content-Type: application/json" \ -d '{ "q": "what food should I avoid?", "containerTag": "user_dhravya" }'

能返回此前写入的记忆内容，说明迁移完成。

迁移时必须保持一致的约束

• 嵌入配置不能悄悄变化。SUPERMEMORY_EMBEDDING_DIMENSIONS必须与模型和已存储数据一致；如果配置的维度与存储数据不一致，服务器会拒绝启动。换嵌入模型不支持就地进行，文档给出的出路是"使用全新数据目录或全量重新摄入"——迁移场景下最稳妥的做法是提供商、模型、维度三项与原机器完全一致（见 Embeddings (self-hosted) 的 "Changing models later" 一节）。
• 版本方向只升不降。日常升级用supermemory-server upgrade；从新版回退到旧版前必须先备份数据目录，且接受"旧版可能不识别新版数据"的风险（原文警告）。
• 自托管二进制不包含平台专属功能（Connectors、托管 MCP 等），迁移不涉及这些配置；它们只存在于托管平台（见 Configuration 的 "Platform-only features"）。

迁移完成后，验证落点就是上面两条：启动输出显示正确的database路径与原有api key，搜索接口能召回迁移前的数据。后续要改模型或做多语言部署，再按 Embeddings (self-hosted) 的说明从全新数据目录开始，并重新摄入内容。

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory