坑边闲话:作为一个 OneDrive坚果云双持的用户,多年来笔者一直对自己的数据同步与存储机制感到较为满意。其中:OneDrive 凭借几乎免费的价格和 1TB 的可靠云存储,被笔者当作照片备份工具;坚果云凭借着强大的国内、国际可用性及增量同步机制,被笔者当作主力文件同步工具

笔者在读本科时一直想使用 Dropbox 作为单一云存储,可惜因当时的网络和价格问题最终没有成行。如今笔者发现在 30% UniDays 优惠券加持下,Dropbox Plus 2TB 服务一年仅需 £67.12,约合 ¥627,总体还是可以接受的。

本文介绍如何在遵循狡兔三窟鸡蛋不放到一个篮子里等原则下,使用不同服务商的云服务的过程。

1. 迁移动机·

随着中国大陆言论审核越来越严格,云盘随时面临资料「被和谐」的隐患。本人自认为云盘里没有违规的文件,如色情、暴力、反动内容。然而「违规内容」的认定缺乏统一标准,比如难以确定在未来的某一天某个关键词是否会成为违禁词。上述情况使得原本正常或有些许擦边的文件也可能在未来的某一天变得不可用。此外,本人未来相当长的一段时间将会居住在海外,因此把资料同步到一个海外公司比较现实。

对于追求高可靠性和高隐私性的用户来说,选择一个大陆境内的网盘作为「身家性命级资料」的存储池并不明智。笔者读本科阶段也曾想过使用 Dropbox 作为主力同步盘,但该网盘需要使用代理且彼时代理流量特别贵,因此不了了之。如今 Dropbox Plus 的价格已经变得可被笔者接受,代理流量的价格也降低了很多,因此使用 Dropbox 已不再是一个不可行的事情。

图 1. 使用英国高校学生身份的 UniDays 非常划算!可享受 30% 的折扣。

1.1 数据安全·

本项分为存储安全性分享安全性

  • 存储安全性
    • 百度网盘:该网盘经常将某些视频定性为违法内容,且可以直接将用户的数据删除而无需告知用户。近年来百度网盘的审核愈发变态,甚至用上了 AI 算法对内容进行分析。由于百度网盘缺乏可靠且高效的算法,偶尔会将医学图像中的裸露画面视为非法内容并自动删除。笔者极其不推荐明文使用百度网盘,建议配合第三方开源加密客户端进行使用。
    • 坚果云:尚未发现对仅个人存储但不共享的数据进行违规性审核;
    • Dropbox:相对安全,风评较好;
    • OneDrive:相对安全,风评较好。
  • 分享安全性
    • 百度网盘:全线审核,分享链接更是严格审核;
    • 坚果云:会进行内容审核,估计过滤原则包括但不限于反党反社会、色情、暴力等;
    • Dropbox:主要是对内容的版权进行审核,审核项目少于 Dropbox;
    • OneDrive:通过 SharePoint 功能进行分享,目前未发现有严厉审核。

此外,在中国大陆:

  • OneDrive 的网页端被屏蔽,因此 OneDrive 分享功能基本上是不可用的;
  • Dropbox 全线被屏蔽,分享功能更是不可用。

提醒

使用了 Dropbox,就放弃在国内共享文件的念头吧。

图 2. 笔者的坚果云还有相当久的高级会员,可惜这段会员期要被浪费掉了。

提醒

云存储是一件事关重大的服务,用得好可以事半功倍,实现可靠的文件存储和方便的文件共享,使用不好则有可能导致文件错乱。因此,在决定投身之前,一定要想清楚:

  • 使用策略:云与云之间是不同的;
  • 回退方案;
  • 价格与效果,如可用空间大小。

1.2 留学期间的可访问性·

本节分析不同网盘的海外可用性。目前仅描述英国地区。

  • 115 网盘:作为一家做类似灰产的科技公司,115 在一个小众领域存活得不错。本人将其作为拥有 250TB 超大云空间的备份盘使用。在英国地区,115 网盘体验一般,延迟较高,貌似数据是来自中国的数据中心;
  • 坚果云:坚果云的客服称海外也可以使用坚果云,效果尚可。至于坚果云是做了线路优化还是在海外有数据中心,不得而知。此外,坚果云的同步方式貌似是单线程逐文件同步,小文件太多会导致同步速度很慢
  • OneDrive:微软在爱尔兰就有数据中心,至于是否是为 OneDrive 服务打造,依旧不得而知,但是 OneDrive 在海外的速度毋庸置疑,绝对是飞速;
  • Dropbox:速度也是第一梯队,和 OneDrive 差不多,甚至更快一些;Dropbox 同步机制是多线程多文件并行,在同步速度上比坚果云快很多

