从 ownCloud 迁移：自建 5 副本 3 地备份的家庭 NAS 实践

一位 Reddit 用户分享了自己多年来搭建家庭自托管基础设施的完整历程，从最初的 WD MyCloud 到如今横跨三地、拥有五份数据副本的 ZFS + Proxmox 集群。这篇帖子既是一份务实的自建云演进记录，也抛出了一个所有 ownCloud 用户都绕不开的现实问题：当官方客户端不再支持经典版本时，该往哪里走？

从 WD MyCloud 到自建服务器的起点

这位用户的故事始于 2019 年前后使用的 WD MyCloud。原本免费且勉强够用的备份同步方案（单文件同步耗时约 2 分钟）突然开始收费，厂商强制切换到 GoodSync 且不提供保留旧系统的途径。在尝试新方案无果后，他决定彻底摆脱厂商锁定。

转折点是发现了 ownCloud——恰好也是他所在的苏黎世联邦理工学院（ETH Zurich）在用的系统。作为一个从未搭建过服务器的新手，他把一台 Sandy Bridge 时代的老电脑改造成服务器，跟着 DigitalOcean 的教程一步步搭起 Ubuntu 16、LAMP 栈，最终跑起了 ownCloud。用他的话说：“它就是能用，而且一直能用。快速、不复杂，完成了核心目标——文件同步。”

更大的收获在于备份策略的简化。有了单一集中的存储位置，他只需让父母把文件同步到服务器，剩下的备份由自己统一负责。“不再有一堆硬盘，不再有把 C 盘全部复制到某处然后不知道到底哪份是最新的，尤其是——不再有 WD 那套软件。”

六个月的硬件大升级

过去半年里，这套系统经历了彻底的重构。原本的 Sandy Bridge 电脑（4×4TB RAID5）被替换为一台 Jonsbo N4 机箱，配置相当讲究：

• 两块 16TB 希捷硬盘做镜像存放主数据
• 额外 2×1TB 用于 Proxmox 虚拟机
• 2×4TB 用于内部 PBS（Proxmox Backup Server）备份
• 一块额外 16TB 用于本地的数据备份（先做 ZFS 快照，再复制到远端）

机箱还预留了 ITX 主板位和一块 PiKVM v4 Mini 用于带外管理。这套配置几乎被原样复制到第二台 Jonsbo N4：两块 14TB 东芝硬盘（两份副本）、两块 4TB（PBS 备份）、一块 1TB SSD，同样塞进了一块 PiKVM——用他的话说“上面已经非常满了”。

第二台机器放在父母家，负责从第一台 N4 的备份盘和运行在其上的 PBS 虚拟机拉取 ZFS 快照与 PBS 备份。此外还有一台 HPE MicroServer Gen 8，配 16TB 加 2TB 硬盘，放在朋友家作为第三地节点，同样从主机拉取数据。

Proxmox VE 是一个基于 Debian Linux 的开源虚拟化平台，集成了 KVM 虚拟机和 LXC 容器两种虚拟化技术，并内置了 ZFS 文件系统支持。ZFS 是由 Sun Microsystems 开发、后被 Oracle 收购的企业级文件系统，其核心特性包括写时复制（Copy-on-Write）机制、数据完整性校验（通过 checksum 防止"静默数据损坏"）、快照与克隆，以及内置的 RAID 功能（称为 RAIDZ）。PBS（Proxmox Backup Server）是与 Proxmox VE 配套的备份专用服务器软件，支持对虚拟机和容器进行客户端去重的增量备份，大幅降低备份所需的存储空间和网络带宽。PiKVM 则是一种基于树莓派的开源带外管理设备，允许管理员通过网络远程访问服务器的 BIOS/UEFI 界面、重装系统，即便操作系统完全无响应也能进行干预，是无人值守远程节点的重要保障。

五份副本、三个地点的备份哲学

这套架构最值得借鉴的是它对备份原则的实践。综合下来，用户实现了三地、五份数据副本的冗余布局，远超经典的 3-2-1 备份法则（3 份副本、2 种介质、1 份异地）。

三个物理地点分别是自己家、父母家和朋友家，通过 Tailscale 的开源自托管替代方案 Headscale 组建 tailnet 互联，同时也用它来远程访问各节点。运行的服务包括 ownCloud、照片管理工具 Immich，以及最近新装的一块 RTX 2000 Ada 显卡，用于一些小规模的 AI 实验。

