第一次迁移生产服务器
好消息，服务器迁移完成了。
坏消息，迁移服务器花了近四小时。这要是生产停机迁移，这不事不得凌晨干。
但我没有，这是一次停机的迁移…
这还是我第一次遇到服务商要跑路。有一说一，机器很稳，也会提前30天发公告，如此的一家服务商就这样没了，挺可惜的，我倒是希望你活下去。
以前总觉得服务器迁移这种事离我挺远，直到通知的时候，才发现：哦，倒霉事落到我身上了。
这次主要迁移的是一些 Web 服务、数据卷。
大部分都跑在 Docker 里，包括：
- cpa
- new-api
- 博客
- PostgreSQL
- Redis
- Nginx
- SSL 证书
需要备份data volume，重新部署 Docker Compose，重新配置 Nginx，重新申请 SSL 证书。
每一层看起来都不复杂，但它们连在一起，就开始有点会折磨人了。
没经验，所以慢
Section titled “没经验，所以慢”这次耗时比较长，主要还是因为没什么服务器迁移经验。
平时部署一个服务还好，看文档，用docker-compose。
但迁移不一样。
迁移是你要先把旧环境拆开，再在新环境里重新拼起来。
比如 Docker volume 看起来恢复了，但数据库不一定真的恢复对了。
Nginx 配置看起来写了，但请求不一定真的进了你想要的 server block。
SSL 证书看起来签了，但域名不一定都覆盖到了。
这几个“不一定”，加起来就是一个下午。
Nginx 是这次的重点嘉宾
Section titled “Nginx 是这次的重点嘉宾”整个过程中最让我头大的还是 Nginx。
主域名访问时，一直出现 nginx welcome page。
二级域名访问却没问题。
这个页面真的很神奇。
就是这个熟悉的家伙：
/etc/nginx/sites-enabled/default删掉默认站点，再 reload Nginx，主域名才终于正常。
这件事给我的感觉就是：有时候不是你没配置，而是有默认配置。
GPT 也会帮倒忙
Section titled “GPT 也会帮倒忙”这次迁移过程中，我也一直在让 GPT 帮我看问题。
它确实很有用。
尤其是排查方向、解释报错、整理命令的时候，可以节省不少时间。
但它也会帮倒忙。
比如有些时候，它会默认你的服务器结构是标准的。
但实际情况是：你的服务器可能有 conf.d，也可能有 sites-enabled，还可能有 certbot 自动生成的配置。
它说得很有道理。
但是服务器情况不一定是gpt说的那样。
所以最后还是要自己去看：
nginx -T真实配置永远比想象中的配置重要。
最后还是跑起来了
Section titled “最后还是跑起来了”折腾了几个小时后，服务终于都恢复了。
博客可以访问，new-api 正常，cpa的数据没丢，统计服务也能起来，主域名和二级域名都能用，SSL 证书也处理好了。
那一刻没有什么特别激动的感觉。
更多是松了一口气。
这次最大的感受是：
时间的流逝，非常快。折腾一会，几个小时没了。
需要树立工程意识，迁移服务的环节流程需要熟悉，才能避免踩坑。要有自己的判断，不能轻易全部的交给 GPT。
服务器迁移不是单纯的搬数据，更是一个重新搭建环境的过程。 每个单独的docker容器挂在的数据卷。 在备份项目和数据卷的时候注意有没有嵌套的卷。 运维也不容易…