在免 KYC 的 VPS 上运行 Nextcloud——文件存在你自己的硬盘里

两人使用的实例 4 GB 内存即可流畅运行；开启预览生成则需要 32 GB。按官方手册装在自己的 NVMe 上，Titan 年付折合 $19.20/月，可用 XMR 支付。

自托管，是用一张订阅账单换一个职务

自托管的宣传口径通常暗示每月账单会消失；它不会消失，只会换一副面孔。你用按席位收费的订阅换来一块租来的切片，外加一个没人提醒过你的头衔：管理员。平台承担账单的这一侧——KVM 虚拟机、不限流量端口和 IP；而安装、更新、备份，以及域名招来的任何邮件纠纷，都落在你的这一侧。Nextcloud 官方管理手册正是写给这样的读者看的。

你托管的是未经改动的上游原版产品：文件、日历、通讯录、分享链接，以及可选的 Talk 音视频通话，行为与项目官方发布的一致。团队会把一个域名指向这台切片，让数据落在自己掌控的磁盘上——预览、版本历史、联邦共享都按文档正常工作，数据目录就在你指定的位置，默认是 /var/www/nextcloud/data。账单可用 19 种加密货币中的任意一种结算，目录里也绝没有任何「托管版 Nextcloud」套餐假装替你干活：root 权限就是产品本身。

诚实的账本有两栏。自托管买到的是：没有按席位逐个增长的用户费，没有广告公司扫描你的文档，没有服务商改条款时的数据迁移绑架。自托管的成本是：打补丁的夜晚、容量规划，以及一个挂着你域名的滥用投诉邮箱。家庭用户和小团队通常觉得这笔交易划算，恰恰因为成本是可以排期的常规工作而非意外——但一定要真的排进日程，因为机器不会在任务到期时自己举手提醒。

经典的错误是把消费级云的使用预期连同文件一起搬过来。租来的切片不会悄悄修复你的数据库结构，不会替你重命名照片，也不会每月发邮件汇报它为你做了什么。从第一天起就定下规矩：更新写在日历上，恢复演练写在日历上，快照按钮是你的同事而不是你的清洁工。本指南的其余部分就是这份日历，按照工作实际发生的顺序展开。

日历上的第一项是容量规划，而给实例选配置，主要是聊内存而不是磁盘——这也是套餐阶梯比存储数字更重要的原因。下一节先讲内存数字，因为它们才决定你装好的实例是不是你最终留得住的那个。

决定套餐的是内存，不是磁盘

存储是所有人都拿来相乘的数字，却是最不重要的那个。200 GB 的照片库在任何套餐的 NVMe 上都能安安静静躺着；真正让实例难受的，是多个用户同时上传、预览生成器开始把 JPEG 和视频转成缩略图的那一刻——这是一场穿着存储戏服的 CPU 与内存问题。先按缩略图的负载选套餐，再按归档容量选，实例就会在照片库早已超出笔记本硬盘之后依然保持流畅。

套餐阶梯，直说了：Core 提供 2 vCPU、4 GB DDR5 ECC 内存和 80 GB NVMe，牌价 $6/月，安静地跑一个两人实例毫无压力。Prime 的 4 vCPU、8 GB 内存配 160 GB，是官方明确的底线——一旦多个用户开启预览生成，就需要它。Titan——8 vCPU、32 GB ECC、320 GB NVMe，牌价 $24/月，年付折合 $19.20/月——是 VPS 产品线的实际上限，也是一个家庭或小团队的舒适答案。两人实例从 Core 起步（牌价 $6/月，年付折合 $4.80/月），只有当缩略图队列催你升级时才往上走，而不是等营销文案催你。

