备份、同步与换机迁移

备份、同步与换机迁移

这一篇讲的三件事经常被混在一起，但它们的性质完全不同：

备份是为了“出事之后能恢复”——单向、可删、越旧越好。
同步是为了“多台机器看到同一份”——双向、会传播删除。
换机迁移是为了“换设备继续用”——一次性、有方向。

混在一起的后果很严重：最常见的事故是“同步把删除同步到了备份”。

先说一个必须记住的结论

Eagle 不提供内置的云同步。

这是官方文档里的明确说明。跨设备访问需要你自己迁移库，或者自行安排第三方同步方案。

而“同步不等于备份”。 官方的措辞很直接：编辑或删除会传播到同步位置，所以同步不构成一份独立的可恢复副本。

这个区别值得展开说：

假设你用网盘同步库文件夹。

你误删了 200 张素材 → 同步工具把删除传到了云端 → 备份也没了
AI 批量跑崩了，标签全乱了 → 同步把错误状态传到了“备份” → 你有一份很新的、但同样错误的副本
同步中途断电，文件处于半写入状态 → 云端那份也坏了

这三种情况里，“同步出来的备份”都没有救到你的能力。

一、备份的正确做法

官方的备份指引覆盖了两条路：把整个库复制到另一台设备，以及使用备份工具。

关键要求只有一个：整个库。

该备份的	不该只备份的
整个库文件夹（含素材 + 标签 + 注释 + 文件夹结构）	只复制选中的图片
独立的、可校验的副本	只复制素材文件而不管库数据

只复制部分图片，会把其余的库数据留在备份之外——而那些数据恰恰不可再生。

一套实用的备份节奏：

频率	动作
每次大规模批量操作前	完整复制一份
每次重要项目交付后	完整复制一份
每周	复制一份到移动硬盘或另一台设备
每月	校验一次完整性（随机抽查若干素材能否打开）

校验这一步经常被跳过，但它才是备份的保险。 一个三个月前做、之后再没打开过的备份，出事的时候可能已经坏了——硬盘有寿命，网盘有同步中断的历史。

版本保留策略： 不要只留最新一份。建议保留“最近三份 + 每月一份 + 每个大改之前一份”。这样至少能应对”上周还好好的“这种情况。

二、同步的正确用法

既然同步有传播删除的风险，那怎么用才安全？

方案 A：单向同步（推荐）

用同步工具把库文件夹单向上传到云盘，不允许云端改本地。

这样做的好处是： - 云端有一份异地副本，硬盘坏了不慌 - 云端被误改也不会立刻影响你（实际上会被下拉覆盖，但那是你可以发现的） - 不需要复杂的冲突处理

方案 B：真双向同步（谨慎）

如果你确实需要两台机器都能编辑（比如公司一台、家里一台），那双向同步是唯一选择。这时候必须：

只在机器 A 上编辑。 机器 B 纯粹用来读取和挑选。这一条纪律能消除 99% 的冲突。
编辑前先确保另一台已完全同步。
冲突发生时，以“最后写入的”为准，并人工检查。

常见坑：在两台机器上同时编辑同一个库，等于给自己制造冲突。同步工具的冲突处理策略（保留两份、覆盖、以新为准）都不理想——因为素材库没有“合并”这个概念。 标签、注释、文件夹归属的合并逻辑，同步工具无法正确处理。

三、换机迁移：完整流程

第 1 步：目标机准备。

装好 Eagle，确认磁盘空间够。

第 2 步：旧机完全退出 Eagle。

这一步不能省。Eagle 在运行时可能持续写入，复制出来的库不完整。

第 3 步：确认库路径。

Eagle 提供了读取当前库路径的能力（库信息里能拿到库所在路径）。复制前先核对路径，别复制错了库——特别是你有多个库的时候。

第 4 步：整体复制库文件夹到目标机。

第 5 步：目标机启动 Eagle，指向这个库。

第 6 步：验收。

抽查几类素材：普通图片、视频、字体、PSD。确认缩略图正常、双击预览正常、标签和注释都在。

第 7 步：旧机先别删。

至少保留一个月，等你在新机上确认所有东西都正常了，再处理旧机。

第 8 步：如果涉及 API 或插件依赖，注意这些是绑在机器上的。

API Key、插件配置、快捷键设置这些通常存在用户数据目录里，不在资源库文件夹内。换机之后这些要重新配一遍。

