将 Nextcloud 迁移到另一台服务器

Nextcloud 可以在需要时迁移到另一台服务器，例如更换硬件，或从虚拟设备迁到物理服务器。迁移期间必须让 Nextcloud 离线，确保没有访问。只有在首次安装 Nextcloud 之前，就已经部署符合行业标准的集群与高可用方案时，Nextcloud 才支持在线迁移。

本文讨论的场景是：一个已经配置好、稳定运行的 Nextcloud 实例，需要迁到另一台机器。例如有了性能更强的服务器，但还不需要集群。迁移耗时取决于实例规模，可能需要数小时。

这里假设用户通过一个虚拟主机名访问实例，这个主机名使用 DNS 中的 CNAME 记录，可以改为指向新位置；迁移后的认证方式，例如 LDAP，也保持不变。

警告：除了使 Nextcloud 进入维护模式，原系统不需要任何修改。 这样一旦出现意外，就能返回原安装环境，在排查问题时继续为用户提供可用的 Nextcloud。

1. 准备新机器。 安装所需操作系统，为 Nextcloud 安装和配置 Web 服务器与 PHP，例如文件权限、上传大小限制。确保 PHP 版本符合 Nextcloud 支持的配置，并安装所有相关 PHP 扩展。配置受 Nextcloud 支持的数据库。如果原机器是近期部署的，复制其基础配置是稳妥的做法。

   重要：迁移前检查原系统的 config/config.php，确认是否配置了以下可选服务：

   • Redis 或 Memcached，用于缓存或会话。
   • 外部对象存储，例如 S3。
   • LDAP。
   • 邮件服务器设置。
   • 全文搜索后端，例如 Elasticsearch。

   复制 Nextcloud 文件之前，必须在新机器上安装并配置这些相同的服务。 否则 Nextcloud 启动时可能出现 “Redis server went away” 或连接失败等错误。

2. 停止原机器上的 Nextcloud。 先启用维护模式，再等待 6—7 分钟，让所有同步客户端识别服务器已进入维护模式，随后停止承载 Nextcloud 的应用服务器或 Web 服务器。

3. 转移数据库。 导出数据库，将导出文件复制到新机器，并导入新机器的数据库。详细步骤见备份与恢复备份。

4. 复制实例的全部文件。 将 Nextcloud 程序文件、数据文件、日志文件和配置文件复制到新机器，参阅备份与恢复备份。数据文件应保留原时间戳，例如使用 rsync 的 -t 选项；否则迁移后客户端会重新下载全部文件。文件所在位置取决于原安装方式和操作系统。新系统要选择恰当的位置；若修改路径，也要对应调整 Nextcloud 的 config.php。

   注意： 这一步可能需要数小时，具体取决于安装规模。

   警告： 更改数据目录的位置可能破坏数据库中的关联关系，官方不支持这样做。

   重要： 将 config/config.php 复制到新机器后，在启动 Nextcloud 之前，逐项检查并更新与服务器有关的配置。至少包括：

   配置项	迁移时的检查内容
   datadirectory	尽可能保持与原服务器完全相同的路径。更改此路径需要更新数据库，强烈不建议这样做。如果确实无法避免，参阅数据目录故障排查。
   dbhost、dbname、dbuser、dbpassword	如果新服务器的数据库主机或凭据不同，更新对应配置。
   trusted_domains	添加或替换新服务器的主机名或 IP 地址。
   overwrite.cli.url、overwritehost、overwriteprotocol、overwritewebroot	按新服务器的 URL 及反向代理配置更新。
   memcache.local、memcache.distributed、memcache.locking 及其连接参数	如果新机器上的缓存或会话后端地址改变，更新配置。根据所用后端检查 redis、redis.cluster，或 memcached_servers。
   objectstore	使用 S3、Swift 等外部对象存储时，确认端点、存储桶和凭据仍有效，并能从新服务器访问。
   mail_smtphost、mail_smtpport	如果新服务器使用不同的 SMTP 中继，更新配置。
   logfile	如果日志路径改变，更新配置。
   tempdirectory	如果设置了自定义路径，确认该目录在新服务器上存在且可写。
   serverid	若已经设置，保留原值。它在多个 PHP 服务器的部署中标识服务器，不应更改。如果通过 NC_serverid 环境变量覆盖它，新服务器应配置相同的覆盖值。

   secret 和 instanceid 在安装时生成一次，与全部加密数据和用户会话相关。不要修改或重新生成它们，必须从原 config.php 逐字复制。

   遗留过期配置，尤其是数据库凭据或 datadirectory，可能导致启动错误或数据损坏。

5. 检查数据指纹。 查看原系统的 config.php 中 data-fingerprint 是否为非空值。如果是，还要在新系统上运行 maintenance:data-fingerprint 命令，与恢复备份时的要求相同，细节见恢复备份。

6. 验证新实例。 再次确认 Nextcloud 仍处于维护模式，并且尚未修改 DNS 的 CNAME 记录。启动新机器上的数据库、Web 服务器或应用服务器，用浏览器访问迁移后的实例。确认能看到维护模式提示，Web 服务器和 Nextcloud 都写入日志，而且没有错误信息。然后退出维护模式，重复检查。以管理员身份登录，确认 Nextcloud 正常运行。

7. 切换 DNS。 修改 CNAME 记录，让用户访问新位置。

来源：Nextcloud 文档贡献者，Migrating to a different server，读取时为 Nextcloud 35 Administration Manual。文档按仓库 CC BY 3.0 许可使用；本稿将英文正文译为中文，并将服务器配置检查项整理成表格。