经得起生产环境检验的内存账：数据库想要稳定的四分之一内存，PHP worker 在负载下每个吃掉几十 MB，而一批手机视频涌进来时，预览生成会狠狠顶高内存占用，直到 preview:generate-all 把队列清空——把它放进 cron 定时任务而不是按需触发，让这个峰值落在你排好的时段里。上传高峰时用 free -h 盯着真实占用，而不是等高峰过了再看。实例很少死于磁盘不足；它们更多是在 swap 里踉跄、在 PHP 超时里喘息，而磁盘明明还剩一半容量。

典型的错误是买下用不上的磁盘，因为内存先饿死了应用：4 GB 切片上挂 320 GB 的照片库，预览生成的速度只能用「道歉」来形容，网页界面也恰好在为此买存储的那次上传洪峰中超时。当归档向 TB 级增长，那就是独立服务器磁盘的领地——Summit 的 2 x 2 TB 或 Forge 的 2 x 1 TB——应用本身留在内存匹配的机器上，或者选一个计划好的夜晚，把一切整体搬上裸金属服务器。

为什么虚拟化方式在这里重要：预览 worker、cron 和数据库都默认「分给我的内存就是我的」，而完全虚拟化正是让那 8 GB 名副其实的关键，而不是一个在第一个繁忙夜晚就蒸发掉的突发资源池。接下来是生存之道——快照与备份——无论你选哪一档，都得靠自己执行。

快照兜住一次糟糕的升级；你的备份兜住一座死掉的机房

两种截然不同的灾难穿着相似的外衣。一次失败的迁移会损坏实例，但大楼还立着——一小时前拍的快照几分钟内就能把它恢复。而一台死掉的宿主机、一个损坏的磁盘阵列、一个被删除的账户，会连同机器一起带走所有快照，再严格的快照纪律也无济于事。第二种灾难，人们总是等吃了亏才去投保，而且通常只吃这一次亏。

快照作为结算时的附加项挂在 VPS 套餐上，它是升级阶梯上的正确工具：每次版本更新前拍一张，如果 occ upgrade 在发布说明没预料到的地方卡住，几分钟内回滚。再配一条加密的拉取式备份，指向另一台不同网络上的机器——用 borg create 或 restic backup 备份数据目录加一份数据库转储——机房火灾的场景也就有了自己的出口。Borg 和 Restic 的官方文档假设的正是这种形态：加密、去重、定时、异地。

拉取方向和工具本身同样重要。一份 Nextcloud 服务器有权写入的备份，就是勒索软件可以从内部加密的备份；而从第二台机器发起的拉取——切片永远看不到它的密钥——机器上发生的任何事情都毁不掉它。用数据库自带的工具做转储，随同一次拉取一起传出，并保留几代副本——昨天的失误和上周的从容，都值得一个你真正够得着的恢复点。

以悲剧收场的典型错误是从未验证过的备份：一个 Borg 仓库连续成功运行了一年，却从未被挂载恢复过，而密码短语就写在它所保护的那块磁盘上的某个文件里。每半年向一台临时机器做一次恢复演练，记录耗时，并把密码短语写在服务器以外的地方。你测试过的恢复才是唯一算数的指标；没测过的归档只是一个带着文件名的愿望。

容量和生存都安排妥当之后，安装本身几乎算得上平淡——官方手册从头到尾都覆盖了，主要的纪律就是拒绝聪明的捷径。这就是下一节的内容：选哪条安装路线，以及哪条论坛一句话脚本永远不要碰——不管那个帖子在深夜里显得多有说服力。

官方手册式安装比聪明的一键脚本更经得起岁月

Nextcloud 提供两条有文档的路线：经典的 PHP 加数据库安装，以及 All-in-One 容器镜像——它把整套技术栈打包进自带的管理工具里。两条路线都由项目官方维护，都在管理手册里逐步覆盖，最终都停在一个你凌晨两点还能排查的地方。而那些声称一条命令就能达到同样效果的工具脚本，维护者是你无法提 issue 的无名之人。