小结

继续使用坚果云加 OneDrive 的组合也是可以勉强接受的,但是 Dropbox 单一网盘存储所有类型数据会更加省心,在电脑上只运行一个同步软件,带来的个人运维压力也更小一些。

有一点要提醒,如果要将 OneDrive 路径(哪怕是子目录)通过 SMB 分享给 Linux 系统,在 Linux 6.6/6.7 内核上会产生问题。虽然当前笔者的内核是 Debian 12.5 的 6.1 版本,但是未来正式升级到 6.6 LTS 后是否会出现同样问题仍未可知,因此转移到 Dropbox 会更加稳妥一些。

P.S. Dropbox 在更高的 Linux 内核版本上是否会出现同样的 CIFS 挂载错误,尚未经过验证

1.3 对使用习惯的破坏性·

坚果云支持多个根同步文件夹,但是 Dropbox 只支持一个。两款软件的设计原则不同,导致笔者在 Windows 上的使用习惯要随之改变。

  • 坚果云的理念是「只改变效率,不改变习惯」,这是一个很好的想法。笔者的 Tencent Files(QQ 数据目录)和 WeChat Files(微信目录)均被设为同步目录,两个目录存储在 ~/Documents 下,重装系统时无脑点击下一步即可,重装 QQ 和微信也无需调整数据目录位置。但是切换到 Dropbox 之后,就不得不手动切换软件的数据目录。因此,Dropbox 的使用成本略高一些。
  • 坚果云和 Zotero 的集成非常好,而 Dropbox 在 macOS 上基本无法同步 Zotero 的 Sqlite 数据库,频繁报错。对于这一点,笔者尚未想出合理的解决办法。

2. 迁移前的准备工作·

既然决定要迁移,自然要做好万全准备和回退的方案。成年人做事,总是要考虑退路的,一旦 Dropbox 不好用,及时切换回之前的方案。

2.1 锁定当前状态·

笔者在国内的 NAS 上有两个 ZFS ZVol LUN,一是坚果云,二是 OneDrive. 这两个 LUN 均被一台 Windows Server 2022 挂载,并分别使用对应客户端创建了网络同步机制。在迁移之前,笔者先在这两个 LUN 上创建快照,并标记 Dropbox 关键字。

图 3. 创建快照是为了知晓后续做了哪些修改,方便手工校对。哪怕没有用,多打两个快照也几乎没有弊端。

可惜 OneDrive 和坚果云没有打快照的能力,否则也应该在云上做快照。

2.2 在单一终端进行上传·

为了保证云端数据的唯一性,建议在单台设备上进行初次同步。笔者选择使用 MacBook Pro 进行初始化设置。

警告

强烈建议先在把要同步的数据准备好,包括:

  • 目录名称正确
  • 目录层级关系良好
  • 文件齐全、无冗余

完成上述步骤并确认之后,再进行同步。随便把文件丢到 Dropbox 里,同步完再批量修改会造成很大的麻烦,Dropbox 网页端最多只允许一次操作 10 万个文件,哪怕对一个子文件非常多的目录进行重命名,也会被转换为对每一个子文件重命名的操作,如此一来便使得代价十分昂贵!

设置好同步目录,然后关闭 Dropbox;或者开启同步,但是先在一个可靠的临时文件夹里准备好所有数据,然后一次性剪切到 Dropbox 同步目录中。

图 4. 在 macOS 客户端设置同步路径,建议保留默认。

Dropbox 的上传会吃满 M3 Max 的小核性能。

图 5. 系统显示,四个能效核心负载非常高,但笔记本总体保持安静的水平。Intel 芯片的 MacBook 在密集同步的过程中或许会非常烫。

图 6. btop 命令显示 CPU 确实占用很高。

图 7. 静待同步结束即可,这个过程耗费时长视网络、磁盘性能而定。

3. 迁移到 Dropbox 后的感受·

3.1 代理流量成为必需·

大概经历了三天的时间,笔者所有的 macOS、Windows 终端完成了 Dropbox 数据同步,MacBook Pro 和某台 Windows 10 设备位于海外,不需要代理即可同步。国内有两地、共五台 Windows 机器,如下图所示。

图 8. 图中左边 5 台位于国内;最左侧位于家中,最右侧位于英国,中间四台位于北京。

国内机器同步完成之后,总耗费香港节点的代理流量 1.6TB,这在数年前代理流量昂贵的时候是想都不敢想的操作。此后,Dropbox 正常工作的前提即是代理节点和本地代理客户端的工作正常。虽说现在监控的客户端软件由两个变为一个,但是需要额外花时间监测外网的可用性。