常见坑：以为复制了库文件夹就等于完整迁移。素材搬过去了，但你的插件配置、API Key、自定义设置全没了。 如果你在旧机上有大量插件配置，建议另外单独导出一份用户数据目录作为留档。

四、库文件变大后的性能考虑

库文件如果存在网络盘上，有一个副作用：大量小文件在网络环境下会明显变慢。

素材库正是“大量小文件”这个形态的典型。Eagle 的库里有原始素材文件、缩略图、元数据文件，全都是小文件。

所以有一个取舍：

放在本地 SSD 上 → 性能好，但备份必须做（硬盘坏了就没了）
放在网络盘/NAS 上 → 异地容灾好，但性能下降明显

折中方案：本地放工作库，网络盘放定期归档副本。 备份按节奏做上去，性能问题就不存在了。

五、备份策略的一个常见误区

误区：备份越多越安全，于是每天备份。

每天备份的问题是：可用版本太多，反而不知道该恢复哪个。而且占空间。

更实用的策略是“按事件备份”而不是”按时间备份“：

事件	备份时机
大规模 AI 批量处理后	立刻
标签批量合并前	立刻（不可逆操作）
迁移 / 大重构前	立刻
项目交付后	做一次
平时	每周一次例行

“事件驱动”的好处是：每一个备份点都对应一个明确的、值得保留的状态。 恢复的时候你知道该恢复到哪个点，因为你知道那时候发生了什么。

六、API 层的备份检查工具

如果你想更系统地确认一个库的完整性，可以用 API 做一次盘点。这不是备份的替代，是备份的验收工具。

核对总数：

console.log(await eagle.item.countAll());

核对当前库信息（名称、路径、最后修改时间）：

console.log(await eagle.library.info());
console.log(eagle.library.path);
console.log(eagle.library.modificationTime);

做一次“资产体检”：

console.log('未分类:', await eagle.item.count({ isUnfiled: true }));
console.log('未打标签:', await eagle.item.count({ isUntagged: true }));
console.log('被删在垃圾桶:', await eagle.item.getAll().then(a => a.filter(i => i.isDeleted).length));

按修改时间做一次增量盘点（找出最近变动的部分，确认备份是否包含了它们）：

let changed = await eagle.item.getIdsWithModifiedAt();
let recent = changed.filter(x => x.modifiedAt > lastBackupTime);
console.log('备份后新增或修改的:', recent.length);

最后这段特别有用。 它能精确回答“这次备份之后我又改了哪些东西”——比”整个库大概复制完了“可靠得多。

一个性能提醒：eagle.item.getAll() 在素材量非常大时（比如 20 万+）会拖慢应用，因为它返回的是完整对象。盘点时优先用 count() 系列方法，它针对计数场景做了优化；需要字段明细时用 get() 并通过 fields 参数指定只返回需要的字段。

七、验证备份是否真的有效

备份不做验证，等于没有备份。

一个完整的验证流程：

定期在另一台设备上打开备份的库。 不只是看文件在不在，而是真的打开 Eagle 指向那个副本。
抽查完整性。 随机挑 10 张素材，确认能预览、能打开信息面板。
检查元数据。 随便点开一张有标签有注释的，确认这些都在。
记录验证结果。 哪天验证过、结果如何，写下来。

第 4 条听起来多余，但一年后你会庆幸有这份记录——当你需要向自己证明“备份是好的”的时候，它就在那儿。

一个可以直接抄的备份 SOP

每周一次： 1. 退出 Eagle。 2. 复制整个库文件夹到备份位置，命名为带日期的副本。 3. 保留策略：最近三份 + 每月一份归档。 4. 随机打开 3 张素材，确认副本可用。

每季度一次： 1. 在另一台设备上完整打开一个备份副本。 2. 抽查各类素材和元数据。 3. 确认无误后记录验证日期。

事件触发时（AI 批量、标签合并、迁移、重构）： 1. 立刻做一份带日期的备份。 2. 标记这份是“操作前”快照。

常见坑：把备份放在和库同一个磁盘上。同一个磁盘的备份只能防“误删、误改”，防不了硬盘故障。 至少要有一份在物理上不同的地方。

常见坑：以为同步盘就是备份。如果你的同步是双向的，那你误删的那一刻，备份也一起没了。“我明明有网盘”不是理由——它是同步，不是备份。

整理人：WorkBuddy

4.3 备份、同步与换机迁移