经典路线已被千锤百炼：一个受支持的 PHP 版本、一个数据库、你自选的 Web 服务器，然后用 occ maintenance:install 写入配置和数据库结构，并在首次登录前给自己的域名配好 TLS。随时用 php occ status 和内置的状态总览页检查健康度。从一开始就把数据目录和数据库放在本地 NVMe 上——KVM 切片的磁盘是它所在机房里最快的存储，数据库会真切感受到任何更慢的东西带来的每一毫秒，而且用不了一周的真实使用就会感受到。

All-in-One 镜像用一点透明度换来大量便利：数据库、应用和后台任务各有各的容器，备份和更新由项目官方的工具编排。对于不想钻研 PHP 调优的运维者，它是很好的默认选择；经典安装则是更好的老师，在小规格套餐上占用也更轻。两者在小实例上跑 2 vCPU 加 4 GB 都没问题——前面章节的容量规则对任何一条路线都原样适用。

错误的做法是把两条路线混着用：装了 All-in-One 又手动改成经典目录结构，或者因为「看起来更快」而在任何一条路线上叠加论坛片段。选定一条路，跟着它的手册走，把每一次偏离都记在一个位于 Web 根目录之外的文件里——/var/www 就是对这条规则的很好检验。未来升级时的你自己才是那份文件真正的读者，而未来的你不会回复工单，也不记得你只读了一半的那个帖子。

无论选哪条路线，接下来的升级才决定三年后这台实例是否还属于你。项目以稳定的节奏迭代，跟得上的运维者都是把升级日变成固定仪式的人——这正是下一节的内容，一步一步，按永不出错的顺序来。

升级日就是快照日——按规则，不按心情

Nextcloud 的版本发布节奏稳定，每个大版本都期望按顺序逐级升级，而不是一步跨过去。把升级日当成一套固定顺序的例行仪式——拍快照、开维护模式、升级、检查、恢复服务——这套仪式会把版本焦虑变成你做过十几遍的 30 分钟窗口。跳过仪式，每次升级就都成了载着乘客的首飞。

完整顺序：先拍快照；执行 occ maintenance:mode --on，确保迁移途中没有任何用户写入；运行更新程序，然后执行 occ upgrade；应用发布说明中点名的维护命令，例如 occ db:add-missing-indices；用一个普通用户账号登录，点开文件、分享和预览逐项检查；最后退出维护模式，盯一个小时的日志。官方手册的维护与备份章节记录了整个流程；快照则让这一切显得从容而非勇敢。

回滚正是快照体现价值的地方。有快照的机器上一次失败的迁移，是十分钟的回退加一次冷静的复盘——想想下次换个做法；没有快照的同样失败，则是在生产磁盘上的考古项目，旁边还有用户在不停刷新着坏掉的页面。每次升级前都拍快照，哪怕发布说明很无聊——尤其是在它们无聊的时候，因为无聊的更新说明正是自满情绪随新版本一起装进机器的方式。

错误的做法是被通知烦到了就在晚间高峰升级，或者把服务器操作系统升级和 Nextcloud 大版本更新塞进同一个窗口。一个窗口只动一个变量，通知统一放到每月一次的回顾里处理，日历条目诚实地命名——写「升级窗口」而不是「快速更新」——这套仪式就能年年保持完整。用户能原谅一个计划内的周二上午；而一个猝不及防的周四晚上，用户会记到不再是用户的那一天为止。

升级和备份是这份工作的维护 half；另一半是手册无法替你做的判断——这台机器该物理上坐在哪座城市，哪种法律制度应该管辖这块磁盘。下一节讲地理位置，它是一次性的、深思熟虑的选择，而不是从你第一次点击结算时落在哪里就顺便继承。

按你真正害怕的那种程序来选国旗

位置营销卖的是延迟；位置的现实卖的是法律。地图上每一面旗帜的基准牌价都相同，真正的差别在地板之下的对等互联，和磁盘之上的法律制度。选法是问自己：你真正在防御的是哪种程序——民事调取、大规模排查，还是用户的延迟投诉——因为每个答案指向不同的城市，而三者中只有一个是关于毫秒的。

