个人服务器治理：让项目位置、服务、日志和备份都可控

服务器“能访问”并不代表可管理。每个域名、反向代理、端口、进程、代码目录、运行用户、数据库、上传文件和备份都应能双向追溯。先盘点和只读核验，不要在不清楚归属的服务上直接重启、覆盖或清理。

建立服务资产表

每个项目记录：项目负责人、公开域名、Nginx server/location、上游地址、PM2/systemd 名称、PID、运行用户、Node 版本、cwd、入口脚本、Git 仓库与 commit、部署目录、监听端口、环境变量文件位置、日志位置、上传目录、数据库/Redis依赖、健康检查和最近备份。绝不把 .env 内容、token、私钥或数据库连接串放进这份表。

目录按源代码/发布产物/持久上传/临时文件/备份区分。上传文件、数据库和密钥不应放在每次部署会替换的目录里。项目之间用独立系统用户、目录权限、端口与数据库账号隔离；管理端口和数据库默认只监听 localhost。

PM2 管理原则

ecosystem 配置是可审阅的服务清单；应用名、cwd、script、解释器、实例数、重启策略和日志路径都要明确。观察状态和修改状态分开：先 describe/jlist/ps/ss 确认一个项目的真实路径和进程归属，再执行只针对该项目的 reload/restart。不要用 restart all 当作部署按钮；pm2 save 前核对清单，防止把临时进程写进启动状态。

应用要在 SIGTERM 时停止接新任务、有限等待在途请求、关闭数据库连接，然后退出。多实例 reload 只在应用无状态、readiness 正确且共享资源安全时使用。日志设置轮转与磁盘阈值，告警不应把密码、完整请求体或书籍内容写出来。

可复现部署

本地锁定依赖并完成 lint/typecheck/test/build，记录提交号与产物哈希。服务端上传到新的候选目录，验证哈希和配置文件存在性（不回显秘密），生成必要的 ORM Client，在备用端口执行健康检查和只读 API。验证通过后再切换流量/软链接，保留旧版本回滚窗口；数据库迁移单独备份、单独评估兼容性。

回滚分为代码、配置、数据三件事。切回旧目录不能自动撤销数据库迁移，配置错误也不能只靠重启消失。每项目文档应给出准确 deploy/check/rollback 入口、目标服务名、健康路径和危险操作说明，命令前先检查 cwd 和受影响项目。

备份与恢复

定义 RPO（可接受丢失时间）与 RTO（恢复时长），覆盖数据库、上传资源、配置和可重建代码。备份要独立于生产磁盘或至少独立权限/介质，文件加密并限制读取；保存周期与删除策略明确。只看到“备份成功”不够：定期在隔离环境恢复，校验数据库对象、上传文件哈希、服务启动和关键页面。保留恢复演练日期与结果。

日常巡检

按项目检查 PM2/systemd 健康、磁盘/inode、内存、CPU、证书到期、Nginx 配置、依赖漏洞、备份新鲜度、错误日志和过期临时文件。任何清理先计算范围、确认文件不被服务或恢复流程引用，再做可回滚的归档。一次只处理一个服务，变更后用公网和本机 loopback 两侧验证。

每个服务另备一页故障卡：公网入口、健康检查、当前版本、日志查询、依赖服务、值班联系人、最近备份、停止接流量方式和回滚目标。故障时先保存现场与时间线，再确认影响面、磁盘和进程状态；不要在证据收集前清日志或批量重启。处置后用独立请求验证登录、静态资源、数据库读写和后台任务，并将临时凭证按既定轮换流程失效。

恢复演练模板

在隔离环境记录备份时间、校验值、恢复步骤、密钥获取方式（不记录密钥本身）和清理办法。恢复数据库后核对迁移版本与关键行数；恢复上传后抽查哈希与权限；启动候选服务，验证 readiness、登录、受限文件访问和静态资源。演练成功记录实际 RTO；失败则补齐缺口并重练。若备份与生产同盘同账号且未加密，要明确它不能抵御磁盘或账号级故障。

安全的服务器是路径、权限、部署和恢复过程都能解释，而不是把所有管理集中到一个没有审计的面板。

参考：PM2 Process Management、Nginx Beginner’s Guide、PostgreSQL Backup and Restore。