不用了的服务器退租前先做什么

项目下线，机器闲着也是成本，不少人直接在控制台点了退租。等想起上面还有配置文件和数据库没导，实例已经释放，找回的希望很渺茫。 先确认没人还依赖它 退租前在业务群里问一句，比事后补救便宜得多。有些不起眼的定时任务、内部小工具、测试环境的数据库，恰恰跑在这台"没用了"的机器上。最近的登录和流量也能佐证判断： ``` last | head -20 ``` 连续几周无人登录、带宽几乎为零，退租决定才算有依据。 把数据完整导出来 按"代码、数据库、配置、证书"四类清点。代码推到仓库；数据库用 mysqldump 导出并压缩；Web 服务与应用的配置、crontab 内容都要留档： ``` crontab -l > crons.bak ``` 导完算校验和，换个目录解压验证能打开，才算导成功。私钥和证书文件单独收好，将来复用能省一次签发。备份目录里那些被遗忘的历史压缩包也别落下，不少团队最全的一份旧备份就躺在这台机器上。 确认迁移真正完成 如果业务是迁到新机器再退旧的，要等新机器稳定运行一段时间再退。DNS 缓存、客户端重试、第三方回调，都可能让旧机器在切换后几天还有零星流量。期间把旧机器的对外端口收紧，只留自己的 IP 可访问，观察一周没有有效请求，再执行退租。控制台流量图是干净与否的直接信号：切换几天后曲线降到贴地，就可以放心了。 数据要彻底擦除 退租前把磁盘上的敏感数据清一遍：数据库文件、应用日志、历史备份、~/.ssh、.history 都在内。证书如果和这台机器的解析绑在一起，先把关系理顺，别让还在运行的服务被连带。数据盘整盘覆盖一遍更稳妥： ``` shred -vfz -n 1 /dev/vdb ``` 覆盖几分钟就能跑完，期间别再写入；系统盘则交给平台的重置或回收流程处理。 退租不急在一时：导出、验证、观察、擦除，四步走完再点确认，既不丢数据，也不给后续留隐患。