共享主机部署出错还能撤回吗？用 Shipback 给 SFTP 发布加上备份与恢复
不少个人站点仍部署在 cPanel、Plesk 或普通 VPS 上：本地改完文件，通过 SFTP 上传即可。麻烦在于，这种发布往往没有 Git 工作树可供 git revert。如果上传覆盖了主机上手工修过的页面，或者 Agent 把旧文件替换成错误版本，恢复就变成了临时找备份、逐个传回去。
Shipback SFTP 是一个面向 SFTP 主机的 Node.js 发布工具，README 标明需要 Node 18+，并提供 CLI 与 MCP 服务。它的核心不是替代 Git，而是在每次覆盖前把服务器原文件备份到远端 _backup-，再记录本次部署涉及的文件；恢复时依据清单判断文件是否仍是本次部署写入的版本。
先预览，再发布
通过 npm 全局安装后，在含有 sites.json 的目录配置站点。配置示例包括主机、端口、用户名、远端根目录、本地目录和忽略规则：
{
"sites": [
{
"name": "mysite",
"host": "server.example.com",
"port": 22,
"username": "cpaneluser",
"remoteRoot": "/home/cpaneluser/public_html",
"localDir": "./mysite",
"ignore": ["drafts/", "*.psd"]
}
]
}
README 给出的基本流程是先看 dry run，再执行部署：
npm install -g shipback-sftp shipback mysite --dry-run shipback mysite
首次使用时工具会询问密码并存入操作系统密钥链；README 说明密码不会经过模型。若主机使用 SSH 密钥，可在站点配置中使用 privateKeyPath。不少共享主机的 SFTP 端口并非 22，连接失败时应先核对控制面板中的端口和 IP 白名单，而不是反复重试上传。
每次部署会备份被覆盖或删除的远端文件，并在 .backup.json 中记录本次新增文件及远端文件的 SHA-256。执行 shipback mysite --restore --dry-run 可先查看撤销计划；确认后用 shipback mysite --restore 恢复最近一次部署，也可指定较早的备份目录。
防止把线上手工修改覆盖回去
回滚不是不加判断地复制旧文件。Shipback 会比较服务器当前文件与部署时写入的内容：如果仍与部署版本一致，就恢复旧文件；如果已经是原版本，则不重复操作；如果内容两边都不一致，默认报告冲突并停止。只有显式传入 --force 才覆盖冲突文件，而且强制恢复前也会备份当前内容。恢复操作本身同样会生成备份，因此恢复也可以再撤销。
需要检查线上改动时，可先运行 shipback mysite --pull --dry-run 查看自上次部署以来服务器端的变化，再决定是否拉回本地。这个步骤对允许通过控制面板直接编辑网站的团队尤其有用：它把“线上有人改过”变成可见差异，而不是等下一次发布才发现。
让 Agent 参与，但限制它能做什么
项目还提供 shipback-mcp，通过 stdio 暴露站点列表、部署预览、部署、检查线上变化、备份列表和恢复等工具。MCP 的部署操作使用预览得到的 planId；如果预览后文件发生变化，执行会拒绝过期计划。README 也强调，Agent 工具不提供删除远端无关文件的 mirror 模式、不允许跳过备份，也不提供清理备份的能力。这比把完整 SFTP 密码和任意 shell 交给模型更收敛，但仍不等于完整安全隔离：本地进程、密钥链权限和 MCP 客户端本身依然需要妥善管理。
操作顺序建议保持简单：先对目标站点运行 dry run，人工确认文件列表；正式部署后查看备份记录；只有确认线上内容需要回退时，先预览 restore，再执行恢复。备份位于同一台主机，能缓解误部署，却不能防止主机账号或存储整体丢失，仍应保留主机商或异地备份。
范围显示你究竟要上传哪些文件；shipback --history 则可查看近期部署、拉取和恢复记录。先把计划、执行结果和备份记录对应起来，发生问题时就不必仅凭终端历史猜测“刚才到底改了什么”。如果项目包含多个站点配置，dry run 时也要显式确认站点名称，避免把正确的恢复流程用到错误目标。
这个差异检查也说明它不是传统意义上的快照：工具只根据记录的文件状态决定能否安全恢复，不会保存网站数据库、上传目录之外的状态或主机配置。WordPress 站点若只用它发布主题文件，数据库内容仍需要单独备份；不要把“文件可撤销”误解成“整站可回到任意时间点”。首次接入已有站点时，先用非生产目录验证忽略规则和远端根路径，尤其检查是否会把缓存、用户上传或环境配置纳入发布范围。
Shipback 适合没有 SSH shell、依赖 SFTP 的共享主机，以及想让 Agent 提交可审查部署计划的小团队。若项目已有成熟的 CI/CD、不可变发布或主机侧快照，应该先评估现有回滚机制；工具提供的是一条务实的 SFTP 撤销路径，而不是替代所有部署治理。
相关链接