Day: September 18, 2026

很多早期部署的 Nextcloud 都采用子目录模式。 例如： 这种部署方式简单，而且可以和其他服务共用同一个主域名。 但随着 Nextcloud 和现代浏览器安全机制不断演进，子目录架构会逐渐暴露一些限制。 这次迁移最终把正式地址从： 迁移为： 也就是独立子域名根路径部署。 整个过程涉及： 并不是简单地修改一个域名字符串。 一、为什么要从子目录迁移到子域名 最直接的原因之一是： 现代浏览器支持： Cookie 前缀。 它要求： 而如果 Nextcloud 长期运行在： 路径下，就很难完全满足： 这一要求。 安全扫描因此一直存在一个： 相关提示。 这意味着即使 HTTPS、HSTS、Content-Security-Policy 等其他配置全部正常，子路径本身仍然会限制部分 Cookie Hardening。 因此最终决定把 Nextcloud 放到独立子域名根目录。 二、DNS：先创建新的正式入口 首先创建： 对应 DNS A 记录： TTL 采用普通值，例如： 在真正修改 Web Server 之前，先确认： 这样后续 TLS 和反向代理才能正常验证。 三、TLS：把新域名加入现有多域名证书 …

长期运行的 Nextcloud 实例，升级通常不是简单地执行一次： 就可以结束。 随着运行时间增加，实例会逐渐积累： 因此，一次跨越多个主要版本的升级，本质上更像是一次系统整理。 这次升级最终依次完成： 最终版本为： 一、没有跨主要版本跳跃 整个升级过程采用官方支持的逐版本路线。 例如： 这样做的主要原因不是保守，而是每一个主要版本都可能包含自己的： 如果跳过中间版本，就可能绕过原本应该执行的升级阶段。 二、数据目录分离显著改变了 updater 的行为 在早期升级过程中，一个非常明显的瓶颈出现在： 某次升级中，这一步曾经持续： 后来数据目录从应用程序目录中彻底分离。 原来的结构类似： 调整后变成： Nextcloud 配置中的： 也同步修改。 而且没有通过符号链接伪装旧数据目录。 之后再次进行： 升级时， 几乎变成瞬时完成。 这说明此前 updater 很大一部分时间很可能消耗在庞大的数据目录树检查上。 应用代码和数据目录分离后，更新器只需要处理真正属于程序的文件。 三、升级使用 updater.phar，并明确关闭 updater 自己的备份 其中一次升级命令类似： 这里使用： 并不是表示系统不需要备份。 而是因为该实例已经有独立的备份策略，不需要 updater 再额外生成一份完整程序备份。 更新完成后，继续执行： 最终状态为： 四、第三方 App 是升级中最需要单独处理的部分 Nextcloud Core 与第三方 …

在一次 Nextcloud 大版本升级之后，系统表面上已经完成版本更新，维护模式也已经解除，但数据库和存储层仍然存在一个持续运行的后台迁移任务： 这个任务最终持续了接近一周。 它并不是传统意义上“数据库 Schema 升级跑了一个星期”，而是 Nextcloud 把一部分历史数据迁移拆成了后台任务，使主版本升级可以提前结束，而大规模历史数据转换则在服务恢复之后继续进行。 这类设计可以缩短维护窗口，但也带来了一个容易被忽略的问题： 升级完成，不代表升级相关的所有数据迁移都已经结束。 一、迁移的实际规模 该实例积累了大量历史 Preview 数据。 当时统计到的迁移规模大致为： 因此，这并不是一个几十秒能够结束的普通后台任务。 Nextcloud 会让 PreviewMigrationJob 分批处理数据，而不是在版本升级过程中一次性完成全部迁移。 这也是为什么： 已经执行成功， 也都已经恢复正常， 但后台仍然持续进行数据迁移。 二、真正的问题不是“慢”，而是普通 cron 调度下出现资源失控 最开始，这项任务完全交给 Nextcloud 正常的 cron 机制运行。 例如： 正常情况下，这种方式没有问题。 但对于一个规模达到十万级数据库记录、百万级历史 Preview 文件的迁移任务来说，问题开始出现。 后台 PHP 任务逐渐堆积，部分进程进入： 也就是 Linux 中的不可中断 I/O 等待状态。 随后系统出现了明显异常： CPU 本身并不是主要瓶颈。 真正的问题更接近： …