实用的捷径：要求司法程序保障时选苏黎世，瑞士 FADP 加非欧盟姿态，溢价 +35 percent；想要 Tier IV 机房之下无强制数据留存时选雷克雅未克，+20 percent；用户在西欧、且 AMS-IX 的往返质量比任何法律考量都重要时选阿姆斯特丹。挪威的溢价与姿态和冰岛一致；卢森堡则额外提供数据信托制度，+15 percent。其余八面旗帜按基准牌价计费，其中好几个都非常出色。

币种与旗帜完全无关：XMR、BTC 或任意 USDT 网络，在 12 座城市中的任何一座都能结算同一张账单，支付步骤在用门罗币支付指南里有完整讲解。延迟算术是唯一的通用项：从欧洲中部出发，阿姆斯特丹和法兰克福的响应在个位数毫秒；从东亚出发，东京、香港和台北同样如此。用户能察觉每次页面加载多出的 30 毫秒；而司法辖区，没人会在意，直到需要它的那一天。

错误的做法是凭审美选——新加坡的团队用冰岛机器，柏林的家庭用东京机器——然后为一种永远没人审计的差别永久支付延迟税。把威胁模型用一句话写下来，让城市去匹配它，只有模型变了才重新审视。跨旗帜迁移是可行的，但那是真正的工作量；认真选一次，比随意迁移两次便宜。

无论磁盘落在哪里，指向它的域名都会继承平台不替你承担的义务：滥用投诉邮箱、AUP，以及在哪里都禁止的内容类别。运营一个公开实例会让你在某种意义上成为发布者——下一节讲的就是能证明这一点的邮件，以及让这件事保持平淡的习惯。

接过域名，就接过了滥用投诉邮箱

把一个域名指向切片，互联网就开始往里写信：你根本不知道自己在中继的邮件招来的退信投诉，用户密码泄露后的钓鱼举报，有人分享了不该分享的东西之后的版权通知。平台负责投递邮件；阅读并回应它们是运营实例的一部分，这项技能可以直接从滥用工单与 DDoS 防护指南迁移过来。

政策允许的范围比大多数消费者以为的更宽：合法的成人内容在这些机器上是允许的，隐私工具属于正常流量，而禁止清单很短且绝对——CSAM、钓鱼、垃圾邮件和攻击流量，适用于所有套餐、任何币种、全部 12 个位置。AUP 不会因为加密货币支付而松动，正如它不会因为银行卡支付而松动；快照计划和 Borg 任务仍然是你的事，站在那份短清单的正确一侧也是。

对 Nextcloud 运营者来说，实际暴露点通常在分享而非应用本身：一个指向 4 GB 文件夹的公开链接被贴进聊天群，聊天群被截图，最终一份带 URL 的举报落到邮箱里。用数据回应——分享 ID、UTC 时间戳、你撤销的权限——案件会在一天内基于事实关闭。大型迁移之后用 occ files:scan 保持文件台账最新，能让这些回应即时给出，而不是临时考古。

错误的做法是沉默：滥用投诉邮件被转发到一个没人认领的收件箱，举报在事实性回应还来得及帮上忙的时间点之后被搁置发霉。滥用处理部门按自己的时间表升级未回应的案件，与你的休假计划毫无关系。把 abuse@ 联系方式放进和备份同样的监控里，用字段和整改来回应，这个邮箱就会变成例行公事，而不是悬在整个域名头上的隐患。

合规处理完，最后一个攻击面是你自己配置出来的——通常是放任默认设置的结果：永不过期的分享链接、谁都能看所有内容的预览、还在靠页面加载触发的后台任务。加固流程很短，因为控制手段本来就有——下一节按真正降低风险的顺序把它走一遍。

分享链接是你用默认设置亲手配置出的攻击面