3.2 Dropbox 的局限性·

此次迁移并非是全面向好,目前感觉 Dropbox 有如下局限性

  1. Dropbox 与 Zotero 的不兼容,使得笔者现在很难高效无障碍管理文献库;此前坚果云在此方面表现优异;
  2. 因为国内网络问题,现在需要更加保证代理的可用性,无形中增加了一层心智负担。但这并非是 Dropbox 自身的问题;
  3. 失去了坚果云的云桥功能,文件现在只有两种状态:同步和不同步。此前处于云桥中的文件介于两者之间,可以按需同步使用。不过这个缺陷问题不大。

3.3 边云协同与本地快照·

  • 边(Edge):所有的本地客户端
  • 云(Cloud):Dropbox 云服务器
  • 本地快照:本地客户端对 Dropbox 同步文件夹进行定期快照

可靠的存储基于多重备份实现,好用的存储需要解决备份之间的一致性。好的数据存储专家,可以在具体应用场景下找到安全可用之间的平衡点。

目前笔者有三地:

  • 家:中国山东省淄博市
  • 宿舍:英国 West Midlands, Selly Oak
  • 学校:中国北京市

以上三地距离较远,按如下方式配置:

  • 核心存储 TrueNAS SCALE 位于学校,存储容量很可观。TrueNAS SCALE 的协服务器是一台 Windows Server,通过 iSCSI 挂载 ZFS ZVol LUN 并在该 LUN 上同步 Dropbox 的全部文件。借助 ZFS 的实时快照功能,可实现全同步数据集层次的快照
  • 每台 PC 性质(与 server 相对立)的机器按如下原则配置存储:每台机器搭载 512GB 系统盘和 2TB 的数据盘,Dropbox 文件夹在 2TB 盘进行本地持久化保存,有多少台 PC 就有多少本地副本;
  • 学校的机器彼此之间可以实现 Dropbox 局域网同步加速,在特殊时刻可节约外网网络流量。

由此,笔者实现了基于 Dropbox 的云边协同,而且边缘节点始终具有全部的数据,若云失效,也可借助 NAS 的协同服务器进行基于 VPN 的手动同步,避免造成数据不一致。

注意

基于同步机制的云存储固然提供了很多便利性,但是也存在一些安全隐患,比如云端修改默认会覆盖本地数据。比如你在 A 机器上编辑了某文件,该修改记录将被同步到云端,随后再同步到 B 机器。这个机制是很自然的,但倘若云端内容被恶意修改,如恶意篡改恶意删除加密勒索等,对应的恶意修改将会被同步到所有的客户端。一旦所有客户端均完成同步,用户将彻底失去自己的数据

上述恶意修改可能发生在以下场景:

  • Dropbox 云服务器被黑客攻击成功,恶意修改由黑客发起;
  • Dropbox 风控策略失控,导致用户被 Dropbox 主动封号并删除数据。参考 V2EX 帖子。潜在的风控误判原因:
    • 用户的代理节点 IP 地址是机房 IP 而非家庭 IP,毕竟海外的正常用户极少使用机房 IP 登录 Dropbox 账号;
    • 其他可能的风险行为。

为了保证可以掌控自己的数据,笔者引入了本节描述的协服务器. 如果读者不具有协服务器条件,可在本机做同步文件夹快照。总之要把握一个原则:基于 Dropbox 或其他商业方案的多机器、多副本存储并非是真正的多副本,因为副本同步机制并非由用户完全掌控。在这套伪多副本机制中添加一个独立可控的备份或快照机制是有必要的。

图 9. 边云协同加本地快照的 Dropbox 同步拓扑结构。边云协同实现高效率同步和本地(边缘)可用性,本地 Extent 快照可保证数据不被恶意修改而造成无法回退。此外,8030-server 挂载了 Dropbox LUN 之后,还可以使用 SMB 服务将文件共享给 Linux 服务器(共享关系未列出),实现自托管云相册(基于 PhotoPrism)等功能。

3.4 注意选择性同步·

macOS 一般不会用到 Windows 版 QQ 和微信的数据库,因此无需同步对应的子文件夹。

图 10. 在 Dropbox 客户端中,要注意取消同步不需要的文件夹。

不过读者要注意,协同服务器要进行全部同步,否则将失去备份的意义。

总结·

经过大概为期一周(8 July 2024 ~ 13 July 2024)的努力,终于搞定了 Dropbox 数据同步,并完成了本博客,总体来看进展顺利,Dropbox 的商务支持也非常及时、专业。希望这次云迁移的经历能对本文读者有所启发。