最近手头这台机器折腾了一圈，把备份、迁移、环境重装这套流程完整走了一遍。过程不算复杂，但刚好能把这台免费云服务器的真实稳定性摊开来看看。跑在上面的是自建搜索服务、Node 接口和笔记同步脚本，数据不多，但足够检验“稳态”之外的应对能力。

故障起因：磁盘空间预警

上周收到告警，系统盘使用率突破 85%。查下来是 Node 模块缓存堆积，加上搜索服务的索引文件增长过快。当时的情况是：服务没挂，但写入开始报错。

我没有选择直接在原机清理，而是决定做一次彻底的“搬家”——备份数据，迁移到同配置的新实例，验证环境重装后的完整性。这一步是为了排除隐患，也是测试平台数据可靠性的好机会。

备份阶段：数据没有丢

我用了最原始但也最稳妥的方式：全量打包。

  1. 停止 Node 服务，避免写入冲突；
  2. 使用 tar 压缩用户目录和数据库 dump 文件；
  3. 通过本地 rsync 下载到主控机，同时上传一份到对象存储作为双保险。

整个过程耗时约 12 分钟。下载完成后，我检查了关键文件：笔记库的 JSON 文件校验一致，搜索索引的头尾哈希对得上。没有发现损坏或截断。这一步说明，在正常运维操作下，存储层的可靠性是值得信任的。

迁移与重装：IP 变了，服务还得起来

旧实例释放后，我在新控制台创建了同样的 1 核 1G 实例。这一步要注意：新实例的公网 IP 肯定不同，所以我的笔记同步脚本和搜索服务的对外地址配置需要更新。

环境重装花了我不少时间，主要是依赖安装和配置调整：

  1. 系统更新：apt update && apt upgrade -y，耗时约 5 分钟；
  2. Node.js 安装：直接使用 NodeSource 源安装 v18 LTS，版本固定；
  3. PostgreSQL 初始化：创建用户和数据库，恢复之前的 SQL dump；
  4. Docker 环境：重新拉取搜索服务的镜像，挂载本地数据卷。

这里有个小插曲：Docker 容器启动时端口冲突，查日志发现是之前遗留的僵尸容器没清干净。用 docker ps -a | grep Exited 扫了一眼，清理掉残留容器后，一切正常。

观测数据：冷启动与稳态表现

服务恢复后，我跑了半小时的压力测试和日常观察。结果如下：

  • 冷启动时间：Node 服务启动较慢，从执行 npm start 到监听端口，大约需要 15-20 秒。这是因为搜索服务初始化索引需要读盘，磁盘 IO 在冷机时确实偏慢；
  • 稳态内存：常驻内存稳定在 500MB 上下，波动幅度在 ±20MB 以内；
  • 接口响应：日常请求响应时间在几十毫秒级别，P99 未超过 200ms。

这些数字和我之前记录的 baseline 基本一致。说明更换实例并没有引入性能退化，也没有因为“免费”身份被限速。

为什么折腾完还敢继续用

这次经历让我更清楚它的边界在哪里。它不是那种“扔上去就不管”的生产级方案，而是一个需要你偶尔参与维护的伙伴。

  • 手动备份意识强：我不依赖平台自动快照，自己掌握数据出口；
  • 迁移成本低：1 核 1G 的配置，重装环境半小时能搞定；
  • 资源兑现实在：500MB 内存、几十毫秒响应，实测数据不掺水；
  • 故障自愈可预期：知道哪里会卡（磁盘 IO），提前规避；
  • 续费机制透明：每 7 天手动点一次，没有隐藏门槛；
  • 适合实验场景：改配置、装新包、测新版本，坏了就重来；
  • 客服响应正常：期间问了一个防火墙规则的问题，两小时内得到回复；
  • 生态完整：Node、Python、PostgreSQL、Docker 都能跑，不阉割；
  • 心态平稳：不指望它永远不出事，但出事能解决；
  • 长期可用：只要我愿意续，它就一直给，没有“突然消失”的风险。

适合谁这样折腾

如果你也是个人开发者，跑一些非关键的内部服务，愿意花时间维护，那这种免费云服务器很适合你。尤其是学生做课设、开发者练手 Linux、或者需要一个备用环境跑定时任务，都很合适。

如果是追求高可用的生产业务，建议还是买付费实例。这里的“免费”是有代价的：你要操心续期，要操心备份，要接受偶尔的维护窗口。

最后提一句，如果你是纯新手，还没接触过服务器，建议先从免费虚拟主机上手，感受一下网页部署的基础流程，再过渡到云服务器，会轻松很多。

想试的自己搜官网，实名后创建实例。记得设个日历提醒，每 7 天点一次续期。这是我保持它长期稳定的唯一“仪式感”。