Obsidian Sync vs 备份：为什么同步不等于备份
Obsidian Sync vs 备份：理解关键区别
Obsidian Sync 与备份的区分比大多数用户意识到的更重要。同步和备份解决的是根本不同的问题，把它们混为一谈是笔记工作流中最常见的数据丢失原因。
同步在多设备间复制知识库的当前状态。你在笔记本上编辑一条笔记，同步会把这个变更推送到手机、平板和桌面。目标是状态一致：每台设备显示相同的最新版本。同步是双向的、实时的。
备份将知识库的历史状态保存为独立、不可变的快照。备份时，Ginkgo 在某个时间点捕获整个知识库，并将其存储在与工作文件分离的位置。目标是恢复能力：你可以回到任何之前的状态，即使是在破坏性编辑之后。备份是单向的、带版本历史的。
关键的洞察在于两者各自防范什么。同步防范设备丢失——如果笔记本坏了，笔记仍然存在于手机上。备份防范编辑失误、损坏和账户级事件——如果插件静默重写了一百条笔记，备份让你撤销；同步则把损害推送到每台设备。
同步问的是："如何让每台设备达成一致？"备份问的是："如何回到已知良好的状态？"完整的数据保护策略需要同时回答这两个问题，因为单独任何一个都无法覆盖全部失败场景。
Obsidian Sync 的隐藏局限性
Obsidian Sync 是一款工程精良的产品，但它有结构性局限，使其作为唯一的数据保护策略不够充分。理解这些局限是 Obsidian Sync vs 备份分析的第一步。
版本历史上限为 12 个月。Obsidian Sync 保留文件级版本历史最长一年，之后旧版本会被永久清除。如果你在 14 个月后才发现一个缓慢引入的损坏——一个渐进失效的插件、一个格式错误的 frontmatter 字段——同步帮不了你。而保留策略可配置的备份可以保存快照数年。
同步在单文件级别操作，而非知识库级别。你可以把单个文件恢复到之前的版本，但无法用一次操作把整个知识库回滚到已知良好状态。当插件同时损坏几十条相互关联的笔记时，逐文件恢复是繁琐且容易出错的过程。备份快照让你把整个知识库作为一个原子单元恢复。
同步会传播不想要的变更。这是最危险的局限。如果插件重写了笔记、同步冲突覆盖了内容、或你误删了文件夹，这个变更会在几秒内推送到每台同步的设备。同步通过确保同样的损害存在于所有地方来保护你不在某一处丢失数据。
同步依赖单一供应商。你的知识库数据存储在 Obsidian 的服务器上，由你的账户把关。账单失败、政策争议或账户被入侵都可能让你瞬间被锁在整个笔记历史之外。存储在你控制的基础设施上——加密密钥只有你持有——的备份，能在同步无法应对的账户级事件中幸存。
为什么同步不够：真实失败场景
四种场景在 Obsidian 社区反复出现，每一种都暴露了同步单独无法填补的缺口。认识到它们有助于澄清 Obsidian Sync vs 备份的问题有明确答案：两者都需要。
插件损坏传播。一个行为异常的社区插件静默地复制、重写或删除知识库中的笔记。同步忠实地把损坏推送到每台设备。等你注意到时，损害已经无处不在，而同步的文件版本历史只有在受影响文件在过去 12 个月内被编辑过时才有帮助。插件运行前的备份快照是回到正轨的快速路径。
误批量删除。一个按错的快捷键或批量编辑工具中错误的正则表达式，一次移除数百条笔记。同步复制了删除操作。即使你立即发现，每台同步的设备都已经丢失了文件。备份让你可以从几分钟或几小时前恢复被删除的笔记，而不回滚整个知识库。
同步冲突解决失误。当同一条笔记在同步运行前在两台设备上被编辑时，Obsidian 会创建冲突文件。手动解决冲突很繁琐，选错了就会永久丢失内容。备份给你一个冲突前的快照作为对比，即使合并搞砸了也能恢复正确的版本。
账户锁定。密码被入侵、会话令牌被盗或账单失败都可能让你被锁在 Obsidian 账户之外，因此也被锁在同步历史之外。没有独立备份，你的知识库被账户访问劫持。一个加密的、异地的、存储在你控制的基础设施上的备份，是当账户本身成为问题时的恢复路径。
备份如何补充同步：纵深防御
正确的心智模型是纵深防御：同步处理设备间的状态一致，备份处理从任意状态恢复。它们覆盖不重叠的失败模式，两者一起使用给你完整的保护。
备份提供独立性。备份快照与你的 Obsidian 账户、同步订阅和工作知识库解耦。它不会被实时知识库发生的任何事损坏、删除或加密。这种独立性正是同步所缺乏的，它是真正数据安全的基础。
备份捕获知识库级快照。备份不跟踪单个文件版本，而是把整个知识库——笔记、附件、配置、插件设置——作为一个时间点的状态存储。当插件一次破坏几十个文件时，你把整个知识库恢复到破坏前的那一刻，而不是逐文件处理。
备份给你存储控制和零知识加密。Ginkgo 在文件离开你的设备之前用 AES-256-GCM 在本地加密，然后把加密数据存储到你选择的本地硬盘、NAS 或云存储。只有你持有密钥。同步把数据存在 Obsidian 的服务器上；备份存在你控制的基础设施上。
备份支持无限版本历史。配置保留策略——一天的每小时快照、一个月的每日快照、一个季度的每周快照、以及多年的每月快照。没有 12 个月上限。18 个月前引入的缓慢破坏可以恢复，而同步早已清除了相关版本。
同步和备份一起实现了 3-2-1 原则：至少 3 份数据副本，在 2 种不同介质上，1 份异地。同步是一份副本（在 Obsidian 服务器上）；备份是第二和第三份（本地 + 云端，加密）。
Ginkgo Backup 作为 Obsidian Sync 替代方案
如果你在评估 Obsidian Sync 的替代方案，Ginkgo Backup 可以通过两种方式填补这个角色：完全替代，或与同步并行的补充。
完全替代。用 Ginkgo 把知识库备份到你控制的云存储商——Backblaze B2、Cloudflare R2、AWS S3 或任何 S3 兼容服务。你的笔记加密存储在你拥有的存储上，可从任何安装了 Ginkgo 的设备访问。对于多设备访问，把每台设备的 Ginkgo 指向同一个云仓库。这用备份-恢复模型替代了同步的多设备一致性，用存储控制和零订阅成本换取实时同步。
互补使用。保留 Obsidian Sync 用于实时多设备编辑，添加 Ginkgo Backup 用于独立、加密、带版本历史的快照。同步处理"每台设备达成一致"的问题；Ginkgo 处理"恢复到任意之前状态"的问题。这是既想要便利又想要安全的用户的推荐配置。
成本对比随时间推移有利于 Ginkgo。Obsidian Sync 是定期订阅——个人约每年 96 美元。Ginkgo Backup 是一次性 39 美元终身许可证，覆盖无限项目和无限版本历史，无定期费用。三年下来，Ginkgo 花费 39 美元而同步花费 288 美元。对于只需要备份（而非实时同步）的用户，Ginkgo 单独使用是更便宜的 Obsidian Sync 替代方案。
功能方面，Ginkgo 在每个备份维度上匹配或超越同步：无限版本历史（对比 12 个月）、知识库级快照（对比文件级版本）、零知识加密（对比服务器端访问）、以及在你控制的基础设施上存储（对比 Obsidian 服务器）。同步唯一的优势是实时多设备一致性，而 Ginkgo 并不试图提供这一点。
同步与备份协同设置
推荐设置结合 Obsidian Sync 用于实时编辑和 Ginkgo Backup 用于恢复。配置两者大约需要五分钟，给你 Obsidian 知识库最强大的实用数据保护。
步骤 1 — 保持 Obsidian Sync 像现在一样运行。同步处理多设备一致性、冲突文件和最近的文件版本历史。你不需要对同步设置做任何更改。
步骤 2 — 安装 Ginkgo Backup，把你的 Obsidian 知识库文件夹添加为本地文件夹源。Ginkgo 会自动检测 Markdown 文件、附件和 .obsidian 配置文件夹。
步骤 3 — 选择一个与同步数据存储位置不同的备份目标。本地 NAS、外置硬盘或你控制的云存储桶。这正是让备份有价值的独立性——单一故障不会同时摧毁同步和你的备份。
步骤 4 — 设置计划。工作时间每小时备份、夜间每日备份，或如果需要最大粒度的每次变更备份。因为 Ginkgo 是增量的，频繁备份在存储和性能上几乎零成本。
步骤 5 — 验证备份。打开一个快照，把一条随机笔记恢复到临时文件夹，确认内容和附件完好。从未恢复过的备份只是假设，不是备份。每月重复此检查。
同步和 Ginkgo 一起运行，你关闭了所有现实的失败模式：设备丢失（同步）、最近文件恢复（同步）、历史知识库恢复（Ginkgo）、账户锁定（Ginkgo）、勒索软件（Ginkgo 异地）、以及缓慢发生的损坏（Ginkgo 长保留）。Obsidian Sync vs 备份的问题通过同时使用两者来回答，各司其职。