这种分布式设计的价值在于：任何单点故障——无论是硬盘损坏、机器宕机还是某个地点遭遇意外——都不会导致数据丢失。ZFS 快照提供了时间点回滚能力，PBS 提供了增量备份，异地节点则抵御了物理灾难风险。对于承担着父母数字资产责任的个人管理员来说，这是一套相当成熟的方案。

3-2-1 备份法则是由存储厂商 Backblaze 推广的数据保护黄金标准：保存至少 3 份数据副本，存储在 2 种不同介质（如硬盘与磁带、本地与云端）上，其中 1 份必须置于异地。这一原则的核心逻辑是消除单点故障——单一硬盘损坏、单一存储类型的系统性失效（如 RAID 控制器故障）、或同一物理地点的灾难（火灾、水灾、盗窃）都无法同时摧毁全部副本。该用户实现的三地五份方案，在此基础上进一步增加了副本数量和物理隔离度，对于承担家庭成员数字资产责任的个人管理员而言，已接近专业级别的容灾设计。值得注意的是，副本数量只是一个维度，备份的可恢复性（即真正测试过能否从备份还原）同样关键，这也是 PBS 增量备份方案的优势之一。

核心难题：ownCloud 客户端不再支持经典版

帖子的真正焦点，是 ownCloud 生态当下的分裂困境。新版客户端（7.x）已不再支持 ownCloud Classic（经典版），这迫使用户必须在几条路径中做出抉择。他逐一评估了主流选项及各自的缺陷：

OCIS

即 ownCloud Infinite Scale，是 ownCloud 官方用 Go 重写的下一代产品。迁移最省事，但用户对其自托管的长期支持存疑：“考虑到客户端的这种情况，我不太信任他们会长期支持自托管。”这种担忧并非空穴来风——当官方连经典版客户端都放弃时，对自托管场景的承诺自然会打折扣。

Nextcloud

作为 ownCloud 早年分叉出来的项目，Nextcloud 是逻辑上最自然的继任者，服务端迁移相对容易。但问题出在客户端：需要为所有用户安装并适配新的 Nextcloud 客户端，否则就得忍受警告信息——而后者可能构成安全风险。

OpenCloud

用户对 OpenCloud 的评价最负面：“安装起来很痛苦，而且我没看到什么优势，尤其是他们似乎把安全补丁放在了付费墙后面。”安全补丁收费对于自托管用户而言几乎是致命缺陷。

继续留守 ownCloud Classic

维持现状意味着停留在一个已被官方逐步抛弃的版本上，长期看安全性和兼容性都会成为隐患。

ownCloud 与 Nextcloud 的分裂源于 2016 年的一次著名开源社区分歧。ownCloud 创始人 Frank Karlitschek 离开公司后，联合核心开发团队 fork 出 Nextcloud，此后两个项目走向截然不同的商业化路径。ownCloud 逐渐向企业授权方向转型，而 Nextcloud 则坚持更开放的社区驱动模式。OCIS（ownCloud Infinite Scale）是 ownCloud 用 Go 语言从头重写的第二代产品，放弃了 PHP 技术栈，在性能和架构上做了根本性重构，但也因此与经典版完全不兼容，数据迁移需要专门的工具。OpenCloud 则是另一支独立分叉，同样基于 Go 重写，但其将安全补丁置于付费层级的商业策略，与自托管社区对开源软件"安全修复必须免费"的基本预期产生了根本冲突。这三个方向各自代表了不同的商业与开源哲学，用户的迁移选择本质上也是对不同社区契约的判断与下注。

给自托管者的启示

这个案例折射出自托管领域一个普遍存在的张力：开源软件的可持续性与厂商商业化之间的矛盾。用户从 WD 的封闭生态逃向 ownCloud，如今又面临 ownCloud 自身的生态动荡，某种程度上说明了单纯依赖某一款软件的风险。

真正让这套系统稳固的，其实不是 ownCloud 本身，而是底层那套与应用解耦的存储和备份架构——ZFS、Proxmox、PBS、Headscale。只要数据层足够健壮，上层的同步应用（无论是 ownCloud、Nextcloud 还是 OCIS）就变成了可替换的组件。这或许才是这篇分享最有价值的启示：在自建基础设施时，把可靠性建立在开放的存储和网络层，而非任何单一的应用软件之上。

就迁移决策而言，从社区反馈的普遍倾向看，Nextcloud 因其服务端迁移的平滑性和活跃的开源社区，通常是 ownCloud Classic 用户最稳妥的落脚点，代价是客户端适配的一次性工作量。而 OCIS 虽然迁移最省事，但需要用户对官方的自托管承诺有足够信心。