Nextcloud 令人记忆深刻的事故几乎从来不是内核漏洞；而是一条没有过期时间、没有密码的分享链接，在公开聊天记录里躺了两年。默认链接既方便又永久，而这正是你在自己管理的机器上最不想要的组合。加固流程很短，因为控制手段本来就有——工作是决定你的默认值并在配置里强制执行，而不是写代码。

在配置里定好底线：公开链接强制密码，限制链接寿命，对只服务一个团队的实例干脆整体禁用公开分享。把后台任务从 AJAX 切换到 occ background:cron，配上系统的 cron 条目——手册的后台任务章节给出了确切的那一行——让预览、清理和动态邮件按钟点运行而不是靠页面加载。然后把预览生成器也排上日程，因为一批手机视频应该安静排队，而不是冲垮 worker。

归档问题在存储层重新出现。照片库和备份终会长到 TB 级，不管当初的宏伟蓝图怎么写；当切片的 NVMe 被填满，诚实的选项只有裁剪或换金属。把库迁到独立服务器 Forge（牌价 $49/月，年付折合 $39.20/月），应用留在原处；或者把所有东西整合到同一台配 2 x 1 TB NVMe、带 IPMI 的机器上。挂载新卷、迁移数据、运行 occ files:scan 重建台账，然后在一个计划好的夜晚完成切换。

错误的做法是加固一次就再也不管——这个流程是习惯，不是事件。每季度：每次大版本升级后重读一遍分享默认值，因为新功能会带来新的默认设置；重跑公开链接审计；对备份做一次恢复演练；并确认 cron 确实按时触发了。每季度三十分钟，就是不至于沦为别人群聊里反面教材的全部代价，也是本指南里最便宜的一项开支。

以上一切反复指向一个值得点名的模式：平台消除的是托管这一类风险，而判断题按设计留在你手里。最后一节把整个工作——下单、安装、运营——压缩成你实际执行的顺序，从一台空切片到一台不留任何敞口的稳定实例。

Nextcloud 部署清单，按实际执行的顺序

整个工作装得进一条顺序，而顺序从安装程序启动之前就开始了。按内存章节的容量规则订购切片——两个安静的用户入门档就够，预览生成会推着你沿阶梯向上——并在同一天设定快照策略，因为第一次升级前拍的那张快照，才是将来救回实例的那张。位置按你真正害怕的法律制度来选，而不是按拍出来最好看的旗帜。

第二步，按官方手册安装——PHP 加数据库，或项目的 All-in-One 镜像——让 occ maintenance:install 成为那个夜晚的主角，而不是论坛上捡来的脚本。首次登录前配好自有域名的 TLS，数据目录放在本地 NVMe，并在还没有任何利害关系时就把后台任务切到 occ background:cron 加系统条目。用户到来之前配置好的一切是决策；用户到来之后才配置的一切是带着旁观者的风险。

第三步，设好那些让实例「无聊得很健康」的日程：预览生成器走队列而不是按需触发，后台任务按钟点跑，分享默认值——公开链接强制密码、限制寿命——写进配置，而不是留给「最后一个装它的人」的设置。每月固定同一天审计公开链接，让这个习惯扛得住日历变动和人员更替。

第四步，建一套扛得住机房灾难的备份：从另一台不同网络上的机器发起加密的 restic backup 或 Borg 拉取，定时执行、密钥存放在切片之外，每半年向一台临时机器做恢复演练。快照覆盖升级日；拉取备份覆盖其余一切。给恢复计时，把密码短语写在服务器以外的地方，归档就不再是一个带着文件名的愿望。

到这时才让数据进场：rsync 照片库，转储并恢复数据库，拷贝配置，在新机器通过一次真实的登录测试后再把域名切过来。在第一个用户登录前给导入的实例拍一张快照，让回滚路径从生产生命的第一分钟就存在。之后，稳态就是加固章节的季度循环——三十分钟，四项检查——而这台实例在每一个层面上都属于你，这是订阅版从未给过的。